Subject: GET with body / SEARCH

From: Matthew Kerwin <[email-masked]>
Date: Fri, 30 Mar 2018 21:03:33 +1000

Hi everyone,

I just noticed Mark opened [GET
w/body](https://github.com/httpwg/http-extensions/issues/546), which
reminds me again of draft-snell-search-method. It came up for me back
in January, but then other things got in the way.

Do you think there's still a strong motivation to get a
general-purpose `SEARCH` RFC published?  Is it something the WG would
be interested in taking on?

Cheers
-- 
  Matthew Kerwin
  https://matthew.kerwin.net.au/

---

From: Guilherme Hermeto <[email-masked]>
Date: Fri, 30 Mar 2018 10:37:29 -0700

I would definitely like to see that, but I think we can go even further and
have a FETCH method, as the one described in CoAP (
https://core-wg.github.io/etch/#intro-fetch). The CoAP FETCH method was
based on the SEARCH proposal from J. Snell (
https://tools.ietf.org/html/draft-snell-search-method-00), but would be
broader, addressing the issue that SEARCH would be too specific.

Thoughts?

---

From: James M Snell <[email-masked]>
Date: Sat, 31 Mar 2018 05:45:05 +0000

Fwiw, SEARCH did not progress because of a perceived lack of interest from
a much broader group. If there's definite interest in that type of
mechanism, I'm happy to revise and continue working on it.

On Fri, Mar 30, 2018, 18:48 Guilherme Hermeto <[email-masked]> wrote:

> I would definitely like to see that, but I think we can go even further
> and have a FETCH method, as the one described in CoAP (

---

From: Guilherme Hermeto <[email-masked]>
Date: Sat, 31 Mar 2018 09:58:58 -0700

Hi James,

there is definitely an appetite for it. Searches have become increasingly
complex in the past years and POST is the method of choice today to perform
searches. A big problem with POST is that as it is not safe,

However, I think your previous proposal could be extended to address
application-level query languages, like GraphQL or JQL. As these become
more complex, they also turn to the POST method. The SEARCH method could be
a better alternative, even though, technically, some of these might not be
searches, but fetching (one or many) resources.

I'm also interested to know why you decided that SEARCH shouldn't be
cacheable. Was that to keep compatibility with existing implementations? If
you fetching a list of resources which requires a complex query or
filtering, I believe people might want the ability to cache these. Have you
thought about defaulting to no caching, but allowing caching to be enabled
by Cache-Control?

And least, should the proposal be prescriptive about the message contents
and how it is logged by the servers? Today, request bodies in POST request
might contain sensitive information and you don't want these on your log
files.

On Fri, Mar 30, 2018 at 10:45 PM, James M Snell <[email-masked]> wrote:

>> based on the SEARCH proposal from J. Snell (https://tools.ietf.org/html/
>> draft-snell-search-method-00), but would be broader, addressing the
>> issue that SEARCH would be too specific.
>>
>> Thoughts?
>>
>>
>>

---

From: James M Snell <[email-masked]>
Date: Sat, 31 Mar 2018 23:51:50 +0000

> searches, but fetching (one or many) resources.

Indeed. Done properly SEARCH should be entirely agnostic to the specific
query language used.

> thought about defaulting to no caching, but allowing caching to be enabled

This is due specifically to limitations in existing cache implementations.
Few, if any, are set up to consider payload as part of the cache key and
fewer still are set up to support extension methods as being cacheable.
There are definite issues with allowing this.

> might contain sensitive information and you don't want these on your log

I'm not entirely certain we can or should do much here other than a note in
the security considerations.

>> Fwiw, SEARCH did not progress because of a perceived lack of interest
>> from a much broader group. If there's definite interest in that type of