Re: what constitutes an "invalid" content-length

In this case, it's a fairly popular site in Norway (mytribe.no) running 
through a relatively recent nginx (1.8.1 Jan 2016).

I would have expected that the static css file would come from the 
reverse proxy cache and so should have had C-L validated/fixed, maybe it 
didn't and the bad C-L is coming from the back end.

But in any case, this isn't really an example of an old or legacy site.

I guess it's always a problem when any single browser makes a stand.  
What we need is for all the browsers to do the same thing.  Then the 
users can't say "but it works in xxx browser", and site operators have 
no choice but to fix it.

Maybe there's some security angle that would prompt a harder look at 
this.

Regards

Adrien



------ Original Message ------
From: "Patrick McManus" <mcmanus@ducksong.com>
To: "Adrien de Croy" <adrien@qbik.com>
Cc: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Sent: 13/07/2016 2:19:32 a.m.
Subject: Re: what constitutes an "invalid" content-length

>H1 Framing is badly broken in practice.. we tried to tighten up what 
>Firefox would accept about a year ago and it was basically a disaster 
>that was reverted. Some of the story is in the 300+ comments in 
>https://bugzilla.mozilla.org/show_bug.cgi?id=237623
>
>You can set network.http.enforce-framing.http1 to true if you'd like a 
>more error filled web and lean on content-providers. That didn't get us 
>very far because we're talking about the tail of the Internet - 
>basically one off gateways to old legacy machinery like pdf generators, 
>and broken dynamic gzip modules and stuff that insists 304 should have 
>a body. While that doesn't dominate the Internet it does cause 
>persistent breakage that a high number of people will see (and be 
>frustrated by) over a fairly short period of time. Its extremely well 
>baked in at this point and its very hard to fix - we're much better off 
>enforcing strict standards around h2 and encouraging a migration than 
>beating our heads against the h1 legacy imo.
>
>I know there is some talk of trying to remove support for 0.9 in 
>another browser. I sincerely wish that team nothing but happiness, good 
>karma, and good luck in their trail blazing - but I wonder if its going 
>to go a similar route.
>
>-Patrick
>
>On Tue, Jul 12, 2016 at 9:31 AM, Adrien de Croy <adrien@qbik.com> 
>wrote:
>>Hi all
>>
>>just dealing with a site that sends more payload data than is 
>>indicated in the Content-Length header.
>>
>>If the browser connects directly, the page loads fine, if via the 
>>proxy, the proxy is truncating the length to that advertised and the 
>>client isn't displaying a page (of course this is the .css file).
>>
>>RFC7230 sections 3.3.2 (Content-Length), 3.3.3 (Message body length), 
>>and 3.3.4 (Handling incomplete messages) only contemplate issues 
>>around Content-Length specifying more bytes than are received, not 
>>fewer.
>>
>>I guess one could argue that a wrong C-L value is "invalid", but it's 
>>not clear that invalid in this context simply means it doesn't parse, 
>>or is otherwise non-compliant with the ABNF.
>>
>>So, it's not clear what the browser and/or proxy response should be.  
>>If we deem a wrong value to be "invalid" (s3.3.3 para 4), a client is 
>>supposed to discard the response.  This isn't happening.
>>
>>For the proxy, it only sees that the content length is wrong once it 
>>receives too many bytes.  By this stage, the horse has bolted so it 
>>cannot really comply either.
>>
>>I would expect it's in everyone's best interest if sites that have 
>>broken framing are forced to be fixed.  This won't happen if browsers 
>>"just work" for the site.
>>
>>Is there a special behaviour we should agree on for such cases?
>>
>>Regards
>>
>>Adrien de Croy
>