- From: Roy T. Fielding <fielding@gbiv.com>
- Date: Thu, 15 Sep 2016 15:21:57 -0700
- To: Willy Tarreau <w@1wt.eu>
- Cc: Kazuho Oku <kazuhooku@gmail.com>, Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
On Sep 15, 2016, at 3:15 PM, Roy T. Fielding <fielding@gbiv.com> wrote: > >> On Sep 15, 2016, at 3:06 PM, Willy Tarreau <w@1wt.eu> wrote: >> >> Hi Roy, >> >> On Thu, Sep 15, 2016 at 01:13:01PM -0700, Roy T. Fielding wrote: >>>> I'd be tempted to simplify this as "if you're sending a body even an empty >>>> one, announce its size in content-length". Methods like POST and PUT expect >>>> a message body so that should always be done. >>> >>> No. It is never a good idea to send extra information just in case you >>> might encounter a broken server. It is better to send less information and >>> let people fix their own broken code. Otherwise, the Internet becomes a >>> cesspool of poorly imagined cases that are far less likely to exist than >>> the keel-over-waiting-for-the-extra-TCP-packets cases that always exist. >> >> But if c-l:0 is supposed to be exactly equivalent to no c-l, then what's >> the purpose of status code 411 ? My understanding no c-l means there is >> no body while c-l: 0 means the body is empty, both of which are totally >> equivalent from a framing perspective, but not necessarily from a >> semantics perspective. >> >> Regards, >> Willy > > CL is present only for message framing and can be removed at any hop. > CL:0 versus no CL has no semantic distinction whatsoever, so any recipient > that chooses to interpret it as a distinction is inherently broken. And the purpose of 411 is to say that Transfer-Encoding chunked isn't useful because the resource requires a fixed length before it can be invoked (CGI). [Actually, I think most servers attempt to read at least one buffer full of body as chunked, to see if it happens to be a short body, and will internally translate that to a fixed CL before continuing; otherwise, sending 411.] ....Roy
Received on Thursday, 15 September 2016 22:22:22 UTC