Subject: Call for Adoption: SEARCH method

From: Mark Nottingham <[email-masked]>
Date: Wed, 4 Nov 2020 12:07:03 +1100

As discussed in the October 202 Interim, this is a Call for Adoption for the HTTP SEARCH method draft:
  https://tools.ietf.org/html/draft-snell-search-method-02

Please indicate whether you support adoption in response to this e-mail; information about intent to implement (or use) it is also useful.

The Call for Adoption will end on 18 November 2020.

Cheers,

Mark and Tommy

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 4 Nov 2020 04:35:32 +0100

On Wed, Nov 04, 2020 at 12:07:03PM +1100, Mark Nottingham wrote:
> Please indicate whether you support adoption in response to this e-mail;

This looks reasonable to me. I do have a few concerns about how
implementations will behave in front of it, which definitely justify
that it's adopted and proposed by the WG (e.g. non-cacheability of the
method: what if a cache doesn't recognize the method and caches by
default?).

> information about intent to implement (or use) it is also useful.

I'm not in a situation where I'll need to do anything to use/implement
it as it should be transparent.

Cheers,
Willy

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 4 Nov 2020 15:10:35 +1100

Hey Willy,

Just responding to one bit from my perspective:

> On 4 Nov 2020, at 2:35 pm, Willy Tarreau <[email-masked]> wrote:
> 
> non-cacheability of the

I don't see any evidence of caches doing that (I quickly checked all of the caches covered by cache-tests.fyi). While new methods aren't introduced that often, I don't think caches behave like that, because there are so many uncacheable methods, and they get blamed for caching things incorrectly.

Cheers,

--
Mark Nottingham   https://www.mnot.net/

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 4 Nov 2020 05:36:24 +0100

On Wed, Nov 04, 2020 at 03:10:35PM +1100, Mark Nottingham wrote:
> I don't see any evidence of caches doing that (I quickly checked all of the
> caches covered by cache-tests.fyi). While new methods aren't introduced that
> often, I don't think caches behave like that, because there are so many
> uncacheable methods, and they get blamed for caching things incorrectly.

Very possible indeed. In any case I think this hypothesis ought to be
addressed, either by making sure the impact is low to null, or by figuring
a graceful degradation mode, or any such thing. I would personally have
thought that letting responses be cached based on cache-control could
have been useful.

Cheers,
Willy

---

From: Cory Benfield <[email-masked]>
Date: Wed, 4 Nov 2020 10:24:57 +0000

I support adopting this draft. I think we have seen sufficient
evidence that the absence of a body on GET has forced users to build
ad-hoc implementations of what SEARCH would formalise.

As I do not implement anything that is cache aware there is limited
implementation work for me to do, but I intend to implement what is
necessary if this is adopted.

---

From: Roberto Polli <[email-masked]>
Date: Wed, 4 Nov 2020 13:44:52 +0100

Dear all,

Il giorno mer 4 nov 2020 alle ore 02:10 Mark Nottingham <[email-masked]> ha
>   https://tools.ietf.org/html/draft-snell-search-method-02

I support SEARCH adoption and I'm willing to help on the draft if needed.
There is a wide interest, even in the public sector, for a safe way to
retrieve information.

Thanks to Julian for his commitment!
Kind regards,
R.

---

From: Julian Reschke <[email-masked]>
Date: Wed, 4 Nov 2020 14:04:27 +0100

> The Call for Adoption will end on 18 November 2020.

I support adoption. I'll also tune the implementation in Apache
Jackrabbit if needed (and should we stick with SEARCH as method name).

Best regards, Julian

---

From: Austin Wright <[email-masked]>
Date: Wed, 4 Nov 2020 13:40:28 -0700

> On Nov 3, 2020, at 18:07, Mark Nottingham <[email-masked]> wrote:
> 

I’m very much in favor of a safe variation of POST.

However,
> for backwards compatibility with existing WebDAV implementations, SEARCH requests that use the text/xml or application/xml content types MUST be processed per the requirements established by [RFC5323 <https://tools.ietf.org/html/rfc5323>].
I think this is too restrictive. If it’s not possible to relax the RFC5323 requirements, I would favor using REPORT instead.

I intend to implement whatever is adopted.

Thanks,

Austin Wright.

---

From: Guilherme Hermeto <[email-masked]>
Date: Wed, 4 Nov 2020 13:13:03 -0800

I support adoption. I also intend to implement support for the method on
Restify.

---

From: Henry Story <[email-masked]>
Date: Thu, 5 Nov 2020 04:10:31 +0100

> On 4 Nov 2020, at 21:40, Austin Wright <[email-masked]> wrote:
> 
> 
> 
> > for backwards compatibility with existing WebDAV implementations, SEARCH requests that use the text/xml or application/xml content types MUST be processed per the requirements established by [RFC5323].

Perhaps the restriction can be relaxed by finding a way for the resource
to describe itself some other way, rather than by mime type?
In LDP this is done by having a resource describe itself as being of a certain
type with a Link relation ”type” ldp:Resource , ldp:Container, etc…

see example 2: 
https://www.w3.org/TR/ldp/#ldpc-informative

It also has headers "Accept-Post:”  to guide the client
on what can be POSTed to a container and ”Accept-Patch”
to guide it on what PATCH language can be used.

A similar technique could be used to help specify the query language
here?

Henry
https://co-operating.systems/

---

From: Greg Wilkins <[email-masked]>
Date: Thu, 5 Nov 2020 09:50:10 +0100

Mark,

There is a s/GET/POST/ error in the introduction:

   As an alternative to using GET, many implementations make use of the
   HTTP POST method to perform queries, as illustrated in the example
   below.  In this case, the input parameters to the search operation
   are passed along within the request payload as opposed to using the
   request URI.

   A typical use of HTTP *GET* for requesting a search

   POST /feed HTTP/1.1
   Host: example.org
   Content-Type: application/x-www-form-urlencoded

   q=foo&limit=10&sort=-published

-- 
Greg Wilkins <[email-masked]> CTO http://webtide.com

---

From: James Fuller <[email-masked]>
Date: Thu, 5 Nov 2020 10:24:15 +0100

+1 ...

XML may not be everyone's cup of tea but there is continuing not
insignificant usage on todays web (ex. aws ec2 command default uses
xml 'under the covers' and there are many, widely deployed machine to
machine systems using XML which may want to leverage SEARCH method
differently then webdav) ... not arguing the merits/non merits of any
data format ... I feel strongly that restricting a data format usage
into the future seems overly constraining.

Generally I  see the attraction of piggybacking on top of existing
WEBDAV rfc though curious what a standalone rfc defining a SRCH method
might look like.

cheers, Jim Fuller

---

From: Julian Reschke <[email-masked]>
Date: Thu, 5 Nov 2020 10:43:23 +0100

Am 04.11.2020 um 21:40 schrieb Austin Wright:
> ...
> I think this is too restrictive. If it’s not possible to relax the
> RFC5323 requirements, I would favor using REPORT instead.
> ...

We can relax the requirement to apply only to */xml which has a document
element in the "DAV:" namespace (see
<https://greenbytes.de/tech/webdav/rfc5323.html#rfc.section.2.2.2>, or
even restrict it to the two element names defined there).

Best regards, Julian

---

From: James Fuller <[email-masked]>
Date: Thu, 5 Nov 2020 11:33:03 +0100

> even restrict it to the two element names defined there).

+1 ... seems a reasonable compromise to me.

Jim

---

From: Henry Story <[email-masked]>
Date: Thu, 5 Nov 2020 17:51:57 +0100

> On 5 Nov 2020, at 17:45, Ben Schwartz <[email-masked]> wrote:
> 
> The draft says "The response to a SEARCH request is not cacheable.".  Why is that?  Semantically, it seems that caching keyed by the request body should behave correctly.
> 
> RFC 7234 says "it is also possible to cache ... responses to methods other than GET if the method's definition allows such caching and defines something suitable for use as a cache key.".
> 
> Without support for caching, I don't have any reason to prefer this method over POST.  With support for caching, this would have been very useful in DoH.

I also had concerns about this.

My guess is that this comes from overlooking the browser as one of the most
important caches around, especially with the move to TLS everywhere.

A browser should be able to implement some of the query languages directly
so that if it has a representation locally it can query that representation
without downloading the remote one.

Henry

> 
> On Tue, Nov 3, 2020 at 8:10 PM Mark Nottingham <[email-masked]> wrote:

---

From: Glenn Block <[email-masked]>
Date: Thu, 5 Nov 2020 00:00:51 +0000

I support adoption.

This is great to see. I've been a fan of this method since I first learned about it years ago.

One place I think this would be valuable is for GraphQL usage. One of the common critiques of GraphQL is that the HTTP caching story is very limited, as by default all requests are via POST.

The GraphQL HTTP w/g has done some work to specify how different methods can be used but you are still limited by the fact that the query is sent via the query string.

Reading through the draft, it says that responses are not cachable, but it sounds like there is "some" client caching through usage of ETAGs and conditional SEARCH requests.

Why not allow support cachable responses? It would be great if there was a way to leverage caches fully.

Regards
Glenn

Glenn Block (he/him/his) | M365 Core Ecosystem | @gblock <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftwitter.com%2Fgblock&data=04%7C01%7CGlenn.Block%40microsoft.com%7C8b67f4d44ba14854defb08d85b6e0918%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637359875442888782%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=zKA721Dufo%2FIGdCEl%2FlHXmlCVokJ2QbNDTZjN%2BAo7ZE%3D&reserved=0> | Principal PM Lead | Schedule with me!<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbook.ms%2FGlenn.Block%40microsoft.com&data=04%7C01%7CGlenn.Block%40microsoft.com%7C8b67f4d44ba14854defb08d85b6e0918%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637359875442898783%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=4ZXDdKU%2FltooMs6XE5Zcyd899Byru2gHDA%2Btd4XSno0%3D&reserved=0>
________________________________
From: Mark Nottingham <[email-masked]>
Sent: Tuesday, November 3, 2020 5:07 PM
To: HTTP Working Group <[email-masked]>
Cc: Tommy Pauly <[email-masked]>
Subject: [EXTERNAL] Call for Adoption: SEARCH method

As discussed in the October 202 Interim, this is a Call for Adoption for the HTTP SEARCH method draft:
  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools..ietf.org%2Fhtml%2Fdraft-snell-search-method-02&amp;data=04%7C01%7CGlenn.Block%40microsoft.com%7C1587193415684c8c2eac08d8811bdd71%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637401303976867322%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=RzTJaZTWHxqmR2zgipC4%2FrIdNQI5kGd73RDTii%2Ba8Ng%3D&amp;reserved=0

Cheers,

Mark and Tommy

---

From: Ben Schwartz <[email-masked]>
Date: Thu, 5 Nov 2020 11:45:02 -0500

The draft says "The response to a SEARCH request is not cacheable.".  Why
is that?  Semantically, it seems that caching keyed by the request body
should behave correctly.

RFC 7234 says "it is also possible to cache ... responses to methods other
than GET if the method's definition allows such caching and defines
something suitable for use as a cache key.".

Without support for caching, I don't have any reason to prefer this method
over POST.  With support for caching, this would have been very useful in
DoH.

---

From: Michael Douglass <[email-masked]>
Date: Thu, 5 Nov 2020 13:05:22 -0500

I also support not limiting the content type. I can imagine implementing 
a search extension to existing XML based protocols.

RFC5323 Section 3 say's

    Clients can determine which query grammars are supported by an
    arbiter by invoking OPTIONS on the search arbiter.  If the resource
    supports SEARCH, then the DASL response header will appear in the
    response.  The DASL response header lists the supported grammars.

    Servers supporting the WebDAV extensions [RFC3253  <https://tools.ietf.org/html/rfc3253>] and/or [RFC3744  <https://tools.ietf.org/html/rfc3744>]
    MUST also:

    o  report SEARCH in the live property DAV:supported-method-set for
       all search arbiter resources, and

...

Presumably a WebDAV compliant client knows whether or not SEARCH is 
supported as a WebDAV service

So:

If it's in DAV:supported-method-set it's WebDAV SEARCH

If it's in the "Accept-Search" Header Field it's the new SEARCH

and you can't have both. No need to parse the content.

---

From: Julian Reschke <[email-masked]>
Date: Thu, 5 Nov 2020 20:37:14 +0100

> and you can't have both. No need to parse the content.

Yes, but...

The content type in the payload is supposed to describe the query
semantics. I would expect any new use of SEARCH to actually use a
payload format that is more specific than text/xml or application/xml.

Am I missing something here?

Best regards, Julian

---

From: Mike Bishop <[email-masked]>
Date: Thu, 5 Nov 2020 19:44:20 +0000

I support adopting this draft, and will read and provide feedback.  There is
interest at Akamai for being able to identify safe POSTs and better manage
cacheability of the results, especially as it relates to GraphQL.

-----Original Message-----
From: Mark Nottingham <[email-masked]> 
Sent: Tuesday, November 3, 2020 8:07 PM
To: HTTP Working Group <[email-masked]>
Cc: Tommy Pauly <[email-masked]>
Subject: Call for Adoption: SEARCH method

As discussed in the October 202 Interim, this is a Call for Adoption for the
HTTP SEARCH method draft:
  https://tools.ietf.org/html/draft-snell-search-method-02

Cheers,

Mark and Tommy

---

From: Michael Douglass <[email-masked]>
Date: Thu, 5 Nov 2020 22:46:53 -0500

On 11/5/20 14:37, Julian Reschke wrote:
>>     Servers supporting the WebDAV extensions [RFC3253 
>> <https://tools.ietf.org/html/rfc3253>] and/or [RFC3744 
>> <https://tools.ietf.org/html/rfc3744>]
>>     MUST also:
>>

Sorry - I think I replied too high up in the thread.

Your later message said:

>
>> for backwards compatibility with existing WebDAV implementations, 
>> SEARCH requests that use the text/xml or application/xml content 
>> types MUST be processed per the requirements established by [RFC5323 
>> <https://tools.ietf.org/html/rfc5323>].
>
I think my suggestion is a valid way of distinguishing between WebDAV 
search and the new search. Given the existing and proposed headers 
there's no need to parse the content to determine if it's a WebDAV search.

If it's a WebDAV search then that's handled however it's done now (or in 
the future).

If it's the new search then I don't see that we need to restrict the 
content to NOT have DAV: namespace elements.

---

From: Julian Reschke <[email-masked]>
Date: Fri, 6 Nov 2020 05:23:42 +0100

> there's no need to parse the content to determine if it's a WebDAV search.

But you need to parse the content at some point of time anyway, right?

> content to NOT have DAV: namespace elements.

First of all, this whole discussion only affects resources that want to
support *both*, that is, implementations of WebDAV SEARCH which want to
implement non-WebDAV uses as well.

Furhermore, the whole distinction between "new" vs "WebDAV" seems to be
weird. The only difference is that for certain specific payloads, the
existing RFC mandates a very specific response format. That's it.
Different request payload formats are totally free to pick what they
need. We are just *relaxing* the requirements.

Best regards, Julian

---

From: Nick Harper <[email-masked]>
Date: Thu, 5 Nov 2020 16:25:55 -0800

I support adoption of a general-purpose HTTP method that is safe and allows
a request body (e.g. GET with body or safe POST).

This draft provides such a method, but it is framed as bringing the
semantics of WebDAV's SEARCH method to HTTP. I am interested in a general
purpose method, not one with such specific semantics. One example of this
is in the introduction: “Unlike POST, however the semantics of the SEARCH
method are specifically defined.” If adopted, I think the Abstract and
Introduction of this draft needs to be reframed to describe that this is a
general-purpose HTTP method to allow making safe HTTP requests that contain
a request body.

If a WebDAV method name is reused for a generic HTTP use-case, one should
be able to implement and use that without needing to understand how that
method works in WebDAV. In particular, I think the special casing of XML
processing to match WebDAV should be removed if this draft is adopted.

I also agree with Ben Schwartz that there's no need to define responses to
this new method to be uncacheable. (A server could choose to respond to
requests indicating that they're not cacheable if that's the server's
desired behavior.) I'm also confused by when a conditional SEARCH request
would be made if the client doesn't do any caching.

---

From: Philippe Mougin <[email-masked]>
Date: Wed, 18 Nov 2020 21:14:19 +0100

Hello,

I don't support adoption because:

- The introduction provides an inaccurate and self contradictory description of GET, as detailed in this message: https://lists.w3.org/Archives/Public/ietf-http-wg/2020JulSep/0198.html

- The name of the method appears too restrictive, as a safe and idempotent equivalent to POST, which is what the draft essentially defines, would be useful beyond search operations.

I would support the adoption if the introduction was amended and the draft was extended beyond providing a SEARCH method to something more generic, such as, for instance, a COMPUTE method.

Best,

Philippe Mougin

> Le 4 nov. 2020 à 02:10, Mark Nottingham <[email-masked]> a écrit :
>

---

From: Julian Reschke <[email-masked]>
Date: Wed, 18 Nov 2020 21:53:03 +0100

> I don't support adoption because:

Adoption doesn't mean endorsement or standardization. It just means that
the WG will use it as base document for future discussions.

The WG will tune the document, there'll be a WG Last Call, and IETF Last
Call, and an IESG evaluation.

Best regards, Julian

---

From: Philippe Mougin <[email-masked]>
Date: Thu, 19 Nov 2020 00:35:20 +0100

> Le 18 nov. 2020 à 21:56, Julian Reschke <[email-masked]> a écrit :
> 

Yes. I think the draft in its current form would lead WG efforts in significantly suboptimal directions, which is why I don't support adoption.

Best, 
Philippe Mougin

---

From: James M Snell <[email-masked]>
Date: Wed, 18 Nov 2020 19:39:39 -0800

On Wed, Nov 18, 2020, 12:18 Philippe Mougin <[email-masked]> wrote:

> - The introduction provides an inaccurate and self contradictory
> description of GET, as detailed in this message:
> https://lists.w3.org/Archives/Public/ietf-http-wg/2020JulSep/0198.html
>
>
> - The name of the method appears too restrictive, as a safe and idempotent
> equivalent to POST, which is what the draft essentially defines, would be
> useful beyond search operations.
>
>
To be clear, this is not intended as a safe, idempotent equivalent to POST.
It is intended specifically to cover search/query operations which are
often ambiguously represented as GET or POST. I'm not quite sure what a
safe idempotent equivalent to POST would even be, but this is not it.

> I would support the adoption if the introduction was amended and the draft
> was extended beyond providing a SEARCH method to something more generic,
> such as, for instance, a COMPUTE method.
>

This can be discussed later once the draft is adopted but I'd be a strong
-1 on COMPUTE as a viable method name here.

---

From: Julian Reschke <[email-masked]>
Date: Thu, 19 Nov 2020 05:46:15 +0100

Am 19.11.2020 um 04:39 schrieb James M Snell:
> On Wed, Nov 18, 2020, 12:18 Philippe Mougin <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>
>     Hello,
>
>
>     <https://lists.w3.org/Archives/Public/ietf-http-wg/2020JulSep/0198.html>
>
>
>     - The name of the method appears too restrictive, as a safe and
>     idempotent equivalent to POST, which is what the draft essentially
>     defines, would be useful beyond search operations.
>
>
> To be clear, this is not intended as a safe, idempotent equivalent to
> POST. It is intended specifically to cover search/query operations which
> are often ambiguously represented as GET or POST. I'm not quite sure
> what a safe idempotent equivalent to POST would even be, but this is not
> it.
> ...

FWIW, I disagree with that. Ignore the method name for a moment, and
what's left is a retrieval operation similar to GET which additionally
takes the request payload into account.

Best regards, Julian

---

From: Nick Harper <[email-masked]>
Date: Wed, 18 Nov 2020 21:42:25 -0800

On Wed, Nov 18, 2020 at 7:43 PM James M Snell <[email-masked]> wrote:

>> idempotent equivalent to POST, which is what the draft essentially defines,
>> would be useful beyond search operations.
>>
>>
> are often ambiguously represented as GET or POST. I'm not quite sure what a

When this draft was presented at the October interim, it was presented in
the context of solving the problem of providing a safe (and idempotent)
HTTP method that has a request body, i.e. a safe POST or a GET with a body.
That problem (i.e. specifying such an HTTP method) is what I'm interested
in solving, not bringing WebDAV's SEARCH semantics to HTTP.

A question for the working group: in this Call for Adoption, are we
considering adopting a general-purpose method that is safe and has a
request body, or are we considering adopting work on the specific
search/query semantics that this draft intends to cover?

If the former, I support that goal, and this draft could be a starting
point. If the latter, I do not support adopting this draft. It also appears
that the draft does not succeed in meeting that goal. The draft includes a
list of 4 bullet points in the introduction of problems using the GET
method. The first two points concern the semantics, but they are not solved
by the SEARCH method presented in the draft. The last two points are
addressed by the SEARCH method, but they are not specific to search/query
semantics and would be solved just as well by a general-purpose method.

>
>
>
>> I would support the adoption if the introduction was amended and the
>> draft was extended beyond providing a SEARCH method to something more
>> generic, such as, for instance, a COMPUTE method.
>>
>

---

From: Julian Reschke <[email-masked]>
Date: Thu, 19 Nov 2020 07:06:37 +0100

Am 19.11.2020 um 06:42 schrieb Nick Harper:
> ...
> When this draft was presented at the October interim, it was presented
> in the context of solving the problem of providing a safe (and
> idempotent) HTTP method that has a request body, i.e. a safe POST or a
> GET with a body. That problem (i.e. specifying such an HTTP method) is
 > ...

Yes, that was the intention.

> what I'm interested in solving, not bringing WebDAV's SEARCH semantics
> to HTTP.
>

The draft is not supposed to cover any *specific* search semantics; that
would be done by specific payload formats. (That said, we may want to
talk about form encoded payloads...)

> point. If the latter, I do not support adopting this draft. It also
> appears that the draft does not succeed in meeting that goal. The draft
> includes a list of 4 bullet points in the introduction of problems using
> the GET method. The first two points concern the semantics, but they are
> not solved by the SEARCH method presented in the draft. The last two

#1 is:

"Without specific knowledge of the resource and server to which the GET
request is being sent, there is no way for the client to know that a
search operation is being requested. Identical requests sent to two
different servers can implement entirely different semantics."

I'm not sure whether this is a problem at all, and if it is, wether it
is fixable with a new method. At the end of the day, it's always up to
the server to do what it wants. What we can do is describe the intent of
the request.

#2 is:

"Encoding query parameters directly into the request URI effectively
casts every possible combination of query inputs as distinct resources.
For instance, because mechanisms such as HTTP caching handle request
URIs as opaque character sequences, queries such as
'http://example.org/?q=foo' and 'http://example.org/?q=Foo' will be
treated as entirely separate resources even if they yield identical
results."

That is solved my moving the "query" into the payload; but then, the
normalization question just applies to a different part of the request.

Best regards, Julian

---

From: "Martin Thomson" <[email-masked]>
Date: Thu, 19 Nov 2020 17:15:10 +1100

> normalization question just applies to a different part of the request.

Isn't it the case that in doing so the payload format is able to deal with things like normalization?  

That is, if I were to use a JSON-based format a SEARCH containing { "a": true, "b": 1 } might be treated differently from { "b": 1, "a": true } in some cases, but not if the format were to say that order doesn't matter.

Now that I've written that out I realize that a better example might be differing whitespace in the different bodies.

---

From: Julian Reschke <[email-masked]>
Date: Thu, 19 Nov 2020 07:21:02 +0100

> That is, if I were to use a JSON-based format a SEARCH containing { "a": true, "b": 1 } might be treated differently from { "b": 1, "a": true } in some cases, but not if the format were to say that…

Yes, indeed.

Best regards, Julian

---

From: Philippe Mougin <[email-masked]>
Date: Thu, 19 Nov 2020 07:45:05 +0100

> Le 19 nov. 2020 à 04:43, James M Snell <[email-masked]> a écrit
> 
> To be clear, this is not intended as a safe, idempotent equivalent to POST. It is intended specifically to cover search/query operations which are often ambiguously represented as GET or POST. I'm not quite sure what a safe idempotent equivalent to POST would even be, but this is not it. 

POST is often used to perform operations that are actually safe by nature, and it would be useful to have a method that could express that at the HTTP level. That's what I referred as a "safe/idempotent equivalent to POST". Essentially, such a method would subsume the SEARCH method described in the draft.

Best,
Philippe Mougin

---

From: James Fuller <[email-masked]>
Date: Thu, 19 Nov 2020 07:58:04 +0100

> takes the request payload into account.

and I disagree with both of you ;) ... +1 for taking on the draft for
discussion.

it would help clarify what exactly s being proposed, as the potential
for developer
confusion is high (because we all know what SEARCH must mean, right ?).

Some of the answers of the following questions interest me for those
future discussions;

* does SEARCH naturally assume working on collection of resources (uri's) ?

* how to generically report errors on a single resource within
returned results (ex. does 207 multi-status apply ?)

* if we are not constraining result format (or content type eg. return
a text/uri-list) then what is different from a
GET with some meta data saying 'this is a search' ? There are a few
slippery slopes here and esp hard mapping
HTTP semantics over many different things generically (eg. file
systems, databases, higher order ex., SPARQL, etc etc etc)
w/o cgi-bin devolution.

The above further reinforces my unease of direct linkage to WEBDAV ...
but should be an interesting conversation.

James Fuller

---

From: Greg Wilkins <[email-masked]>
Date: Thu, 19 Nov 2020 09:19:01 +0100

> takes the request payload into account.

Then why don't we just define the semantics of  GET's may have bodies.   I
think this would be trivial for most implementations and that many already
do support it, given that RFC7230 3.3
<https://tools.ietf.org/html/rfc7230#section-3.3> says:

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

Then in RFC7231 4.3.1 <https://tools.ietf.org/html/rfc7231#section-4.3.1>
it says:

>    A payload within a GET request message has no defined semantics;
>    sending a payload body on a GET request might cause some existing
>    implementations to reject the request.

So let's just save the carbon footprint of creating another method (and
enforcing that GET's cannot have bodies) by defining the circumstances in
which a body of a GET can have semantic significance?    I don't see that
as contrary to 7230 and is not prohibited by 7231.

For most implementations, this will just work as they don't care about the
method when handing message framing.   For implementations that actually
handle the method, I see very less work to allow bodies to GETs (which many
probably already do) that to add a new method and all the framework
apparatus that implies and all the tests and new CIs and wasted
CPU/developer cycles for something that is already mostly there.

A client that wishes to send a SEARCH or a GET with a body will equally
have to expect a 4xx if something in the path doesn't expect either.   The
main difference is that a GET with a body may receive a response that
simply ignored the body and the client may not be able to determine that.
But then equally it is not possible to tell if a SEARCH method has been
simply routed to a GET implementation and the body equally ignored.   If
this is a concern, then perhaps defining a response header that indicates
the request body was considered is a better way forward?

cheers

---

From: James Fuller <[email-masked]>
Date: Thu, 19 Nov 2020 09:51:33 +0100

On Thu, 19 Nov 2020 at 09:22, Greg Wilkins <[email-masked]> wrote:
> Then why don't we just define the semantics of  GET's may have bodies.   I think this would be trivial for most implementations and that many already do support it, given that RFC7230 3.3 says:
>>

+1 ... somewhat related - would there by any parity to making a DELETE
with body (allowed today) both safe & idempotent as well ?

James Fuller

---

From: Julian Reschke <[email-masked]>
Date: Thu, 19 Nov 2020 10:05:33 +0100

> * does SEARCH naturally assume working on collection of resources (uri's) ?

Technically, no.

> returned results (ex. does 207 multi-status apply ?)

Out of scope, I would say.

> systems, databases, higher order ex., SPARQL, etc etc etc)

The difference is that the "query" (for some value of that) can go into
the payload.

> but should be an interesting conversation.

The intent is not to have any normative linkage to WebDAV (or almost
none) when we're done.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Thu, 19 Nov 2020 10:10:52 +0100

Am 19.11.2020 um 09:19 schrieb Greg Wilkins:
> ...
> Then why don't we just define the semantics of  GET's may have bodies.
 > ...

My understanding is that we won't be able to do that, because it would
not work everywhere. If we found out that not to be true, it would be an
alternative.

> have to expect a 4xx if something in the path doesn't expect either.
>
>   The main difference is that a GET with a body may receive a response
> that simply ignored the body and the client may not be able to determine
> that.  But then equally it is not possible to tell if a SEARCH method
> has been simply routed to a GET implementation and the body equally
> ignored.   If this is a concern, then perhaps defining a response header
> that indicates the request body was considered is a better way forward?

The subtle difference here is that a server that ignores the body on GET
currently is conformant, while a server that treats SEARCH as GET is buggy.

The suggestion with the response header field although is interesting.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Thu, 19 Nov 2020 10:13:50 +0100

> with body (allowed today) both safe & idempotent as well ?

a) <https://github.com/httpwg/http-core/issues/258>

b) *safe*???

Best regards, Julian

---

From: James Fuller <[email-masked]>
Date: Thu, 19 Nov 2020 10:47:30 +0100

> a) <https://github.com/httpwg/http-core/issues/258>

that addresses my concern

> b) *safe*???

more tea needed for me ... ignore ;)

James Fuller

---

From: James M Snell <[email-masked]>
Date: Thu, 19 Nov 2020 06:25:25 -0800

Heh, I think we had a similar discussion before when we first started
writing this up if memory serves me correctly ;) ... My view of it should
definitely not limit anyone else's here, or hold up the WG adopting the
draft ;)

On Wed, Nov 18, 2020, 20:50 Julian Reschke <[email-masked]> wrote:

> .

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Fri, 27 Nov 2020 14:25:05 +0100

tor. 19. nov. 2020 kl. 08:01 skrev James Fuller <[email-masked]>:

> for developer confusion is high (because we all know what SEARCH
> must mean, right ?).

I agree. When I first brought this to the WG's attention, it was based
on discussions around the use of GET with payload, which is both wrong
and dangerous:

https://github.com/elastic/elasticsearch/issues/16024

In my view, SEARCH as currently specified only solves the first of
five desirable properties of a new HTTP method:

1. Explicit support for a request payload.
2. Safe.
3. Idempotent.
4. Cacheable by default (keyed by payload).
5. Content-Type agnostic.

Not attempting to solve any of the other properties is a missed
opportunity, imho. I would support and implement the method
regardless, but I would be much more in favor if we managed to give
the method all of the five properties mentioned above.

Wrt. cacheable by default, we may also consider a general HTTP header
that can also be applied to POST, as suggested here:

https://github.com/httpwg/http-extensions/issues/942

> * does SEARCH naturally assume working on collection of resources (uri's) ?

Not any more than GET with a query string?

> GET with some meta data saying 'this is a search' ?

The result of a SEARCH request should not impose any semantics on the
response, imho. The semantics of the response is conveyed by its
Content-Type, which the client can of course negotiate with the Accept
header. Each item in the SEARCH result is not necessarily its own HTTP
resource, although something like that would be possible with a multipart/*
response Content-Type.

-- 
Asbjørn Ulsberg           -=|=-        [email-masked]
«He's a loathsome offensive brute, yet I can't look away»

---

From: Julian Reschke <[email-masked]>
Date: Fri, 27 Nov 2020 14:30:54 +0100

> 5. Content-Type agnostic.

Hmmm?? It solves 1...3, unless I'm missing something.

5. Would be solved by this spec.

4. is non-trivial, and it would be good to solve that in general, not
just as a special case.

> resource, although something like that would be possible with a multipart/*

Yes.

Best regards, Julian

---

From: Philippe Mougin <[email-masked]>
Date: Fri, 27 Nov 2020 17:41:47 +0100

> Le 27 nov. 2020 à 14:32, Julian Reschke <[email-masked]> a écrit :
> 

Looks indeed that it explicitly solves it. But only for the narrow use case of search operations, with no clear benefit from this limitation.

Best,

Philippe Mougin