- From: Adrien de Croy <adrien@qbik.com>
- Date: Tue, 26 Oct 2010 10:45:05 +1300
- To: Julian Reschke <julian.reschke@gmx.de>, HTTP Working Group <ietf-http-wg@w3.org>
On 26/10/2010 4:23 a.m., Julian Reschke wrote: > On 11.06.2009 11:58, Roy T. Fielding wrote: >> On Jun 11, 2009, at 11:39 AM, Julian Reschke wrote: >> >>> Mark Nottingham wrote: >>>> We have a similar situation around request bodies -- >>>>> A message-body MUST NOT be included in a request if the >>>>> specification of the request method (Section 2 of [Part2]) >>>>> explicitly disallows an entity-body in requests. >>>> What I'd like to do in both cases is make it more apparent that the >>>> list of exceptions is closed, by not predicating it on an external >>>> MUST NOT. >>> >>> That's a good point. >>> >>>> In the case for requests, I think the entire sentence disappears, >>>> because we have not specified any method that disallow request bodies >>>> (unless one of the many WebDAV methods places this requirement on >>>> requests, and even then...). >>> >>> Nope, WebDAV doesn't do that. >>> >>> From RFC2616 I see two potential candidates: (1) TRACE (which uses the >>> same terminology as the 205 status that started this thread: "MUST NOT >>> include an entity"), and (2) CONNECT (?). >> >> There are no candidates. Any change to the message parsing algorithm >> would require a major bump in HTTP version. in relation to CONNECT, I think we can justify giving it special treatment for several reasons: 1. It's not part of the original spec, but an extension designed to enable arbitrary connectivity through a compliant proxy 2. It already has very specific requirements which make it very un-HTTP-like (e.g. the proxy connects and gets out of the way), no HTTP is (necessarily) used upstream. In fact in our code-base the special handling for CONNECT is much more involved than for say HEAD. I find it hard to conceive of a proxy that wouldn't treat CONNECT as a very special case already. In the one case where I've seen a body on a CONNECT method (blu-ray player), if that body were passed through to the end server, it broke things. If you allow bodies on a method, then Content-Length is required. I don't see any Content-Length headers on CONNECT messages, so current browsers would become incompatible. Can we allow Transfer-Encoding: chunked on CONNECT? IMO we can't. Adrien > > ... > > In the meantime, the parsing section in Part 1 has been revised. > > I believe we still need to rephrase the description of 205, currently > saying: > > "The response MUST NOT include a message-body." > > Proposal: > > "The message-body included with the response MUST be empty." > > (<http://trac.tools.ietf.org/wg/httpbis/trac/attachment/ticket/88/i88.diff>) > > > Best regards, Julian >
Received on Monday, 25 October 2010 21:45:44 UTC