Re: Proposed HTTP SEARCH method update

Henry,

Authors of the HTTP specs are advising passing a body with GET is a very bad idea. This is mostly for historical reasons.

Julian Reschke also felt that the use of headers for queries was also ill-advised given that a lot of firewalls may manipulate or block headers. The concern is unanticipated consequences.  E.g. the nature of the GET changes because the header or the body is missing and the server mistakenly releases information because the operation becomes treated as a plain get.  E.g. the return of a resource was to be subject to some filter condition and the client is fooled into thinking the condition was true.

There are also (whether founded or not) concerns about space limitations in headers and URLs. Though I have to wonder, if your filter is that long, should the filter be processed?  E.g. why pass a public key when you can pass its thumbprint.

By using a new HTTP method, then the failure due to lack of support for the method becomes guaranteed. A server that does not support or does not get the request (because of a firewall) will not unintentionally continue processing the request.  

Phil

@independentid
www.independentid.com
phil.hunt@oracle.com

> On May 10, 2015, at 5:04 AM, henry.story@bblfish.net wrote:
> 
> 
>> On 1 May 2015, at 18:12, Phil Hunt <phil.hunt@oracle.com <mailto:phil.hunt@oracle.com>> wrote:
>> 
>> One of the use cases I am having difficulty is what I will call “MATCH”.  This is a bit different from doing a system wide search as much of the discussion has focused on.  In this case, we want to test if a certain filter condition is true for a given resource and optionally return some attributes (or nothing at all).
> 
> yep .
> 
>> 
>> We talked about this in developing the SCIM protocol.  We decided to go with the POST option since a SEARCH method would be long term (C below).
>> 
>> I’ve looked at a number of approaches on this case:
>> 
>> A. A GET is inappropriate because the filter condition cannot be passed on the URL.  It would be ok if it could be passed in the BODY, but I hear that’s bad.
> 
> There are two possibilities here, both allowed by the current spec.
>  1) GET with Query: and Query-Type: header ( the second one giving the mime type of the header
>  2) GET with Content-Type header and body.
> 
> There have been no criticisms of (1), only of (2) . 
> (2) does not go against any of the more recent specs - it is even allowed, and probably works for most servers. It should be left open for the longer term after studies if it really is problematic and in what circumstances. But 1) is a good fallback position.
> 
> The fallback position of both is that if the server does not understand the headers or body, it returns the value it would have returned on a plain GET. This actually works: you can try it on any web server to see :-)
> 
> The main problem with a GET is when the resource is to all intents and purposes infinitely long and one really never wants to do a GET on the resource. In that case it is important to be able to run SEARCH ( or some other verb such as QUERY). Could it be that some resource just offer SEARCH/QUERY and not GET in that case?
> 
> 
>> B. A POST is problematic because it should be to create or replace the resource.  How does the server detect the intended operation?
>> 
>> C. A POST + a path extension (e.g., “/.search” giving   https://example.com/Users/<id>/.search <https://example.com/Users/%3Cid%3E/.search>) is a work around works, but seems kludgy.  Access control systems have to know that https://example.com/Users/<id>/.search <https://example.com/Users/%3Cid%3E/.search> is the same resource as https://example.com/Users/<id> <https://example.com/Users/%3Cid%3E>
>> 
>> D. A POST to /search can also work, but makes for a more complex operation as now we are not talking about an operation based on a URL.  It also may complicate access control since the resource being queried isn’t part of the URL.
>> 
>> I recall talking to Julian about if-match headers…I can’t remember the pros/cons we talked about. But I do think that the semantics shouldn’t change. I can see adding if-match conditions to a SEARCH command as being useful. I think overloading these might be more complexity.
>> 
>> I think this is a case that more clearly shows why “SEARCH” is useful. 
>> 
>> Phil
>> 
>> @independentid
>> www.independentid.com <http://www.independentid.com/>phil.hunt@oracle.com <mailto:phil.hunt@oracle.com>
>