Re: Proposed HTTP SEARCH method update

[Julian Reschke <[e-mail]>]

On 2015-04-26 07:40, [e-mail] wrote:
> ...
> Great!  We are getting closer to the core of the problem, which I had tried to address earlier :-)
>
> I agree that HTTP caching should operate upon representations of resource state. My point it that SEARCH always returns a partial representation of the resource state, so that it should be cachable too. This means
> improving the caching stack so that it knows how to update partial representations.

And you seriously believe that people are going to upgrade their caching 
stack specifically for SEARCH?

> To illustrate the different cases, let us take the example from http://datatracker.ietf.org/doc/draft-snell-search-method/ . The resource <http://example.org/contacts> is a small table of contacts.
> Let us imagine that
>
> A. GET followed by SEARCH
> -------------------------
>
> 1. James makes a GET request on <http://example.org/contacts> via a cache C and C caches the returned  representation with etag1 ( and the same Location header )
> 2. Ashok then makes a conditional SEARCH request on <http://example.org/contacts> via the same cache C with etag1 too
>
> I think it is important that SEARCH guarantee the following:
>
> it should not be necessary for the cache C to send the search request all the way back to the server example.org if it knows the query lanuage used in the SEARCH request, because it should be able to answer that
> itself using the information from the GET in 1. above.

That not only implies that caches special-case the SEARCH method, but 
also know the semantics of SEARCH payloads.

> ...


I'd prefer to concentrate on the concrete method definition first.

As Mark said, once you leave the world of GET and HEAD, standard caches 
won't help you anymore.

Of course a server can indicate that a specific SEARCH response is 
indeed cacheable (cache-control!), but it's unlikely that generic caches 
will start to implement that.

If what's needed is a mechanism to discover GETtable resources that 
implement a specific query, something like 
<https://greenbytes.de/tech/webdav/draft-reschke-http-get-location-latest.html> 
might be needed.

Best regards, Julian