- 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>
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. Willy
Received on Wednesday, 18 March 2020 04:05:16 UTC