Re: Proposed HTTP SEARCH method update

> On 25 Apr 2015, at 20:56, Mark Nottingham <mnot@mnot.net> wrote:
> 
> 
>> On 26 Apr 2015, at 6:49 am, henry.story@bblfish.net wrote:
>> 
>> If search is cacheable when the Conent-Location of the response matches the effective request uri, how does that show that the SEARCH response is not cacheable?
> 
> It is cacheable — in the sense that it can be stored. However, that stored response can only be used to satisfy future GET requests to the same URI — which is probably not what you want.
> 
> HTTP caching operates upon representations of resource state, which means accessing the contents of the cache is always GET (or HEAD).

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.

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.

B. SEARCH followed by SEARCH
----------------------------

1. a JS Agent in a browser does not know how large </contacts> is, and only needs to render a couple of fields from that table, so it sends a SEARCH for those fields to the server example.org via it's local in browser cache BC. 
2. The same JS Agent later needs the same to fields again for some different purpose, and sends the same query again using a conditional GET with the same etag. 

Here it should be clear that the in browser cache should be able to immediately return the previous response without needing to connect to example.org. One way to think about it is that this is just a short cut for the previous example A, where the script would have first done a GET for the full resource and then a SEARCH on the representation returned by the GET.

Interestingly enough in this case the cache could be much dumber and not even know abut the query language. As long as the query is the same byte for byte, has the same mime type, is on the same resource with the same etag, it should be able to return the correct result.

> 
> This makes methods that also return things that look like representations difficult to work with — e.g., OPTIONS, PROPFIND. Generally, the better way to do things like this is to make them proper resources, and use links to relate them to the resource they're "talking" about. 

Here we are dealing with partial representations of a remote resource. This is why I say that PATCH is to PUT what SEARCH is to GET. They are just ways to save bandwidth. But in both cases they work on the representation of the resource.

This may require altering the capacities of caches over time. Current caches that don't know about SEARCH will not do anything wrong by not caching, but future optimised caches will be able to make a big difference to the responsiveness of the web.

I hope this helps.

Henry

> 
> Cheers,
> 
> --
> Mark Nottingham   https://www.mnot.net/
> 
> 
> 
> 

Social Web Architect
http://bblfish.net/

Received on Sunday, 26 April 2015 05:40:43 UTC