- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Sun, 26 Apr 2015 11:17:55 +0200
- To: "henry.story@bblfish.net" <henry.story@bblfish.net>, Mark Nottingham <mnot@mnot.net>
- CC: James M Snell <jasnell@gmail.com>, ashok malhotra <ashok.malhotra@oracle.com>, ietf-http-wg@w3.org
On 2015-04-26 07:40, henry.story@bblfish.net 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
Received on Sunday, 26 April 2015 09:18:26 UTC