Re: what constitutes an "invalid" content-length

On Tue, Jul 12, 2016 at 8:21 PM, Mark Nottingham <mnot@mnot.net> wrote:

> 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?"



we don't actually do that - it doesn't mesh well with how fast we want to
either recycle connections or notify the in-browser consumer (i.e. the
parser, the decoder, etc..) about EOM.

If doing persistent connections - 'extra' bytes get silently thrown away as
leading garbage on the subsequent response... otherwise we just read to EOF
and ignore C-L/Chunked. (A surprising portion of the servers that get C-L
wrong are closing the connection anyhow) as a message delimiter.

My biggest frustration in this space is actually around the unreliability
of truncation detection. *lots* of non persistent h1 transactions that seem
to be strongly framed come up short by some criterion - c-l, missing a
zero-chunk terminator, or unclean close termiations like RST or TLS Alerts.
For all practical purposes you need to silently accept what you have
received. Of course some actual network driven truncations look exactly the
same. That's created a problem in the file downloader (do I show a retry or
not?) and there is a security implication as well (do you really need all
that javascript?) when carried over a non-authenticated transport (or when
we are forced to ignore some aspects of it.)