- From: Willy Tarreau <w@1wt.eu>
- Date: Thu, 15 Sep 2016 09:00:00 +0200
- To: Kazuho Oku <kazuhooku@gmail.com>
- Cc: Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
Hi Kazuho, On Thu, Sep 15, 2016 at 09:09:42AM +0900, Kazuho Oku wrote: > Hi, > > Thank you very much for the clarification. > > So to paraphrase, the general rule for handling request body is > defined in section 3.3.3 of RFC 7230 as: > > 6. If this is a request message and none of the above are true, then > the message body length is zero (no message body is present). > > which means that in HTTP, there is no distinction between a request > with zero-length body and a request _without_ a body. > > That means it is completely up to the HTTP client to whether or not to > send `content-length: 0` for such requests, though each implementation > may decide to send or not, depending on interoperability issues that > might exist. In fact there exists a corner case, some servers return 411 in response to a POST without a content-length. Thus I'd suggest that the client always emits the content-length when it considers that semantically it emits a body even if it's empty. Let's imagine a disk backup tool uploading files over HTTP, using a few header fields to pass file name, permissions and various meta-data. Some files may be empty, and regardless of this they are sent. In this case it totally makes sense to emit "content-length: 0". 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. Regards, Willy
Received on Thursday, 15 September 2016 07:00:29 UTC