Re: Proposed HTTP SEARCH method update

Thank you Phil. Great way to explain.
On May 11, 2015 2:21 PM, "Phil Hunt" <phil.hunt@oracle.com> wrote:

> 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> 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) is a work around works, but seems
> kludgy.  Access control systems have to know that
> https://example.com/Users/<id>/.search is the same resource as
> https://example.com/Users/<id>
>
> 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
> phil.hunt@oracle.com
>
>
>
>