- From: Michael Sweet <msweet@apple.com>
- Date: Wed, 29 Apr 2015 08:15:31 -0700
- To: Eric Covener <covener@gmail.com>
- Cc: henry.story@bblfish.net, Willy Tarreau <w@1wt.eu>, HTTP Working Group <ietf-http-wg@w3.org>
Eric, > On Apr 29, 2015, at 6:10 AM, Eric Covener <covener@gmail.com> wrote: > > On Wed, Apr 29, 2015 at 8:46 AM, Michael Sweet <msweet@apple.com> wrote: >> i.e., RFC 2616 forbids including a message body for methods that do not define one, while RFC 7230 allows it. > > "A message-body MUST NOT be included in a request if the specification > of the request method (section 5.1.1) does not allow sending an > entity-body in requests." > > IMO "does not allow" and "does not define" are quite a bit far apart. Regardless of how you want to interpret RFC 2616, RFC 723x is now the "law of the land" WRT HTTP, and it does not make this statement - I simply pointed out that this is a change between the two specs, and that there is a lot of room for interpretation in both specs. GET is not defined as accepting a message body in the request, in either RFC 2616 or RFC 7231. And in fact RFC 7231 has the following to say: A payload within a GET request message has no defined semantics; sending a payload body on a GET request might cause some existing implementations to reject the request. which supports what I have said so far: doing a GET with a request body is probably not a good idea without some way for the server to indicate that such semantics are supported by the server's GET implementation. If you want to extend GET for searches/queries, you need to do it in a way that doesn't break existing servers and the semantics of GET - probably through a new header that allows the client to discover the server supports the extension, with a corresponding Content-Type in the GET request to indicate the type of query present in the message body. _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair
Received on Wednesday, 29 April 2015 15:16:02 UTC