- From: Amos Jeffries <squid3@treenet.co.nz>
- Date: Sat, 21 Jul 2012 11:31:45 +1200
- To: ietf-http-wg@w3.org
On 21/07/2012 7:20 a.m., Julian Reschke wrote: > On 2012-07-20 21:09, Zhong Yu wrote: >> Some small problems with the spec: >> >> http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-20#section-4.6.14 >> >> >> The meaning of 417 is vague. If a server isn't interested in the body >> of a request with "Expect: 100-continue", SHOULD the server send 417? >> I don't think so, there can be many reasons why the server isn't >> interested in the body; it should send a specific response code >> reflecting the real reason, e.g. 403. >> >> Server's intent that the client does not send the body is already >> expressed by not sending 100 before the final code; there's no value >> in 417 repeating that intent. >> >> Then 417 is only useful when the server cannot understand the >> expectation. > > Indeed. See also: > > "Upon receiving a request which includes an Expect header field with > the "100-continue" expectation, an origin server MUST either respond > with 100 (Continue) status code and continue to read from the input > stream, or respond with a final status code. The origin server MUST > NOT wait for the request body before sending the 100 (Continue) > response. If it responds with a final status code, it MAY close the > transport connection or it MAY continue to read and discard the rest > of the request. It MUST NOT perform the request method if it returns a > final status code." -- > <http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p1-messaging-latest.html#rfc.section.6.4.3> > >> http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-20#section-6.4.3 >> >> Requirements for HTTP/1.1 origin servers: >> ... (the server) MUST NOT perform the request method if it returns a >> final status code (without a prior 100) >> >> That's too harsh, isn't it? Though the server doesn't need to read the >> request body, that doesn't mean the request cannot be served. Maybe >> the request headers contains sufficient information, and the request >> body is just a redundancy measure. > > That appears to be an edge case not worth optimizing for. > In isolation this appears to be translatable as: MUST NOT perform method if final status (200) is returned without prior 100-continue (ie HTTP/1.0 hop erased Expect) Amos
Received on Friday, 20 July 2012 23:32:20 UTC