- From: Willy Tarreau <w@1wt.eu>
- Date: Mon, 12 Aug 2019 07:49:53 +0200
- To: RFC Errata System <rfc-editor@rfc-editor.org>
- Cc: fielding@gbiv.com, julian.reschke@greenbytes.de, ben@nostrum.com, aamelnikov@fastmail.fm, adam@nostrum.com, mnot@mnot.net, patrick.ducksong@gmail.com, tpauly@apple.com, andersk@mit.edu, ietf-http-wg@w3.org
On Sun, Aug 11, 2019 at 07:27:30PM -0700, RFC Errata System wrote: > The following errata report has been submitted for RFC7231, > "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content". > > -------------------------------------- > You may review the report below and at: > https://www.rfc-editor.org/errata/eid5806 > > -------------------------------------- > Type: Technical > Reported by: Anders Kaseorg <andersk@mit.edu> > > Section: 4.3.7 > > Original Text > ------------- > A server MUST generate a Content-Length field with a value of "0" if no > payload body is to be sent in the response. > > Corrected Text > -------------- > If no payload body is to be sent in the response, a server MUST > generate a status code of 204 (No Content) or a Content-Length field > with a value of "0" (but not both). > > Notes > ----- > The original text contradicts RFC 7230 §3.3.2: "A server MUST NOT send a > Content-Length header field in any response with a status code of 1xx > (Informational) or 204 (No Content)", unless the intention was to disallow > all 204 responses to OPTIONS requests, which I assume it was not. Indeed, it seems valid to me. With this said, I don't know how common it is to respond with 204 to an OPTIONS request given that 204 is reportedly cacheable by default (6.3.5) while OPTIONS is said not to be. Thus more confusion may arise on this point as well. Willy
Received on Monday, 12 August 2019 05:50:50 UTC