- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Fri, 20 Jul 2012 21:20:06 +0200
- To: Zhong Yu <zhong.j.yu@gmail.com>
- CC: Willy Tarreau <w@1wt.eu>, Roberto Peon <grmocg@gmail.com>, James M Snell <jasnell@gmail.com>, Amos Jeffries <squid3@treenet.co.nz>, Osama Mazahir <OSAMAM@microsoft.com>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>, Poul-Henning Kamp <phk@phk.freebsd.dk>, Adrien de Croy <adrien@qbik.com>, Gabriel Montenegro <Gabriel.Montenegro@microsoft.com>
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. Best regards, Julian
Received on Friday, 20 July 2012 19:20:58 UTC