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
>