- From: Zhong Yu <zhong.j.yu@gmail.com>
- Date: Fri, 20 Jul 2012 14:09:24 -0500
- To: Willy Tarreau <w@1wt.eu>
- Cc: Roberto Peon <grmocg@gmail.com>, James M Snell <jasnell@gmail.com>, Amos Jeffries <squid3@treenet.co.nz>, Osama Mazahir <OSAMAM@microsoft.com>, Julian Reschke <julian.reschke@gmx.de>, "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>
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. 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. Zhong Yu
Received on Friday, 20 July 2012 19:09:51 UTC