W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2020

Re: Fwd: New Version Notification for draft-nottingham-bikeshed-length-00.txt

From: Willy Tarreau <w@1wt.eu>
Date: Wed, 18 Mar 2020 05:04:57 +0100
To: Mark Nottingham <mnot@mnot.net>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <20200318040457.GA12317@1wt.eu>
Hi Mark,

On Wed, Mar 18, 2020 at 12:29:24PM +1100, Mark Nottingham wrote:
> FYI, as discussed in <https://github.com/httpwg/http-core/issues/276>.
> Prettier version at <https://mnot.github.io/I-D/bikeshed-length/>.

Interesting. I've also thought many times "too bad we don't have a distinct
header field for this one". I too think that something advisory may be
very useful, but I'm also seeing some misuse. Typically some recipients
might decide to allocate a large enough memory area to receive the
advertised contents, and this will be used to DoS some servers by sending
very large lengths (as we used to see with C-L in the past).

Despite this I still think that if we word it appropriately (i.e. "do not
trust it") and if we make sure it is never correlated to the effective
length, we could easily address potential issues and make it useful.

I think that it could be worded as suggesting that even the sender does
not necessarily precisely know the exact value to place there. For example
if a client needs to decompress a file before sending it, it could
arbitrarily advertise 10 times its compressed size. Similarly a client
uploading a log file could advertise the current size plus a small
margin, knowing that the file might continue to grow during the transfer.

If presented like this it should be clear that the recipient must not trust
it for anything but a progress bar or 413 and that could be very useful.

BTW I wouldn't say "it is not allowed to occur in trailer sections" since
it's not expected to have any particular meaning there, and adding a new
rule will only make its processing more complicated, I'd simply say that
it's pointless to place it there and that it may be ignored.

Received on Wednesday, 18 March 2020 04:05:16 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 18 March 2020 04:05:17 UTC