- From: Patrick McManus <mcmanus@ducksong.com>
- Date: Wed, 15 Feb 2017 08:33:57 -0500
- To: Cory Benfield <cory@lukasa.co.uk>
- Cc: Poul-Henning Kamp <phk@phk.freebsd.dk>, Mark Nottingham <mnot@mnot.net>, Adrien de Croy <adrien@qbik.com>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
- Message-ID: <CAOdDvNqYX8ZEZLFiLYSQr+ov4qMtCd2VnKScfM5=sDUKUEo62w@mail.gmail.com>
On Wed, Feb 15, 2017 at 5:37 AM, Cory Benfield <cory@lukasa.co.uk> wrote: > So I don’t really consider this a new class of problems, so much as H2 > giving us the solution to this problem. In my view, for H2 implementations > should either treat the content-length is an absolute right-or-wrong, or > just ignore it completely. Either works, and implementations may decide > which they prefer. I suspect most will go for the former (except browser > UAs, who are generally speaking inclined to tolerate most misbehaviour if > possible). content-length in h2 doesn't define the framing - as Cory points out we are saved from the sad h1 reality by consistent and simple framing rules in h2. It should just be used informationally - e.g. for drawing download thermometers. or making sensible pre-allocations/quota checks (assuming you don't also make a TOCTOU bug out of it). Firefox treats all h2 transactions as if they were h1 chunked. with the exception of the anecdote that started this thread (funny!), I'm not aware of anyone actually trying to publish incorrect CL and call it compliant. The exceptions in implementations that allow consuming such behavior are there as explicit choices about bugwards-interop, changing spec language wrt h1 isn't going to change those decisions. The implementors already either understand the tradeoffs or made an unintentional mistake in generating the crud in the first place. This however is a reason why the language in h2 is much stronger - so that early interop would force implementations to clean up their act during the launch phase. I'm sure that entropy will inevitably win, but the road is considerably cleaner for a while. I will say that during h2 dev chrome firefox and msft were all vigilant in situations where there was a bug report from some new content source of "it works in A, but not in B" (which happened for all variations of A and B) and the root cause turned out to be a sender violation with a more lenient variant allowing it.. the resolution was always changes that created a stricter enforcement across the board. (i.e. now it doesn't work in A or B!) this applies to more than browsers of course, but reporters love to play us off against each other. That's a lesson to be learned for quic - and its a lesson that we should stay vigilant in h2 even though it is now deployed. Otherwise entropy wins and you end up with defacto specs. This is a good forum to raise those issues as they come up. -Patrick
Received on Wednesday, 15 February 2017 13:34:37 UTC