Re: GET with body / SEARCH

On Sat, Mar 31, 2018, 09:59 Guilherme Hermeto <gui.hermeto@gmail.com> wrote:

> 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.
>

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


> 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?
>

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.


> 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.
>

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


>
>
>
> On Fri, Mar 30, 2018 at 10:45 PM, James M Snell <jasnell@gmail.com> wrote:
>
>> 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 <gui.hermeto@gmail.com>
>> 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 (
>>> 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?
>>>
>>>
>>>
>>> On Fri, Mar 30, 2018 at 4:03 AM, Matthew Kerwin <matthew@kerwin.net.au>
>>> wrote:
>>>
>>>> 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/
>>>>
>>>>
>>>
>