Subject: Re: Proposed HTTP SEARCH method update

From: Philippe Mougin <[email-masked]>
Date: Mon, 4 May 2015 08:45:12 +0200

> Le 10 avr. 2015 à 18:00, James M Snell <[email-masked]> a écrit :
> 
> Please see: http://datatracker.ietf.org/doc/draft-snell-search-method/
> 
> Comments welcome.
> 
> - James
> 

James,

I think the introduction chapter fails to correctly characterize the way GET is commonly used to support search operations. 

The draft gives an example ("http://example.org/feed?q=foo&limit=10&sort=-published") and states: "The path identifies the resource processing the query (in this case 'http://example.org/feed') while the query identifies the specific parameters of the search operation."

This description recasts the Web model into an RPC-like system where the http://example.org/feed resource is a little bot we send parameters to in order for it to perform a search. 

But this is not the case. Actually with the GET approach there is no http://example.org/feed resource involved at all in the search operation. The only resource involved is http://example.org/feed?q=foo&limit=10&sort=-published. Typically this resource will be defined as being the result of a specific search computation (or might be defined in more abstract terms). 
This is one of the distinctive feature of the Web: the ability to define ressources as the results of some computations and to perform these computations when a client GET the representations of these resources. This has numerous implications such as the existence of a generic retrieval method, the  ability to support hypermedia by linking to these resources (e.g., a link to the next page of a large search result set), and the ability to support caching of computations' results.

SEARCH, on the other hand, does not make use of this approach. A sensible comparison of SEARCH and GET should take this difference into account, I'd suggest.   

Best,

Philippe Mougin

---

From: Wenbo Zhu <[email-masked]>
Date: Tue, 19 May 2015 15:08:41 -0700

On Sun, May 3, 2015 at 11:45 PM, Philippe Mougin <[email-masked]> wrote:

> I think the introduction chapter fails to correctly characterize the way
> GET is commonly used to support search operations.
>
> The draft gives an example ("
> http://example.org/feed?q=foo&limit=10&sort=-published") and states: "The
> path identifies the resource processing the query (in this case '
> http://example.org/feed') while the query identifies the specific
> parameters of the search operation."
>
> This description recasts the Web model into an RPC-like system where the
> http://example.org/feed resource is a little bot we send parameters to in
> order for it to perform a search.
>
+1

SEARCH with a body feels as bad as "X-HTTP-Method-Override" alike (when one
has to work around the URL encoding limit to turn a GET into POST), and
neither will be safely retried or cached, yet.

GET with a body: to ensure no server will ignore the body, could we expect
the client to generate a unique token in the URL? Also, I think the C-T
alone will be sufficient to categorize a GET as a search request, by
supported proxies/servers.

>
> But this is not the case. Actually with the GET approach there is no
> http://example.org/feed resource involved at all in the search operation.
> The only resource involved is
> http://example.org/feed?q=foo&limit=10&sort=-published. Typically this
> resource will be defined as being the result of a specific search
> computation (or might be defined in more abstract terms).
> This is one of the distinctive feature of the Web: the ability to define
> ressources as the results of some computations and to perform these
> computations when a client GET the representations of these resources. This
> has numerous implications such as the existence of a generic retrieval
> method, the  ability to support hypermedia by linking to these resources
> (e.g., a link to the next page of a large search result set), and the
> ability to support caching of computations' results.
>
> SEARCH, on the other hand, does not make use of this approach. A sensible
> comparison of SEARCH and GET should take this difference into account, I'd
> suggest.
>
> Best,
>
> Philippe Mougin
>

---

From: Phil Hunt <[email-masked]>
Date: Tue, 19 May 2015 16:46:00 -0700

Ok. I’ll bite. Why doesn’t DELETE do the same thing?

Phil

@independentid
www.independentid.com
[email-masked]

> On May 19, 2015, at 3:08 PM, Wenbo Zhu <[email-masked]> wrote:
> 
> 
> 
> On Sun, May 3, 2015 at 11:45 PM, Philippe Mougin <[email-masked] <mailto:[email-masked]>> wrote:
> 
> > Le 10 avr. 2015 à 18:00, James M Snell <[email-masked] <mailto:[email-masked]>> a écrit :
> >
> > Please see: http://datatracker.ietf.org/doc/draft-snell-search-method/ <http://datatracker.ietf.org/doc/draft-snell-search-method/>
> >
> > Comments welcome.
> >
> > - James
> >
> 
> James,
> 
> The draft gives an example ("http://example.org/feed?q=foo&limit=10&sort=-published <http://example.org/feed?q=foo&limit=10&sort=-published>") and states: "The path identifies the resource processing the query (in this case 'http://example.org/feed <http://example.org/feed>') while the query identifies the specific parameters of the search operation."
> 
> This description recasts the Web model into an RPC-like system where the http://example.org/feed <http://example.org/feed> resource is a little bot we send parameters to in order for it to perform a search.
> +1
> 
> SEARCH with a body feels as bad as "X-HTTP-Method-Override" alike (when one has to work around the URL encoding limit to turn a GET into POST), and neither will be safely retried or cached, yet.
> 
> GET with a body: to ensure no server will ignore the body, could we expect the client to generate a unique token in the URL? Also, I think the C-T alone will be sufficient to categorize a GET as a search request, by supported proxies/servers.
>  
> 
> But this is not the case. Actually with the GET approach there is no http://example.org/feed <http://example.org/feed> resource involved at all in the search operation. The only resource involved is http://example.org/feed?q=foo&limit=10&sort=-published <http://example.org/feed?q=foo&limit=10&sort=-published>. Typically this resource will be defined as being the result of a specific search computation (or might be defined in more abstract terms).

---

From: Zhong Yu <[email-masked]>
Date: Tue, 19 May 2015 19:29:02 -0500

> Ok. I’ll bite. Why doesn’t DELETE do the same thing?

Just today, I saw a case [1] where a popular client sends body in
DELETE, and a popular server outright rejects DELETE with body.

In a messy situation like this, we would naturally seek an authority
or an arbitrator. However, the good people of this working group do
not seem to be interested in playing that role. They are more
interested in documenting the best practice that maximize
interoperability. They will give advices and recommendations, but they
are not here to issue rulings or give permissions.

That's probably the misunderstanding here by people who want GET with
body - they think this working group can be an authority that makes it
happen.

Therefore I think this topic (GET+body) is out of the scope. You do
not need to seek permission from the working group, you will not get
any. You will not get an opposite "decree" either. You can go ahead
and do it, against all advices, and if it becomes a huge success, the
working group will accept the reality and document it down.

[1] http://stackoverflow.com/questions/30334776/servlets-3-1-how-to-handle-body-in-delete-request

Zhong Yu
bayou.io

---

From: Phil Hunt <[email-masked]>
Date: Tue, 19 May 2015 21:04:36 -0700

What I was trying to illustrate is that DELETE is also a function and it hasn’t turned the web into RPC.  Why have RPC methods like PATCH PUT and DELETE?

I don’t see how SEARCH “hurts” the web. If GET is supposed to be a web linkable resource and not one with embedded RPC functions like SEARCH or for that matter delete (e.g. GET http://example.com/Users/123?method=delete). In a hypermedia web, don’t we want to keep GET from being overloaded with functions like search?

Phil

@independentid
www.independentid.com
[email-masked]

> On May 19, 2015, at 5:29 PM, Zhong Yu <[email-masked]> wrote:
>

---

From: Amos Jeffries <[email-masked]>
Date: Wed, 20 May 2015 16:43:06 +1200

> are not here to issue rulings or give permissions.

There is a very good reason for that. We do not know of any use case why
a body would be needed on DELETE. Neither do we know of any good reason
why one should be rejected. So it is left as a place where future
standards can define meaning if a case is ever found.

Anyhow the [1] situation is different.

The curl test being run on the server sends it the 9-byte long string
"test.json" - as opposed to the JSON data inside it which the API
expected.  I believe the server 400 message complained about may
actually be the server rejecting invalid data format.

==> Throwing an invalid syntax inside the payload does not help debugging.

If the server were simply rejecting based on any payload existence it
would be clearly violating RFC 7230 section 3.3. Which states a payload
may exist on any method ... "even if the method does not define any use
for a message body.".

"
   The presence of a message body in a request is signaled by a
   Content-Length or Transfer-Encoding header field.  Request message
   framing is independent of method semantics, even if the method does
   not define any use for a message body.
"

RFC 7231 DELETE method only states that there is no defined semantics
for a payload and that sending a custom one may cause problems.

> body - they think this working group can be an authority that makes it

Perhapse. AFAIK we have a good record on setting those bad assumptions
straight though.

> working group will accept the reality and document it down.

Discussing it is very much in scope IMHO. GET is a part of HTTP, any
attempt to give its payload meaning needs scrutiny by persons currently
members of this WG and probably other WG as well.

There have been several proposals that have a lot of merit. Henrys' is
one of the better ones. The problem is how the legacy infrastructure
will handle it. Which is where this WG comes in with the advice. Note
that the change between RFC 2616 and RFC 7231 regarding GET body was
preparation for one day having bodies work on GET. We are just nowhere
near that being ready to use yet.

> [1] http://stackoverflow.com/questions/30334776/servlets-3-1-how-to-handle-body-in-delete-request

Amos

---

From: Julian Reschke <[email-masked]>
Date: Wed, 20 May 2015 08:09:18 +0200

On 2015-05-20 00:08, Wenbo Zhu wrote:
>      > Please see:
>     http://datatracker.ietf.org/doc/draft-snell-search-method/
>      >
>      > Comments welcome.
>      >
>      > - James
>      >
>
>     James,
>
>     I think the introduction chapter fails to correctly characterize the
>     way GET is commonly used to support search operations.
>
>     The draft gives an example
>     ("http://example.org/feed?q=foo&limit=10&sort=-published") and
>     states: "The path identifies the resource processing the query (in
>     this case 'http://example.org/feed') while the query identifies the
>     specific parameters of the search operation."
>
>     This description recasts the Web model into an RPC-like system where
>     the http://example.org/feed resource is a little bot we send
>     parameters to in order for it to perform a search.
>
> +1
>
> SEARCH with a body feels as bad as "X-HTTP-Method-Override" alike (when
> one has to work around the URL encoding limit to turn a GET into POST),
> and neither will be safely retried or cached, yet.

SEARCH can be safely retried, and some pieces of code already know that.

Also: X-HTTP-Method-Override is a hack people used when they couldn't 
use new methods (for some value of "new"). Why does *not* using this 
hack feel to you like doing it? /me confused.

> GET with a body: to ensure no server will ignore the body, could we
> expect the client to generate a unique token in the URL? Also, I think

a) How is this supposed to work? b) Even if it did, how is mangling 
things into the URL ever a good idea?

> the C-T alone will be sufficient to categorize a GET as a search
> request, by supported proxies/servers.

Yes, if you rewrite all components that currently do not expect GET with 
bodies.

 > ...

Best regards, Julian

---

From: Wenbo Zhu <[email-masked]>
Date: Tue, 19 May 2015 23:37:27 -0700

On Tue, May 19, 2015 at 11:09 PM, Julian Reschke <
[email-masked]> wrote:

> Also: X-HTTP-Method-Override is a hack people used when they couldn't use
> new methods (for some value of "new"). Why does *not* using this hack feel
> to you like doing it? /me confused.

SEARCH to me is like a POST, i.e. to make a function call against a
resource. This is what I was suggesting (or voting) ...

> a) How is this supposed to work? b) Even if it did, how is mangling things
> into the URL ever a good idea?

To address the concern that a server that does not look at the GET body may
return an unfiltered resource based on just the URL.

If a client doesn't care about body being ignored, then there is no need to
mingle the URL.

> Yes, if you rewrite all components that currently do not expect GET with
If we can address the safety issue, then I believe GET + body complicates
the Web less than introducing a new method like SEARCH (whose use cases
overlaps with GET in many ways), IMHO.

---

From: Julian Reschke <[email-masked]>
Date: Wed, 20 May 2015 08:41:11 +0200

On 2015-05-20 08:37, Wenbo Zhu wrote:
>     Also: X-HTTP-Method-Override is a hack people used when they
>     couldn't use new methods (for some value of "new"). Why does *not*
>     using this hack feel to you like doing it? /me confused.
>

Well, it's not. One obvious difference is that it already is defined to 
be safe.

> To address the concern that a server that does not look at the GET body
> may return an unfiltered resource based on just the URL.

I still don't see how this affect existing code.

> ...
>     Yes, if you rewrite all components that currently do not expect GET
>     with bodies.
>
> If we can address the safety issue, then I believe GET + body
> complicates the Web less than introducing a new method like SEARCH
> (whose use cases overlaps with GET in many ways), IMHO.

SEARCH is not a new method. The proposal is about extending it to make 
it useful outside WebDAV.

Best regards,Julian

---

From: Wenbo Zhu <[email-masked]>
Date: Wed, 20 May 2015 01:04:29 -0700

On Tue, May 19, 2015 at 11:41 PM, Julian Reschke <
[email-masked]> wrote:

> Well, it's not. One obvious difference is that it already is defined to be
> safe.
>

If a server chooses to return an unfiltered response to "GET /foo", then
"GET /foo/<random-token>" will return a 404 if the client is concerned
about the GET body being dropped along the way.

> SEARCH is not a new method. The proposal is about extending it to make it
> useful outside WebDAV.
>
I don't know WebDAV well enough from the standardization/adoption point of
view to comment on this. My own experience is that a new method like SEARCH
(that aims to replace GET) would require a lot of changes.

This of course is not to argue that we should extend GET just because it
involves less changes to the existing Web.

The proposal would do a better job if it articulates the semantic
significance of a new "read" method, in addition to the HTTP detail, IMHO.

E.g. if we believe there are three types of reads in the view of a client:

1. READ: entity known
2. QUERY: entity unknown, response including the entity ids as well as the
content (possibly as partial/templated objects)
3. MONITOR: state changes **

#2 could be called SEARCH. #1 is GET of course, and we will then ask the
Web to migrate all the existing uses of GET for #2 to using SEARCH.

** #3 is effectively Hanging GET. Polling state changes deserve its own
method too.

---

From: Julian Reschke <[email-masked]>
Date: Wed, 20 May 2015 10:09:05 +0200

On 2015-05-20 10:04, Wenbo Zhu wrote:
>
>
> On Tue, May 19, 2015 at 11:41 PM, Julian Reschke
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Well, it's not. One obvious difference is that it already is defined
>     to be safe.
>
>                  expect the client to generate a unique token in the
>         URL? Also, I
>                  think
>
>

Well, that violates the principles in <https://tools.ietf.org/html/rfc7320>.

>     SEARCH is not a new method. The proposal is about extending it to
>     make it useful outside WebDAV.
>
> I don't know WebDAV well enough from the standardization/adoption point
> of view to comment on this. My own experience is that a new method like
> SEARCH (that aims to replace GET) would require a lot of changes.

a) it is not a new method; it has been defined years ago (as safe), some 
code is already aware of that, and it's in the IANA HTTP method registry.

b) it doesn't aim to replace GET; that would be stupid.

Best regards, Julian

---

From: Zhong Yu <[email-masked]>
Date: Wed, 20 May 2015 04:00:42 -0500

> Anyhow the [1] situation is different.

I commented on your answer on stackoverflow.

---

From: "Roy T. Fielding" <[email-masked]>
Date: Wed, 20 May 2015 10:45:39 -0700

> On May 19, 2015, at 9:04 PM, Phil Hunt <[email-masked]> wrote:
> 

They are not RPC methods.  They have uniform semantics, operate on the target resource,
and are defined in such a way that intermediaries can understand their intended effects.

> I don’t see how SEARCH “hurts” the web. If GET is supposed to be a web linkable resource and not one with embedded RPC functions like SEARCH or for that matter delete (e.g. GET http://example.com/U…

SEARCH does not have uniform semantics (it means different things based on the body),
does not operate on the target resource, and is useless for intermediaries.
However, that isn't why it is bad for the Web.

The reason SEARCH is bad for the Web is because it allows lazy fools to provide
reusable information in a form that doesn't have an associated resource identifier.
It provides the same function as a parametrized GET request without minting a URL.
In other words, it reduces the number of identifiable resources, which reduces
the network effect of linked resources, which harms the Web because it reduces the
power of the resulting information system.

....Roy

---

From: Phil Hunt <[email-masked]>
Date: Wed, 20 May 2015 11:48:38 -0700

Roy,

Thanks for your comments.

We seem to agree on the objectives to enhance the web, but come to a different conclusion. I’m not sure why yet. 

I’m observing GET with filters causing the same “damage” that you are suggesting search does.  I think it is worse because of the need to pass private or confidential information in URLs.  So my first need is to move away from overriding to somewhere else. Headers? Body?  Both have problems and can cause the client to make erroneous assumptions about the results.   

By the way, I found it interesting that people are having the same issue with DELETE on this thread. I’ve also started to run into issues around is delete really always a delete….this pushes the need for parameters on delete.  But I digress away from my use case.

In my use case, I would like to test a condition about an addressable resource rather than return it.  A matching capability is powerful because it exposes an “oracle” function that allows a client to ask a question that is true/false without needing the whole resource or even disclosing the raw information (e.g. an attribute). I’ve considered using match headers, but I worry about knowing the service provider got the headers intact. E.g. if the headers are stripped, the risk is too much information is exposed leading to bad assumptions (that a specific condition was true) on the part of the client.

Over time, I think the use of SEARCH would reduce use of GET yes. But my thinking is it reduces the poor uses of GET. What it is really doing is purifying GET and unloading it from all this overburdening “function" stuff and making the quality of bookmarking and linking better.

Thanks,

Phil

@independentid
www.independentid.com
[email-masked]

> On May 20, 2015, at 10:45 AM, Roy T. Fielding <[email-masked]> wrote:
>

---

From: Julian Reschke <[email-masked]>
Date: Wed, 20 May 2015 21:49:21 +0200

> does not operate on the target resource, and is useless for intermediaries.

It has the same properties as PATCH wrt the payload. Whether it operates 
on the target resource seems to be a matter of definition and opinion.

> power of the resulting information system.

Which is why the spec should recommend that a SEARCH response comes with 
a Content-Location whenever feasible.

Best regards, Julian

---

From: Wenbo Zhu <[email-masked]>
Date: Fri, 22 May 2015 00:00:53 -0700

On Wed, May 20, 2015 at 11:48 AM, Phil Hunt <[email-masked]> wrote:

> We seem to agree on the objectives to enhance the web, but come to a
> different conclusion. I’m not sure why yet.
>
> I’m observing GET with filters causing the same “damage” that you are
> suggesting search does.  I think it is worse because of the need to pass
> private or confidential information in URLs.  So my first need is to move
> away from overriding to somewhere else. Headers? Body?  Both have problems
> and can cause the client to make erroneous assumptions about the results.
>
> By the way, I found it interesting that people are having the same issue
> with DELETE on this thread. I’ve also started to run into issues around is
> delete really always a delete….this pushes the need for parameters on
> delete.  But I digress away from my use case.
>
DELETE with parameters as matching rules etc could really be just a POST,
the universal method for overriding with rpc semantics.

>
> In my use case, I would like to test a condition about an addressable
> resource rather than return it.  A matching capability is powerful because
> it exposes an “oracle” function that allows a client to ask a question that
> is true/false without needing the whole resource or even disclosing the raw
> information (e.g. an attribute). I’ve considered using match headers, but I
> worry about knowing the service provider got the headers intact. E.g. if
> the headers are stripped, the risk is too much information is exposed
> leading to bad assumptions (that a specific condition was true) on the part
> of the client.
>
> Over time, I think the use of SEARCH would reduce use of GET yes. But my
> thinking is it reduces the poor uses of GET. What it is really doing is
> purifying GET and unloading it from all this overburdening “function" stuff
> and making the quality of bookmarking and linking better.
>

Rather than seeing SEARCH as related to GET, maybe what we really need is
just a safe/Idempotent POST (aka rpc). With reduced semantics the benefits
of such a new method may become more obvious.

> >> What I was trying to illustrate is that DELETE is also a function and
> it hasn’t turned the web into RPC.  Why have RPC methods like PATCH PUT and
> DELETE?
> >
> >> I don’t see how SEARCH “hurts” the web. If GET is supposed to be a web
> linkable resource and not one with embedded RPC functions like SEARCH or
> for that matter delete (e.g. GET
> http://example.com/Users/123?method=delete). In a hypermedia web, don’t
> we want to keep GET from being overloaded with functions like search?
> >

---

From: Julian Reschke <[email-masked]>
Date: Fri, 22 May 2015 09:26:33 +0200

On 2015-05-22 09:00, Wenbo Zhu wrote:
> ...
> Rather than seeing SEARCH as related to GET, maybe what we really need
> is just a safe/Idempotent POST (aka rpc). With reduced semantics the
> benefits of such a new method may become more obvious.
> ...

And that new method would be different from SEARCH exactly how?

Best regards, Julian

---

From: Wenbo Zhu <[email-masked]>
Date: Fri, 22 May 2015 10:41:40 -0700

> And that new method would be different from SEARCH exactly how?

Anything that does not apply to POST could be dropped, i.e. not limiting
this method to search-like semantics (which is not well-defined or
understood, and often overlaps with GETs).

And the method name needs a separate discussion ... and maybe SEARCH is
good enough (not because it's already implemented).

---

From: Phil Hunt <[email-masked]>
Date: Fri, 22 May 2015 11:10:38 -0700

It might be useful for someone to profile the HTTP SEARCH draft to show a use case that people can see the trade-offs.

That way we can see an example of some details.

I think SEARCH is sufficiently defined in line with the template established by the other HTTP methods. Over defining at this level can cause more problems than good. 

I have something in mind if people are interested.

Phil

@independentid
www.independentid.com
[email-masked]

> On May 22, 2015, at 10:41 AM, Wenbo Zhu <[email-masked]> wrote:
> 
> 
> 
> On Fri, May 22, 2015 at 12:26 AM, Julian Reschke <[email-masked] <mailto:[email-masked]>> wrote:
> Anything that does not apply to POST could be dropped, i.e. not limiting this method to search-like semantics (which is not well-defined or understood, and often overlaps with GETs). 
> 
> And the method name needs a separate discussion ... and maybe SEARCH is good enough (not because it's already implemented).
> 
> 
> Best regards, Julian
>

---

From: "Appanasamy, Palanivelan" <[email-masked]>
Date: Sat, 23 May 2015 22:52:30 +0530

Looks interesting. But, what exactly is the use case here. Thanks.

-Palanivelan
DMTS-Engg, VerizonLabs

From: Phil Hunt [mailto:[email-masked]]
Sent: Friday, May 22, 2015 11:41 PM
To: Wenbo Zhu
Cc: Julian Reschke; Roy T. Fielding; Zhong Yu; Philippe Mougin; James Snell; [email-masked]
Subject: Re: Proposed HTTP SEARCH method update

Phil

@independentid
www.independentid.com<http://www.independentid.com>
[email-masked]<mailto:[email-masked]>

On May 22, 2015, at 10:41 AM, Wenbo Zhu <[email-masked]<mailto:[email-masked]>> wrote:

On Fri, May 22, 2015 at 12:26 AM, Julian Reschke <[email-masked]<mailto:[email-masked]>> wrote:

Best regards, Julian

---

From: Phil Hunt <[email-masked]>
Date: Sat, 23 May 2015 11:10:54 -0700

Confused. That was what I was proposing to do. Give you a profile that would serve as a use case to discuss. 

Phil

> On May 23, 2015, at 10:22, Appanasamy, Palanivelan <[email-masked]> wrote:
> 
> On Fri, May 22, 2015 at 12:26 AM, Julian Reschke <[email-masked]> wrote:

---

From: Wenbo Zhu <[email-masked]>
Date: Tue, 26 May 2015 16:54:48 -0700

On Fri, May 22, 2015 at 11:10 AM, Phil Hunt <[email-masked]> wrote:

> It might be useful for someone to profile the HTTP SEARCH draft to show a
> use case that people can see the trade-offs.
>
> I think SEARCH is sufficiently defined in line with the template
> established by the other HTTP methods. Over defining at this level can
> cause more problems than good.
>
I think use cases would be useful.

Up to this point, the questions I would ask are:
1. Why can't the SEARCH method be extended to cover any read-only
computation, e.g. a calculate service?
2. SEARCH, as briefly defined in the proposal**, how is it sufficiently
different from GETs?
3. The issue of URL length limit: is it a practical issue even under the
exact semantics of a GET?

** "The SEARCH method is used to initiate a server-side search." ... "The
body of the request defines the query." ...

---

From: Phil Hunt <[email-masked]>
Date: Tue, 26 May 2015 17:00:56 -0700

In line...

Phil

> On May 26, 2015, at 16:54, Wenbo Zhu <[email-masked]> wrote:
> 
> 
> 
> 1. Why can't the SEARCH method be extended to cover any read-only computation, e.g. a calculate service?

Not sure we want to turn this into an execute method. 
> 2. SEARCH, as briefly defined in the proposal**, how is it sufficiently different from GETs? 
GET reverts to its proper use of returning a single resource. 

We would be unloading get and making it a higher quality link. 

Filters on get end up creating more low-quality links to the same resource. 
> 3. The issue of URL length limit: is it a practical issue even under the exact semantics of a GET?
> 
> ** "The SEARCH method is used to initiate a server-side search." ... "The body of the request defines the query." ...

Bigger issue is exposure of sensitive information in URL which gets recorded in many logs where it should not appear.

---

From: Wenbo Zhu <[email-masked]>
Date: Thu, 28 May 2015 00:05:07 -0700

> Filters on get end up creating more low-quality links to the same
None of these mandates a request body. Also, "single resource", "link
quality" don't seem to be strict enough: e.g.  a collection of items of a
query response could still be treated as a useful/single "resource".

> Bigger issue is exposure of sensitive information in URL which gets
> recorded in many logs where it should not appear.
>
Yes. Practically #1 and #3 have been bigger issues to me, e.g. WebDAV has
REPORT ...