- From: Amos Jeffries <squid3@treenet.co.nz>
- Date: Mon, 12 Aug 2019 20:05:52 +1200
- To: ietf-http-wg@w3.org
On 12/08/19 5:49 pm, Willy Tarreau wrote: > 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. Ditto. > 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. > That should not be an issue since the 204 caching is explicitly "unless otherwise indicated by the method definition". Amos
Received on Monday, 12 August 2019 08:06:49 UTC