- From: Bence Béky <bnc@chromium.org>
- Date: Wed, 8 Nov 2017 10:53:27 -0500
- To: HTTP <ietf-http-wg@w3.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 Wednesday, 8 November 2017 15:54:12 UTC