Re: Proposed HTTP SEARCH method update

On Fri, Apr 10, 2015 at 12:00 PM, James M Snell <jasnell@gmail.com> wrote:
> Please see: http://datatracker.ietf.org/doc/draft-snell-search-method/
>
> Comments welcome.

I don't have any substantive comments on the heart of the spec, but
take issue with the characterization of some of the motivations for
the use of SEARCH;

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

It is architecturally beneficial that a client has no knowledge of
whether a search takes place or not when a server responds to a GET,
as that is an implementation detail. If that information needs to be
exposed, then a new method needs to be used, as this draft specifies,
but that is in no way a disadvantage of using GET. It is actually a
reason why someone might want to avoid using SEARCH, or other
get-me-this-info-not-using-GET methods, e.g. PROPFIND).

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

The first sentence describes, AFAICT, problems with parameter
ordering, but that is not an interpretation of the meaning of a
parametrized URL that is licensed by either specification or deployed
implementation. It concludes with an example of case-sensitivity, but
I fail to see either the connection to parameter ordering, or any
problem with this situation as we know that the http URI scheme is
case sensitive past the authority component. Those URIs identify
different resources and could represent two different "searches" for
differently-capitalized words.

I'd also point out that SEARCH response are specified as
non-cacheable, so it hardly seems appropriate to describe a perceived
inefficiency in GET response caching as inferior to a complete
inability to cache.

On the flip side, I was surprised to not see the value of avoiding
overloading POST's meaning as an advantage, as I consider that far and
away SEARCH's biggest selling point.

Mark.

Received on Monday, 20 April 2015 03:09:58 UTC