- From: Stefan Eissing <stefan.eissing@greenbytes.de>
- Date: Thu, 9 Nov 2017 10:09:46 +0100
- To: Bence Béky <bnc@chromium.org>
- Cc: HTTP <ietf-http-wg@w3.org>
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