Re: what constitutes an "invalid" content-length

Hey Patrick,

Just curious -- is the heuristic you use more than just "if we only have one outstanding request, keep reading bytes and consider them part of the response?"

Cheers,


> On 13 Jul 2016, at 12:19 AM, Patrick McManus <mcmanus@ducksong.com> wrote:
> 
> 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
> 

--
Mark Nottingham   https://www.mnot.net/

Received on Wednesday, 13 July 2016 00:21:36 UTC