Re: HTTP/2 push header validation

FYI: Apache httpd copies the "Accept-*" headers from the original
request to the PUSH_PROMISE and uses them also for generating the
pushed response.

The rationale is that the client would use the same Accept-* 
headers when accessing the pushed resource (an assumption) and
thus better satisfy caching constraints.

Would be nice to get some feedback from UAs on this.

Cheers,

Stefan

> Am 08.11.2017 um 16:53 schrieb Bence Béky <bnc@chromium.org>:
> 
> Hi,
> 
> I'm working on stricter header validation of HTTP/2 pushed streams in
> Chrome and wanted to give a heads up, and also to solicit feedback
> (support if you have a use case, or push back if you think it's going
> to break your product).  Currently Chrome matches GET requests to
> pushed streams by URL only, disregarding the Vary header.  I plan on
> obeying the Vary header, resulting in some requests not being matched
> with pushes that currently would be (arguably incorrectly) matched.
> 
> For comparison,
> https://jakearchibald.com/2017/h2-push-tougher-than-i-thought/#items-in-the-push-cache-should-be-matched-using-http-semantics-aside-from-freshness
> reports that as of this May, Firefox and Edge both ignored the Vary
> header for HTTP/2 pushed streams, along with the current behavior of
> Chrome.  Safari already obeyed the Vary header, which is the proposed
> behavior for Chrome.
> 
> There is already some public discussion about this proposed change at
> https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/5_aP_stqndw.
> Notably the idea arose whether this is worth doing properly, or Chrome
> could just drop every pushed stream containing the Vary response
> header.  It is suspected that most pushes will have Vary:
> accept-encoding in the response, making it necessary to interpret Vary
> properly.  I'll measure Vary headers in pushed responses from Chrome's
> point of view in the wild and circle back in a few weeks with some
> data.
> 
> Then there is also the issue of Range responses.  One question is
> whether exact matching is enough or there would be a use case for
> using a pushed stream to serve a request for a subrange (like it is
> done in the cache).  The other is if allowing multiple pushes for the
> same URL would make sense, for example, for the use case of multiple
> non-overlapping ranges.  In this case, some extra logic might be
> needed to reject the exact same response being pushed multiple times,
> as it is suspected that some server implementations might currently
> do.
> 
> Cheers,
> 
> Bence
>

Received on Thursday, 9 November 2017 09:10:19 UTC