Re: Call for Adoption: SEARCH method

[Julian Reschke <[e-mail]>]

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

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

> 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

#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