Re: can GET do for QUERY? extending Partial Content

> On 29 Apr 2015, at 17:15, Michael Sweet <msweet@apple.com> wrote:
> 
> 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.

yes, something like the Accept-Patch header defined in RFC-5987 [1] or the Accept-Post header defined in LDP [2] . One could define an Accept-Get header returned on Options, HEAD and GET. 

Extending behavior always comes by extending parts that are undefined. This can always lead to breakages at first. To avoid the breakages either clients have to know out of band that a or service supoorts it, or an Accept-GET header is required. In the much longer term the fact that this behavior is defined, should make it possible to avoid this extra step. 


Henry


[1] https://tools.ietf.org/html/rfc5789
[2] http://www.w3.org/TR/ldp/#header-accept-post

> 
> _________________________________________________________
> Michael Sweet, Senior Printing System Engineer, PWG Chair
> 

Social Web Architect
http://bblfish.net/

Received on Wednesday, 29 April 2015 15:33:04 UTC