W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2017

HTTP/2 push header validation

From: Bence Béky <bnc@chromium.org>
Date: Wed, 8 Nov 2017 10:53:27 -0500
Message-ID: <CACMu3to-oHddpB40iKgznQZUD=5TS84Pq9bnV5cQEeoR2qBTqA@mail.gmail.com>
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

This archive was generated by hypermail 2.3.1 : Wednesday, 8 November 2017 15:54:15 UTC