Re: Standardising preload & H2 push cache

65 views
Skip to first unread message

Ryan Sleevi

unread,
Aug 17, 2016, 8:28:54 PM8/17/16
to Jake Archibald, Chromium Loading Performance, Ojan Vafai, net-dev
+cc net-dev

On Wed, Aug 17, 2016 at 5:17 PM, 'Jake Archibald' via Chromium Loading Performance <loadi...@chromium.org> wrote:
We're discussing this over at https://github.com/whatwg/fetch/issues/354.

It seems like link[rel=preload] and H2 push should end up in the same per-document cache, and land in the HTTP cache along the way.

However, I'm told that we do something different with the HTTP cache, as in we only set a preloaded or pushed request/response into the cache if it's "used" by the page. Is this true? If so, what's the reason?

--
You received this message because you are subscribed to the Google Groups "Chromium Loading Performance" group.
To unsubscribe from this group and stop receiving emails from it, send an email to loading-dev+unsubscribe@chromium.org.
To post to this group, send email to loadi...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/loading-dev/CAPy%3DJooJs%2BTg2g9qBj7VVAFKxRwRbM1Yp79Gjtnn8qO5mNWXtg%40mail.gmail.com.

Ryan Sleevi

unread,
Aug 17, 2016, 8:34:36 PM8/17/16
to Charles 'Buck' Krasic, Jake Archibald, Chromium Loading Performance, Ojan Vafai, net-dev


On Wed, Aug 17, 2016 at 5:29 PM, 'Charles 'Buck' Krasic' via Chromium Loading Performance <loadi...@chromium.org> wrote:
The net stack is structured so that the the cache transaction layer generates network transactions when needed.   For server push, the layering means that when pushed resources arrive there isn't an obvious way for the net layer to interact with the cache.   When the page "uses" the a pushed resource, the net layer intercepts the request and supplies the pushed resource from memory.  This is transparent to the cache layer, so the resource will be stored in the http cache as usual as part of the cache transaction.

It was my impression that rel=preload in combination with push would pull the resource up into the http cache even if the page didn't "use" the resource, but someone who actually knows the preloader should confirm.
--
Charles 'Buck' Krasic | Software Engineer | ckr...@google.com | +1 (408) 412-1141

--
You received this message because you are subscribed to the Google Groups "Chromium Loading Performance" group.
To unsubscribe from this group and stop receiving emails from it, send an email to loading-dev+unsubscribe@chromium.org.
To post to this group, send email to loadi...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/loading-dev/CAD-iZUbaZpv9y1vd3_rV4J03NGKu%2B5UX_hivWRp3%2BgJwuaW-Jg%40mail.gmail.com.

Jake Archibald

unread,
Aug 17, 2016, 8:54:27 PM8/17/16
to rsl...@chromium.org, Charles 'Buck' Krasic, Chromium Loading Performance, Ojan Vafai, net-dev
Is there a web developer benefit to this, or is it just what fitted with our implementation? As someone unfamiliar with our implementation, it feels a bit weird.

Does it currently sit in a different "waiting zone" to link[rel=preload] content? Do we do anything beyond HTTP caching for link[rel=prefetch]?

On Wed, 17 Aug 2016 at 20:34 Ryan Sleevi <rsl...@chromium.org> wrote:
On Wed, Aug 17, 2016 at 5:29 PM, 'Charles 'Buck' Krasic' via Chromium Loading Performance <loadi...@chromium.org> wrote:
The net stack is structured so that the the cache transaction layer generates network transactions when needed.   For server push, the layering means that when pushed resources arrive there isn't an obvious way for the net layer to interact with the cache.   When the page "uses" the a pushed resource, the net layer intercepts the request and supplies the pushed resource from memory.  This is transparent to the cache layer, so the resource will be stored in the http cache as usual as part of the cache transaction.

It was my impression that rel=preload in combination with push would pull the resource up into the http cache even if the page didn't "use" the resource, but someone who actually knows the preloader should confirm.
On Wed, Aug 17, 2016 at 5:17 PM, 'Jake Archibald' via Chromium Loading Performance <loadi...@chromium.org> wrote:
We're discussing this over at https://github.com/whatwg/fetch/issues/354.

It seems like link[rel=preload] and H2 push should end up in the same per-document cache, and land in the HTTP cache along the way.

However, I'm told that we do something different with the HTTP cache, as in we only set a preloaded or pushed request/response into the cache if it's "used" by the page. Is this true? If so, what's the reason?

--
You received this message because you are subscribed to the Google Groups "Chromium Loading Performance" group.
To unsubscribe from this group and stop receiving emails from it, send an email to loading-dev...@chromium.org.



--
Charles 'Buck' Krasic | Software Engineer | ckr...@google.com | +1 (408) 412-1141

--
You received this message because you are subscribed to the Google Groups "Chromium Loading Performance" group.
To unsubscribe from this group and stop receiving emails from it, send an email to loading-dev...@chromium.org.

To post to this group, send email to loadi...@chromium.org.

Matt Menke

unread,
Aug 17, 2016, 8:58:34 PM8/17/16
to Jake Archibald, Ryan Sleevi, Charles 'Buck' Krasic, Chromium Loading Performance, Ojan Vafai, net-dev
It's architectural.  The entire network stack is pull-based.  You create a URLRequest, you pull the response from it (Which causes it to send a request and pass back the header), you pull data for each read, etc.

With preload, the header is handled outside the network stack, in blink.  So blink creates the request, pulls data into its cache, etc.

With H2 push....There is nothing to pull the data.  There is no URLRequest, and there are a fair number of layers between where pushed streams live, and URLRequest, so you can't just create a URLRequest (Owned by what?) and pass it an already started stream.

On Wed, Aug 17, 2016 at 8:54 PM, 'Jake Archibald' via Chromium Loading Performance <loadi...@chromium.org> wrote:
Is there a web developer benefit to this, or is it just what fitted with our implementation? As someone unfamiliar with our implementation, it feels a bit weird.

Does it currently sit in a different "waiting zone" to link[rel=preload] content? Do we do anything beyond HTTP caching for link[rel=prefetch]?

On Wed, 17 Aug 2016 at 20:34 Ryan Sleevi <rsl...@chromium.org> wrote:
On Wed, Aug 17, 2016 at 5:29 PM, 'Charles 'Buck' Krasic' via Chromium Loading Performance <loadi...@chromium.org> wrote:
The net stack is structured so that the the cache transaction layer generates network transactions when needed.   For server push, the layering means that when pushed resources arrive there isn't an obvious way for the net layer to interact with the cache.   When the page "uses" the a pushed resource, the net layer intercepts the request and supplies the pushed resource from memory.  This is transparent to the cache layer, so the resource will be stored in the http cache as usual as part of the cache transaction.

It was my impression that rel=preload in combination with push would pull the resource up into the http cache even if the page didn't "use" the resource, but someone who actually knows the preloader should confirm.
On Wed, Aug 17, 2016 at 5:17 PM, 'Jake Archibald' via Chromium Loading Performance <loadi...@chromium.org> wrote:
We're discussing this over at https://github.com/whatwg/fetch/issues/354.

It seems like link[rel=preload] and H2 push should end up in the same per-document cache, and land in the HTTP cache along the way.

However, I'm told that we do something different with the HTTP cache, as in we only set a preloaded or pushed request/response into the cache if it's "used" by the page. Is this true? If so, what's the reason?

--
You received this message because you are subscribed to the Google Groups "Chromium Loading Performance" group.
To unsubscribe from this group and stop receiving emails from it, send an email to loading-dev+unsubscribe@chromium.org.



--
Charles 'Buck' Krasic | Software Engineer | ckr...@google.com | +1 (408) 412-1141

--
You received this message because you are subscribed to the Google Groups "Chromium Loading Performance" group.
To unsubscribe from this group and stop receiving emails from it, send an email to loading-dev+unsubscribe@chromium.org.

To post to this group, send email to loadi...@chromium.org.

--
You received this message because you are subscribed to the Google Groups "Chromium Loading Performance" group.
To unsubscribe from this group and stop receiving emails from it, send an email to loading-dev+unsubscribe@chromium.org.

To post to this group, send email to loadi...@chromium.org.

Jake Archibald

unread,
Aug 17, 2016, 9:08:16 PM8/17/16
to Matt Menke, Ryan Sleevi, Charles 'Buck' Krasic, Chromium Loading Performance, Ojan Vafai, net-dev
So does H2 push sit in a different "waiting zone" to link[rel=preload] content? If both "waiting zones" have a match for a particular request, which one wins? I'm guessing preload, since it sounds like pushed resources are deeper.

On Wed, 17 Aug 2016 at 20:58 Matt Menke <mme...@chromium.org> wrote:
It's architectural.  The entire network stack is pull-based.  You create a URLRequest, you pull the response from it (Which causes it to send a request and pass back the header), you pull data for each read, etc.

With preload, the header is handled outside the network stack, in blink.  So blink creates the request, pulls data into its cache, etc.

With H2 push....There is nothing to pull the data.  There is no URLRequest, and there are a fair number of layers between where pushed streams live, and URLRequest, so you can't just create a URLRequest (Owned by what?) and pass it an already started stream.

On Wed, Aug 17, 2016 at 8:54 PM, 'Jake Archibald' via Chromium Loading Performance <loadi...@chromium.org> wrote:
Is there a web developer benefit to this, or is it just what fitted with our implementation? As someone unfamiliar with our implementation, it feels a bit weird.

Does it currently sit in a different "waiting zone" to link[rel=preload] content? Do we do anything beyond HTTP caching for link[rel=prefetch]?

On Wed, 17 Aug 2016 at 20:34 Ryan Sleevi <rsl...@chromium.org> wrote:
On Wed, Aug 17, 2016 at 5:29 PM, 'Charles 'Buck' Krasic' via Chromium Loading Performance <loadi...@chromium.org> wrote:
The net stack is structured so that the the cache transaction layer generates network transactions when needed.   For server push, the layering means that when pushed resources arrive there isn't an obvious way for the net layer to interact with the cache.   When the page "uses" the a pushed resource, the net layer intercepts the request and supplies the pushed resource from memory.  This is transparent to the cache layer, so the resource will be stored in the http cache as usual as part of the cache transaction.

It was my impression that rel=preload in combination with push would pull the resource up into the http cache even if the page didn't "use" the resource, but someone who actually knows the preloader should confirm.
On Wed, Aug 17, 2016 at 5:17 PM, 'Jake Archibald' via Chromium Loading Performance <loadi...@chromium.org> wrote:
We're discussing this over at https://github.com/whatwg/fetch/issues/354.

It seems like link[rel=preload] and H2 push should end up in the same per-document cache, and land in the HTTP cache along the way.

However, I'm told that we do something different with the HTTP cache, as in we only set a preloaded or pushed request/response into the cache if it's "used" by the page. Is this true? If so, what's the reason?

--
You received this message because you are subscribed to the Google Groups "Chromium Loading Performance" group.
To unsubscribe from this group and stop receiving emails from it, send an email to loading-dev...@chromium.org.



--
Charles 'Buck' Krasic | Software Engineer | ckr...@google.com | +1 (408) 412-1141

--
You received this message because you are subscribed to the Google Groups "Chromium Loading Performance" group.
To unsubscribe from this group and stop receiving emails from it, send an email to loading-dev...@chromium.org.

To post to this group, send email to loadi...@chromium.org.

--
You received this message because you are subscribed to the Google Groups "Chromium Loading Performance" group.
To unsubscribe from this group and stop receiving emails from it, send an email to loading-dev...@chromium.org.

To post to this group, send email to loadi...@chromium.org.

Ryan Sleevi

unread,
Aug 17, 2016, 9:10:14 PM8/17/16
to Jake Archibald, Ryan Sleevi, Charles 'Buck' Krasic, Chromium Loading Performance, Ojan Vafai, net-dev
On Wed, Aug 17, 2016 at 5:54 PM, Jake Archibald <jakear...@google.com> wrote:
Is there a web developer benefit to this, or is it just what fitted with our implementation? As someone unfamiliar with our implementation, it feels a bit weird.

Does it currently sit in a different "waiting zone" to link[rel=preload] content?

Yes, significantly so.

Pushed streams sit deep in the bowels of the //net stack, in the browser process, in memory, as part of SpdySession. When PUSH streams come along on a session, we drain the frame from the SpdySession (because we have to, to avoid HOL), and drop it into a SpdyStream. That SpdyStream will later (potentially) be claimed by a request, at which point, we replay the frames from the SpdyStream (or more aptly, the point is reset, and they're pulled as they normally would be for an unpushed stream)


What's important is that the HTTP cache knows nothing about this. It sits above the SPDY logic (which just resembles a normal socket/HttpStream from the POV of the Network Transaction).

You can s/SPDY/H\/2/ here - it's a naming artifact that reflects the origins of our HTTP/2 implementation.

For the reasons Matt mentioned (core architecture), the H/2 stream just... sits here, consuming browser memory.
 
Do we do anything beyond HTTP caching for link[rel=prefetch]?

Prefetch/preload are handled by Blink, in the renderer process, which IPCs to the browser and kicks off the pull requests that Matt mentioned.

Ryan Sleevi

unread,
Aug 17, 2016, 9:11:24 PM8/17/16
to Jake Archibald, Matt Menke, Ryan Sleevi, Charles 'Buck' Krasic, Chromium Loading Performance, Ojan Vafai, net-dev
On Wed, Aug 17, 2016 at 6:08 PM, Jake Archibald <jakear...@google.com> wrote:
So does H2 push sit in a different "waiting zone" to link[rel=preload] content? If both "waiting zones" have a match for a particular request, which one wins? I'm guessing preload, since it sounds like pushed resources are deeper.

See other reply for the context of the buffers, but yes, you're correct that preload wins, if the preload request hit the cache. If it misses the cache, it'll issue a request, in which case, it's a race to see if it matches a H/2 PUSHed stream sitting in the unclaimed queue. If it doesn't, it'll initiate a new outbound request, and any subsequent PUSH will go unclaimed. 

Ojan Vafai

unread,
Aug 17, 2016, 9:13:25 PM8/17/16
to rsl...@chromium.org, Jake Archibald, Charles 'Buck' Krasic, Chromium Loading Performance, net-dev
On Wed, Aug 17, 2016 at 6:10 PM Ryan Sleevi <rsl...@chromium.org> wrote:
On Wed, Aug 17, 2016 at 5:54 PM, Jake Archibald <jakear...@google.com> wrote:
Is there a web developer benefit to this, or is it just what fitted with our implementation? As someone unfamiliar with our implementation, it feels a bit weird.

Does it currently sit in a different "waiting zone" to link[rel=preload] content?

Yes, significantly so.

Pushed streams sit deep in the bowels of the //net stack, in the browser process, in memory, as part of SpdySession. When PUSH streams come along on a session, we drain the frame from the SpdySession (because we have to, to avoid HOL), and drop it into a SpdyStream. That SpdyStream will later (potentially) be claimed by a request, at which point, we replay the frames from the SpdyStream (or more aptly, the point is reset, and they're pulled as they normally would be for an unpushed stream)


What's important is that the HTTP cache knows nothing about this. It sits above the SPDY logic (which just resembles a normal socket/HttpStream from the POV of the Network Transaction).

You can s/SPDY/H\/2/ here - it's a naming artifact that reflects the origins of our HTTP/2 implementation.

For the reasons Matt mentioned (core architecture), the H/2 stream just... sits here, consuming browser memory.

This seems...bad. Is this theoretically fixable?

Jake Archibald

unread,
Aug 17, 2016, 9:14:58 PM8/17/16
to rsl...@chromium.org, Matt Menke, Charles 'Buck' Krasic, Chromium Loading Performance, Ojan Vafai, net-dev
What's the lifetime of a pushed resource then? For preload it (should be) associated with the document, but seems like we don't have that linkage for H2 push.

Ryan Sleevi

unread,
Aug 17, 2016, 9:16:59 PM8/17/16
to Ojan Vafai, Ryan Sleevi, Jake Archibald, Charles 'Buck' Krasic, Chromium Loading Performance, net-dev
On Wed, Aug 17, 2016 at 6:13 PM, Ojan Vafai <oj...@chromium.org> wrote:
This seems...bad. Is this theoretically fixable?

That's by design of any multiplexing protocol, be it HTTP/2 or other, if you allow the peer to initiate. You have to drop the data, buffer the data, or consume the data.

Ryan Sleevi

unread,
Aug 17, 2016, 9:18:45 PM8/17/16
to Jake Archibald, Ryan Sleevi, Matt Menke, Charles 'Buck' Krasic, Chromium Loading Performance, Ojan Vafai, net-dev
On Wed, Aug 17, 2016 at 6:14 PM, Jake Archibald <jakear...@google.com> wrote:
What's the lifetime of a pushed resource then? For preload it (should be) associated with the document, but seems like we don't have that linkage for H2 push.

Dig into the linked code. It's tied to the SpdySession. Which is tied to the lifetime of the H/2 connection to the "server group" (since we may coalesce multiple unique domains to a singular connection, as per H/2's connection pooling)

The //net layer intentionally separates out the notions of sockets to requests, and has no awareness of documents. This is by design - multiple documents may request the same URL, and multiple requests may use the same socket. 

Ojan Vafai

unread,
Aug 17, 2016, 9:49:26 PM8/17/16
to rsl...@chromium.org, Jake Archibald, Charles 'Buck' Krasic, Chromium Loading Performance, net-dev
Maybe I'm missing something. Could we write the data to the disk cache and read it out again if we need to?

Ryan Sleevi

unread,
Aug 17, 2016, 9:55:30 PM8/17/16
to Ojan Vafai, Ryan Sleevi, Jake Archibald, Charles 'Buck' Krasic, Chromium Loading Performance, net-dev
That's the "consume the data" model. See my reply to Jake earlier - the SPDY pool sits significantly below the HTTP cache logic. Also, what do you do for pushed no-store resources?

As Matt earlier replied, a lot of these decisions are baked into the architectural assumptions of a pull-based model. Push is... a bit of a unique special snowflake.

Ryan Sleevi

unread,
Aug 17, 2016, 9:59:52 PM8/17/16
to Ryan Sleevi, Ojan Vafai, Jake Archibald, Charles 'Buck' Krasic, Chromium Loading Performance, net-dev
I should add that I suspect you're reading an implicit "unbounded growth" for these streams. There's not - there's bounds on each stream, and if you fill up those bounds (the receive window), the peer isn't allowed to keep pushing data because the window hasn't been updated by acking the data. This is similar, FWIW, to how TCP works w/r/t kernel buffers and such. So it's not new/unique to H/2.

Egor Pasko

unread,
Aug 18, 2016, 7:20:39 AM8/18/16
to Ojan Vafai, Ryan Sleevi, Jake Archibald, Charles 'Buck' Krasic, Chromium Loading Performance, net-dev
If we are concerned with RAM footprint, we can certainly make it a disk-based storage, though it cannot be HTTP cache for reasons rsleevi@ mentioned. I am not sure we are already as concerned about memory usage of H2 push as to introduce this extra complexity with managing the lifetime of the data on disk.



--
Egor Pasko

Jake Archibald

unread,
Aug 18, 2016, 8:51:55 AM8/18/16
to Egor Pasko, Ojan Vafai, Ryan Sleevi, Charles 'Buck' Krasic, Chromium Loading Performance, net-dev
Speaking as a web developer (with almost no knowledge of Blink internals) I'm less worried about the footprint, but more worried about the matching of pushed resources, and its relation to similar things like rel=preload.

The idea that I could push a no-cache resource with the HTML for tab A, which could get consumed by tab B in some kind of race feels really brittle. link[rel=preload] feels more manageable as it can only be matched by requests from the associated document (via fetch group https://fetch.spec.whatwg.org/#fetch-groups).

Cloudflare has started using link rel=preload headers as an indication for push (https://blog.cloudflare.com/announcing-support-for-http-2-server-push-2/) so we should make sure these dedupe in a reliable way, or make it clear that having both is bad practice. A way to do this is to start consuming the push and tie its lifetime to the document it originated from, via the stream id that produced the PUSH_PROMISE. As it's consumed, it may enter the HTTP cache. We can define rel=preload in a very similar way, allowing for deduping and minimal (or no) behavioural difference between HTTP/1 & 2.

Anne suggests this has been discussed before and the current model is open for change https://github.com/whatwg/fetch/issues/354#issuecomment-240646492 - is this no longer the case?

Ryan Sleevi

unread,
Aug 18, 2016, 10:55:10 AM8/18/16
to Jake Archibald, Chromium Loading Performance, Charles 'Buck' Krasic, Egor Pasko, net-dev, Ojan Vafai

There is no reasonable way to tie PUSH to documents in our current architecture, nor does it seem a reasonable architectural direction to take.

Tom Bergan

unread,
Aug 18, 2016, 4:20:26 PM8/18/16
to Jake Archibald, rsl...@chromium.org, Chromium Loading Performance, Charles 'Buck' Krasic, Egor Pasko, net-dev, Ojan Vafai
Independent of Chrome's architecture, I don't think it makes sense to tie PUSHes to documents because the HTTP/2 spec has no concept of documents (nor does it seem reasonable to add one).

> The idea that I could push a no-cache resource with the HTML for tab A, which could get consumed by tab B in some kind of race feels really brittle.

Could you say more about why this troubles you? Assuming tabs A and B both use the no-cache resource, they're both getting an up-to-date version of the resource. The only difference is that one tab needs an extra round trip to fetch that resource.

One concern you might have is that the no-cache resource was pushed for tab A minutes ago, but never used, then happens to match a request in tab B minutes later (when the resource is now stale). A very strict reading of the HTTP/2 spec says that the no-cache resource cannot be used by tab B in this case unless the server never closed the pushed stream:

Pushed responses are considered successfully validated on the origin server (e.g., if the "no-cache" cache response directive is present ([RFC7234], Section 5.2.2)) while the stream identified by the promised stream ID is still open.

However, I don't know how Chrome deals with this case in practice.

--
You received this message because you are subscribed to the Google Groups "Chromium Loading Performance" group.
To unsubscribe from this group and stop receiving emails from it, send an email to loading-dev+unsubscribe@chromium.org.

To post to this group, send email to loadi...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/loading-dev/CACvaWvba2%2BpzKj407ds2x0PnQ33zA19t%2BgGB0GdFoQgPsL7AWQ%40mail.gmail.com.

Ryan Sleevi

unread,
Aug 18, 2016, 4:25:59 PM8/18/16
to Tom Bergan, Jake Archibald, Ryan Sleevi, Chromium Loading Performance, Charles 'Buck' Krasic, Egor Pasko, net-dev, Ojan Vafai
On Thu, Aug 18, 2016 at 1:20 PM, Tom Bergan <tomb...@chromium.org> wrote:
One concern you might have is that the no-cache resource was pushed for tab A minutes ago, but never used, then happens to match a request in tab B minutes later (when the resource is now stale). A very strict reading of the HTTP/2 spec says that the no-cache resource cannot be used by tab B in this case unless the server never closed the pushed stream:

Pushed responses are considered successfully validated on the origin server (e.g., if the "no-cache" cache response directive is present ([RFC7234], Section 5.2.2)) while the stream identified by the promised stream ID is still open.

However, I don't know how Chrome deals with this case in practice.

Depends on the size of the resource. If the server wasn't able to send it all (e.g. because the receive window was full because no request was attached to drain it and thus update the receive window), it likely has left the stream open, and thus it'll get consumed.

If it's a small resource - for example, it entirely fits into memory (like, say, a small CSS resource) - it's possible that we will have buffered the entire resource in the unclaimed push stream. I'm not familiar enough with the protocol details to know what happens in that case - if the H/2 server can close it without having ever received the ack from the client - but if it does, that's pure wasted bandwidth, since as you mention, it won't be able to be matched.

My understanding is we dropped unclaimed streams to the floor once they get closed. rch@ or bnc@ could confirm. 

Charles 'Buck' Krasic

unread,
Aug 18, 2016, 5:55:49 PM8/18/16
to Ryan Sleevi, Tom Bergan, Jake Archibald, Chromium Loading Performance, Egor Pasko, net-dev, Ojan Vafai
AFAIK, unclaimed streams are dropped based on timeout, regardless of whether the server side is closed or not.

Ojan Vafai

unread,
Aug 18, 2016, 5:59:58 PM8/18/16
to Tom Bergan, Jake Archibald, rsl...@chromium.org, Chromium Loading Performance, Charles 'Buck' Krasic, Egor Pasko, net-dev
There are three things here:
  1. Is changing this reasonable for Chrome's current architecture?
  2. Is changing this reasonable for the specs?
  3. Is changing this reasonable for web developers trying to interact with H2?
I'd like to understand #3 first before we talk about #1 and #2. At the moment, it's not clear to me whether H2 pushes getting cached would be an improvement for web developers. It's certainly not intuitive for them.

To unsubscribe from this group and stop receiving emails from it, send an email to loading-dev...@chromium.org.

To post to this group, send email to loadi...@chromium.org.

Kenji Baheux

unread,
Aug 18, 2016, 6:17:40 PM8/18/16
to Ojan Vafai, Tom Bergan, Jake Archibald, rsl...@chromium.org, Chromium Loading Performance, Charles 'Buck' Krasic, Egor Pasko, net-dev

+1

We are building a platform for developers.

So, yes it makes sense to start from #3 and work backward. If there is an essential need or benefit at #3 then we should strive to achieve it, within reason, even if #2 and #1 gives us tough times.

In effect, Ojan' ordered list is a reverse order of concerns.

Jake, do you mind bootstraping #3 with a doc of currently known or perceived benefits?


To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/loading-dev/CANMdWTuBsH%2BMzDjaiOvduvmSamrNdPbK995EK1TP9QW9w6e25A%40mail.gmail.com.

Jake Archibald

unread,
Aug 19, 2016, 12:30:19 AM8/19/16
to Kenji Baheux, Ojan Vafai, Tom Bergan, rsl...@chromium.org, Chromium Loading Performance, Charles 'Buck' Krasic, Egor Pasko, net-dev

Sure, I'll throw something together on Monday (ooo today)

Jake Archibald

unread,
Aug 19, 2016, 1:01:10 AM8/19/16
to Kenji Baheux, Ojan Vafai, Tom Bergan, rsl...@chromium.org, Chromium Loading Performance, Charles 'Buck' Krasic, Egor Pasko, net-dev

If I have a fresh copy of A in my cache, and A is pushed to me with a more recent last-modified date, then I request A, which copy do I get?

Ryan Sleevi

unread,
Aug 19, 2016, 1:15:58 AM8/19/16
to Jake Archibald, Chromium Loading Performance, Tom Bergan, Kenji Baheux, Egor Pasko, Charles 'Buck' Krasic, net-dev, Ojan Vafai

Which cache and pushed how?

If it's memory cache, you get that first.
If it's disk cache, you get that first.
You should only consume an H2 Push if it would have otherwise resulted in a network request.

Think of push as an RTT reducer and nothing more (for now). It only comes into play if we would have hit the network.


To unsubscribe from this group and stop receiving emails from it, send an email to loading-dev+unsubscribe@chromium.org.

To post to this group, send email to loadi...@chromium.org.

--
You received this message because you are subscribed to the Google Groups "Chromium Loading Performance" group.
To unsubscribe from this group and stop receiving emails from it, send an email to loading-dev+unsubscribe@chromium.org.

To post to this group, send email to loadi...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/loading-dev/CANMdWTuBsH%2BMzDjaiOvduvmSamrNdPbK995EK1TP9QW9w6e25A%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "Chromium Loading Performance" group.
To unsubscribe from this group and stop receiving emails from it, send an email to loading-dev+unsubscribe@chromium.org.

To post to this group, send email to loadi...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/loading-dev/CAPy%3DJoqO00t60yezxB%3D-U4atVx3mNHr3RvyCNER1CCRV7qu_aw%40mail.gmail.com.

Matt Menke

unread,
Aug 19, 2016, 8:34:13 AM8/19/16
to Ryan Sleevi, Jake Archibald, Chromium Loading Performance, Tom Bergan, Kenji Baheux, Egor Pasko, Charles 'Buck' Krasic, net-dev, Ojan Vafai
Also worth noting it's impossible for Chrome to make any guarantees about using the pushed resource instead of the cached one, even if we wanted to - the situation is inherently racy, even if the pushed resource is sent before the resource that references it.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/loading-dev/CACvaWvYTrq60FvjOSS4V7PP5tJVopcQ7HigNgV%3DsiHNfKmHOpg%40mail.gmail.com.

Chris Bentzel

unread,
Aug 19, 2016, 11:58:22 AM8/19/16
to Matt Menke, Ryan Sleevi, Jake Archibald, Chromium Loading Performance, Tom Bergan, Kenji Baheux, Egor Pasko, Charles 'Buck' Krasic, net-dev, Ojan Vafai
There is some work being done soon to check if pushed content is already in cache and reset the stream if it's present. This does mean that there will be a little bit of cache interaction at the lower SpdyStream layer.

I have wondered if the current implementation of push in the stack will lead to surprising behaviors for developers, so glad that we're starting with that and have it drive any potential architectural change.

To unsubscribe from this group and stop receiving emails from it, send an email to loading-dev...@chromium.org.

To post to this group, send email to loadi...@chromium.org.

--
You received this message because you are subscribed to the Google Groups "Chromium Loading Performance" group.
To unsubscribe from this group and stop receiving emails from it, send an email to loading-dev...@chromium.org.

To post to this group, send email to loadi...@chromium.org.

--
You received this message because you are subscribed to the Google Groups "Chromium Loading Performance" group.
To unsubscribe from this group and stop receiving emails from it, send an email to loading-dev...@chromium.org.

--
You received this message because you are subscribed to the Google Groups "Chromium Loading Performance" group.
To unsubscribe from this group and stop receiving emails from it, send an email to loading-dev...@chromium.org.

To post to this group, send email to loadi...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/loading-dev/CACvaWvYTrq60FvjOSS4V7PP5tJVopcQ7HigNgV%3DsiHNfKmHOpg%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "Chromium Loading Performance" group.
To unsubscribe from this group and stop receiving emails from it, send an email to loading-dev...@chromium.org.

To post to this group, send email to loadi...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/loading-dev/CAEK7mvrgBzYJZMH5V1222tWv6juMCtJw2WgLUXgN8Xp%2BYKGZxg%40mail.gmail.com.

Jake Archibald

unread,
Aug 22, 2016, 2:36:08 PM8/22/16
to Kenji Baheux, Ojan Vafai, Tom Bergan, rsl...@chromium.org, Chromium Loading Performance, Charles 'Buck' Krasic, Egor Pasko, net-dev
https://docs.google.com/document/d/1U4FzX3goA42oMDiqnGk3tI3bsMrIayMGcTFjdlStjAs/edit# 

Here's my take on the differences between H2 push & link[rel=preload] and what my advice to developers would currently be.

Ilya Grigorik

unread,
Aug 23, 2016, 2:02:06 PM8/23/16
to Jake Archibald, Kenji Baheux, Ojan Vafai, Tom Bergan, Ryan Sleevi, Chromium Loading Performance, Charles 'Buck' Krasic, Egor Pasko, net-dev
To make things (even) more interesting... 

One of the long outstanding developer wants [1] is a mechanism to expose push streams to the application - e.g. get a JS callback for "push stream has arrived" ala WebSocket onmessage. For one, this would finally answer the question of "so what about websockets in h2" because with said mechanism it would be trivial to polyfill the WS API.

The obvious implication of the above is that the net-stack would have to "push" the stream up to renderer, which might also then answer the open questions about cache interactions (and how it relates, or not, to preload) and such. And if we're talking about cache interactions, then we should also talk about how that should work [2].



To unsubscribe from this group and stop receiving emails from it, send an email to loading-dev+unsubscribe@chromium.org.

To post to this group, send email to loadi...@chromium.org.

--
You received this message because you are subscribed to the Google Groups "Chromium Loading Performance" group.
To unsubscribe from this group and stop receiving emails from it, send an email to loading-dev+unsubscribe@chromium.org.

To post to this group, send email to loadi...@chromium.org.

--
You received this message because you are subscribed to the Google Groups "Chromium Loading Performance" group.
To unsubscribe from this group and stop receiving emails from it, send an email to loading-dev+unsubscribe@chromium.org.

To post to this group, send email to loadi...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/loading-dev/CAPy%3DJorkSzqCrcU27t-P6AxV7P_1qhm%3DG8Wq3-fic5M3_qjsnw%40mail.gmail.com.

Matt Menke

unread,
Aug 23, 2016, 2:19:22 PM8/23/16
to Ilya Grigorik, Jake Archibald, Kenji Baheux, Ojan Vafai, Tom Bergan, Ryan Sleevi, Chromium Loading Performance, Charles 'Buck' Krasic, Egor Pasko, net-dev
I don't think that works.  Push can't be all things to all people.  If we supported that use case, we break the case where a push is for the next navigation.  A resource is pushed, a new navigation happens in another tab before we tell the page about it and hear back, and it requests the same resource.  If we provide the resource, we break the websocket-like interface.  If we don't, we break the case where push is for another navigation.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/loading-dev/CADXXVKrvASyFyRdW6Qry3%2Bk8-z5UguHzMFnAjf407x8pNn4dgw%40mail.gmail.com.

Jake Archibald

unread,
Aug 23, 2016, 2:24:21 PM8/23/16
to Matt Menke, Ilya Grigorik, Kenji Baheux, Ojan Vafai, Tom Bergan, Ryan Sleevi, Chromium Loading Performance, Charles 'Buck' Krasic, Egor Pasko, net-dev

Given the immediacy of h2 push, I don't think we should worry too much about the next navigation case.


To unsubscribe from this group and stop receiving emails from it, send an email to loading-dev...@chromium.org.

To post to this group, send email to loadi...@chromium.org.

--
You received this message because you are subscribed to the Google Groups "Chromium Loading Performance" group.
To unsubscribe from this group and stop receiving emails from it, send an email to loading-dev...@chromium.org.

To post to this group, send email to loadi...@chromium.org.

--
You received this message because you are subscribed to the Google Groups "Chromium Loading Performance" group.
To unsubscribe from this group and stop receiving emails from it, send an email to loading-dev...@chromium.org.

To post to this group, send email to loadi...@chromium.org.

--
You received this message because you are subscribed to the Google Groups "Chromium Loading Performance" group.
To unsubscribe from this group and stop receiving emails from it, send an email to loading-dev...@chromium.org.

To post to this group, send email to loadi...@chromium.org.

Tom Bergan

unread,
Aug 23, 2016, 3:22:58 PM8/23/16
to Jake Archibald, Matt Menke, Ilya Grigorik, Kenji Baheux, Ojan Vafai, Ryan Sleevi, Chromium Loading Performance, Charles 'Buck' Krasic, Egor Pasko, net-dev
I think ojan@'s earlier comment and Jake's doc nicely summarize the main question for me. Is H2 push a network-level optimization (an "RTT reducer", as rsleevi@ put it), where requests go through this sequence:
  1. Service worker (an "origin" thing)
  2. HTTP cache (a "browser profile" thing)
  3. Network (with a lookup in a per-connection "push store", to reduce RTTs)
Or, is H2 push a first-class web feature, where requests go through a sequence like this:
  1. Preload/push store (a "client" thing, perhaps with notifications up to JS when the store is updated)
  2. Service worker (an "origin" thing)
  3. HTTP cache (a "browser profile" thing)
  4. Network
In its current form, H2 push is a network-level optimization that is not visible to higher levels of the stack. In this world, I don't think we need to reason about documents, navigations, Fetch groups, CORS checks, cross-origin (but same-authority) pushes, and other typical Web questions -- the only impacts of H2 push are faster RTTs (when pushed responses match outgoing network requests) and wasted bandwidth (when pushed responses go unused).

Should H2 push be a first-class web feature, instead? Jake's doc nicely summarizes the differences between push and preload, but it doesn't really motivate why H2 push deserves first-class web treatment. Ilya's example of JS code that wants to be notified when pushes arrive is more compelling -- if there are more use cases like that one, then a case could be made that H2 push should be promoted to a first-class web feature.

To unsubscribe from this group and stop receiving emails from it, send an email to loading-dev+unsubscribe@chromium.org.

To post to this group, send email to loadi...@chromium.org.

--
You received this message because you are subscribed to the Google Groups "Chromium Loading Performance" group.
To unsubscribe from this group and stop receiving emails from it, send an email to loading-dev+unsubscribe@chromium.org.

To post to this group, send email to loadi...@chromium.org.

--
You received this message because you are subscribed to the Google Groups "Chromium Loading Performance" group.
To unsubscribe from this group and stop receiving emails from it, send an email to loading-dev+unsubscribe@chromium.org.

To post to this group, send email to loadi...@chromium.org.

--
You received this message because you are subscribed to the Google Groups "Chromium Loading Performance" group.
To unsubscribe from this group and stop receiving emails from it, send an email to loading-dev+unsubscribe@chromium.org.

To post to this group, send email to loadi...@chromium.org.

Ilya Grigorik

unread,
Aug 23, 2016, 8:22:29 PM8/23/16
to Tom Bergan, Jake Archibald, Matt Menke, Kenji Baheux, Ojan Vafai, Ryan Sleevi, Chromium Loading Performance, Charles 'Buck' Krasic, Egor Pasko, net-dev
Given the amount of developer interest in leveraging push for flattening dependency chains, module loading, WebSocket replacement, etc., I am a strong believer that we should consider it a "first-class web feature". Keeping it opaque doesn't help anyone.. lack of actionable feedback and APIs will only lead to less than useful implementations on all sides.

Jake Archibald

unread,
Aug 24, 2016, 2:12:00 AM8/24/16
to Ilya Grigorik, Tom Bergan, Matt Menke, Kenji Baheux, Ojan Vafai, Ryan Sleevi, Chromium Loading Performance, Charles 'Buck' Krasic, Egor Pasko, net-dev

If the store sits with a client or origin we could have a nice API to show the pushes & preloads. But if the store is wider than same-origin, that becomes really tricky.


To unsubscribe from this group and stop receiving emails from it, send an email to loading-dev...@chromium.org.

To post to this group, send email to loadi...@chromium.org.

--
You received this message because you are subscribed to the Google Groups "Chromium Loading Performance" group.
To unsubscribe from this group and stop receiving emails from it, send an email to loading-dev...@chromium.org.

To post to this group, send email to loadi...@chromium.org.

--
You received this message because you are subscribed to the Google Groups "Chromium Loading Performance" group.
To unsubscribe from this group and stop receiving emails from it, send an email to loading-dev...@chromium.org.

To post to this group, send email to loadi...@chromium.org.

--
You received this message because you are subscribed to the Google Groups "Chromium Loading Performance" group.
To unsubscribe from this group and stop receiving emails from it, send an email to loading-dev...@chromium.org.

To post to this group, send email to loadi...@chromium.org.

Adam Rice

unread,
Aug 24, 2016, 2:21:35 AM8/24/16
to Jake Archibald, Ilya Grigorik, Tom Bergan, Matt Menke, Kenji Baheux, Ojan Vafai, Ryan Sleevi, Chromium Loading Performance, Charles 'Buck' Krasic, Egor Pasko, net-dev
Naive question: I was under the impression that HTTP/2 was supposed to be an alternative transport for the HTTP protocol. Has that changed?

To unsubscribe from this group and stop receiving emails from it, send an email to loading-dev+unsubscribe@chromium.org.

To post to this group, send email to loadi...@chromium.org.

--
You received this message because you are subscribed to the Google Groups "Chromium Loading Performance" group.
To unsubscribe from this group and stop receiving emails from it, send an email to loading-dev+unsubscribe@chromium.org.

To post to this group, send email to loadi...@chromium.org.

--
You received this message because you are subscribed to the Google Groups "Chromium Loading Performance" group.
To unsubscribe from this group and stop receiving emails from it, send an email to loading-dev+unsubscribe@chromium.org.

To post to this group, send email to loadi...@chromium.org.

--
You received this message because you are subscribed to the Google Groups "Chromium Loading Performance" group.
To unsubscribe from this group and stop receiving emails from it, send an email to loading-dev+unsubscribe@chromium.org.

To post to this group, send email to loadi...@chromium.org.


--
You received this message because you are subscribed to the Google Groups "net-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to net-dev+unsubscribe@chromium.org.
To post to this group, send email to net...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/CAPy%3DJoqLQszWHg894v3FE6uHjZuS%3DPnWc3Xp7mMkRg4K%3DOvipA%40mail.gmail.com.

Jake Archibald

unread,
Aug 24, 2016, 2:41:43 AM8/24/16
to Adam Rice, Ilya Grigorik, Tom Bergan, Matt Menke, Kenji Baheux, Ojan Vafai, Ryan Sleevi, Chromium Loading Performance, Charles 'Buck' Krasic, Egor Pasko, net-dev

H2 also adds entirely new features, like PUSH_PROMISE.


To unsubscribe from this group and stop receiving emails from it, send an email to loading-dev...@chromium.org.

To post to this group, send email to loadi...@chromium.org.

--
You received this message because you are subscribed to the Google Groups "Chromium Loading Performance" group.
To unsubscribe from this group and stop receiving emails from it, send an email to loading-dev...@chromium.org.

To post to this group, send email to loadi...@chromium.org.

--
You received this message because you are subscribed to the Google Groups "Chromium Loading Performance" group.
To unsubscribe from this group and stop receiving emails from it, send an email to loading-dev...@chromium.org.

To post to this group, send email to loadi...@chromium.org.

--
You received this message because you are subscribed to the Google Groups "Chromium Loading Performance" group.
To unsubscribe from this group and stop receiving emails from it, send an email to loading-dev...@chromium.org.

To post to this group, send email to loadi...@chromium.org.


--
You received this message because you are subscribed to the Google Groups "net-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to net-dev+u...@chromium.org.

To post to this group, send email to net...@chromium.org.

David Benjamin

unread,
Aug 25, 2016, 3:57:54 PM8/25/16
to Jake Archibald, Adam Rice, Ilya Grigorik, Tom Bergan, Matt Menke, Kenji Baheux, Ojan Vafai, Ryan Sleevi, Chromium Loading Performance, Charles 'Buck' Krasic, Egor Pasko, net-dev
It's possible I'm not following this thread fully, but what would push as a "first-class web feature" even mean? A push comes from an HTTP/2 session which has no binding to a document. (And cannot because the entire point of HTTP/2 was to put everything on one socket! That's where a lot of the performance comes from.)

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/CAPy%3DJooxo5VHp6wyKUNjid97jiMxcqmaF0BP7TYSut21qQ3CCQ%40mail.gmail.com.

David Benjamin

unread,
Aug 25, 2016, 4:00:52 PM8/25/16
to Jake Archibald, Adam Rice, Ilya Grigorik, Tom Bergan, Matt Menke, Kenji Baheux, Ojan Vafai, Ryan Sleevi, Chromium Loading Performance, Charles 'Buck' Krasic, Egor Pasko, net-dev
(Matt tells me that pushes are associated with existing streams, so there is actually a binding. Nevermind me. :-) )

Chris Bentzel

unread,
Sep 12, 2016, 4:25:10 PM9/12/16
to David Benjamin, Jake Archibald, Adam Rice, Ilya Grigorik, Tom Bergan, Matt Menke, Kenji Baheux, Ojan Vafai, Ryan Sleevi, Chromium Loading Performance, Charles 'Buck' Krasic, Egor Pasko, net-dev
I have some severely delayed notes from a meeting we had on Aug 24. Please feel free to correct these or specify any oversights:

- Need to spec the "use once" behavior that is currently done for
  prefetch/preload of no-cache resources. This also applies to pushed
  resources that are no-store or require revalidation.

- Since push_promise's are associated with an active stream, we can
  tie that back to an actual URLRequest. From there we can send
  signals about pushed streams back to the context where the initial
  stream was fetched from. This can't be done at the time headers are
  sent back for the intiial request as it can be done at any time
  while the associated reuqest is still open. It arguably could be
  done as a set of headers or data once the body of the associated
  request is consumed. [I'm not sure this was discussed - but arguably
  we could also signal as soon as PUSH_PROMISEs arise]

- One of the concerns with implementation of h2 push is that it
  currently bypasses many hooks that are done for typical requests -
  such as SafeBrowsing checks and WebRequest extension API
  interception. These hooks are done when the matching request is
  issued. Conceptually there's not much different between the current
  in-memory approach tied to an HTTP/2 connection (SpdySession) versus
  storing the data in the cache, but the lifetime of the current
  approach is a bit lower. 

- The current architecture of the networking stack is that the cache
  lives above the network requests, so the actual network requests
  (and HTTP/2 connection information) don't have insight into the
  cache. This is changing though with work to check if promised
  streams are in the cache and canceling the request if so. 

- Cache persistence of H2 Push could have flow control behavior impact
  which would allow the server to send more resources. Currently the
  pushed data consumes flow control window until it is used, but if
  persisted it could be freed up.

- Cache persistence might also impact whether pushed streams can
  continue after the request they are tied to goes away. PUSH_PROMISEs
  can only happen when a request they are associated with is still
  active. If the user navigates away from the page, that active
  request 


To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/loading-dev/CAF8qwaCsEaesM00tKA1rN0eP%2BRtbj%3D9ZXBvqq5dV%3DEc4%3DwQRtA%40mail.gmail.com.

Matt Menke

unread,
Sep 12, 2016, 4:31:32 PM9/12/16
to Chris Bentzel, David Benjamin, Jake Archibald, Adam Rice, Ilya Grigorik, Tom Bergan, Kenji Baheux, Ojan Vafai, Ryan Sleevi, Chromium Loading Performance, Charles 'Buck' Krasic, Egor Pasko, net-dev
On Mon, Sep 12, 2016 at 4:24 PM, Chris Bentzel <cben...@chromium.org> wrote:
I have some severely delayed notes from a meeting we had on Aug 24. Please feel free to correct these or specify any oversights:

- Need to spec the "use once" behavior that is currently done for
  prefetch/preload of no-cache resources. This also applies to pushed
  resources that are no-store or require revalidation.

- Since push_promise's are associated with an active stream, we can
  tie that back to an actual URLRequest. From there we can send
  signals about pushed streams back to the context where the initial
  stream was fetched from. This can't be done at the time headers are
  sent back for the intiial request as it can be done at any time
  while the associated reuqest is still open. It arguably could be
  done as a set of headers or data once the body of the associated
  request is consumed. [I'm not sure this was discussed - but arguably
  we could also signal as soon as PUSH_PROMISEs arise]

- One of the concerns with implementation of h2 push is that it
  currently bypasses many hooks that are done for typical requests -
  such as SafeBrowsing checks and WebRequest extension API
  interception. These hooks are done when the matching request is
  issued. Conceptually there's not much different between the current
  in-memory approach tied to an HTTP/2 connection (SpdySession) versus
  storing the data in the cache, but the lifetime of the current
  approach is a bit lower. 

There is one big difference here - normally, safe browsing kills an untrused download before the body makes it to the disk cache.  Through this path, if we download dangerous data that safebrowsing catches, and the site is later removed from safe browsing, we still have the bad object in our cache.
 
To unsubscribe from this group and stop receiving emails from it, send an email to loading-dev+unsubscribe@chromium.org.

To post to this group, send email to loadi...@chromium.org.

--
You received this message because you are subscribed to the Google Groups "Chromium Loading Performance" group.
To unsubscribe from this group and stop receiving emails from it, send an email to loading-dev+unsubscribe@chromium.org.

To post to this group, send email to loadi...@chromium.org.

--
You received this message because you are subscribed to the Google Groups "Chromium Loading Performance" group.
To unsubscribe from this group and stop receiving emails from it, send an email to loading-dev+unsubscribe@chromium.org.

To post to this group, send email to loadi...@chromium.org.

--
You received this message because you are subscribed to the Google Groups "Chromium Loading Performance" group.
To unsubscribe from this group and stop receiving emails from it, send an email to loading-dev+unsubscribe@chromium.org.

To post to this group, send email to loadi...@chromium.org.


--
You received this message because you are subscribed to the Google Groups "net-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to net-dev+unsubscribe@chromium.org.

To post to this group, send email to net...@chromium.org.

--
You received this message because you are subscribed to the Google Groups "net-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to net-dev+unsubscribe@chromium.org.

--
You received this message because you are subscribed to the Google Groups "Chromium Loading Performance" group.
To unsubscribe from this group and stop receiving emails from it, send an email to loading-dev+unsubscribe@chromium.org.

Adam Rice

unread,
Sep 12, 2016, 11:08:57 PM9/12/16
to Chris Bentzel, David Benjamin, Jake Archibald, Ilya Grigorik, Tom Bergan, Matt Menke, Kenji Baheux, Ojan Vafai, Ryan Sleevi, Chromium Loading Performance, Charles 'Buck' Krasic, Egor Pasko, net-dev
On 13 September 2016 at 05:24, Chris Bentzel <cben...@chromium.org> wrote:
- Since push_promise's are associated with an active stream, we can
  tie that back to an actual URLRequest.

This is currently true, but the proposal to fix the cache lock effectively removes the 1:1 guarantee, at least for cacheable resources.

Ryan Sleevi

unread,
Sep 12, 2016, 11:15:22 PM9/12/16
to Adam Rice, Chromium Loading Performance, Tom Bergan, Chris Bentzel, Kenji Baheux, Egor Pasko, Matt Menke, Ojan Vafai, David Benjamin, Ilya Grigorik, Jake Archibald, Charles 'Buck' Krasic, net-dev

It doesn't actually remove the guarantee, does it? There will always be an initiating request that is draining the stream into the cache, right?

Adam Rice

unread,
Sep 12, 2016, 11:49:39 PM9/12/16
to Ryan Sleevi, Chromium Loading Performance, Tom Bergan, Chris Bentzel, Kenji Baheux, Egor Pasko, Matt Menke, Ojan Vafai, David Benjamin, Ilya Grigorik, Jake Archibald, Charles 'Buck' Krasic, net-dev
On 13 September 2016 at 12:15, Ryan Sleevi <rsl...@chromium.org> wrote:

It doesn't actually remove the guarantee, does it? There will always be an initiating request that is draining the stream into the cache, right?

If you view the first request as special, then the 1:1 relationship comes back. But any concurrent request can write to the cache. In my mind all requests that are consuming the stream become equivalent. I guess this is subjective.

Charles 'Buck' Krasic

unread,
Sep 13, 2016, 1:10:55 PM9/13/16
to Chris Bentzel, David Benjamin, Jake Archibald, Adam Rice, Ilya Grigorik, Tom Bergan, Matt Menke, Kenji Baheux, Ojan Vafai, Ryan Sleevi, Chromium Loading Performance, Egor Pasko, net-dev
... this last sentence seems to have been truncated, and it's not obvious to me what the missing bit was going to say.   I don't see how cache persistence might also impact whether pushed streams can continue after the request they are tied to goes away.   Perhaps I'm not clear on which you mean by "the request they are tied to":  is it the stream that carries the PUSH_PROMISE, or the stream that carries the promised resource?   I'm guessing you meant former, in which case I think cancelling has the same impact with or without cache persistence of H2 push.
 

To unsubscribe from this group and stop receiving emails from it, send an email to loading-dev+unsubscribe@chromium.org.

To post to this group, send email to loadi...@chromium.org.

--
You received this message because you are subscribed to the Google Groups "Chromium Loading Performance" group.
To unsubscribe from this group and stop receiving emails from it, send an email to loading-dev+unsubscribe@chromium.org.

To post to this group, send email to loadi...@chromium.org.

--
You received this message because you are subscribed to the Google Groups "Chromium Loading Performance" group.
To unsubscribe from this group and stop receiving emails from it, send an email to loading-dev+unsubscribe@chromium.org.

To post to this group, send email to loadi...@chromium.org.

--
You received this message because you are subscribed to the Google Groups "Chromium Loading Performance" group.
To unsubscribe from this group and stop receiving emails from it, send an email to loading-dev+unsubscribe@chromium.org.

To post to this group, send email to loadi...@chromium.org.


--
You received this message because you are subscribed to the Google Groups "net-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to net-dev+unsubscribe@chromium.org.

To post to this group, send email to net...@chromium.org.

--
You received this message because you are subscribed to the Google Groups "net-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to net-dev+unsubscribe@chromium.org.

--
You received this message because you are subscribed to the Google Groups "Chromium Loading Performance" group.
To unsubscribe from this group and stop receiving emails from it, send an email to loading-dev+unsubscribe@chromium.org.

To post to this group, send email to loadi...@chromium.org.
Reply all
Reply to author
Forward
0 new messages