- From: <henry.story@bblfish.net>
- Date: Sat, 25 Apr 2015 20:09:34 +0200
- To: Mark Nottingham <mnot@mnot.net>
- Cc: James M Snell <jasnell@gmail.com>, ashok malhotra <ashok.malhotra@oracle.com>, ietf-http-wg@w3.org
> On 22 Apr 2015, at 01:23, Mark Nottingham <mnot@mnot.net> wrote: > > >> On 21 Apr 2015, at 2:08 pm, James M Snell <jasnell@gmail.com> wrote: >> >> If the SEARCH response has a Content-Location header and that was used for the cache, then yes, the response would be cashable. > > ONLY if the C-L is the same as the effective request URI. Is this just a limitiation of current caching protocols? Let's put it differently. I'd expect that if I sent the same query to the same resource with the same conditional request (on the same etag), I'd get the same result. Why should I not? So that means that a cache could check something like SEARCH + URL + mime-type and body of response and store the result, which it could return directly in another request if the appropriate headers + body of request matched. It seems that your claim that SEARCH responses are not cachable is related to a very specific idea of how caches operate. Am I right? Perhaps you can point me to the document. Perhaps that document would allow one for the sake of argument to put the query in the header. Would it then be cacheable? If that is correct then it might be worth noting this, because one can imagine caching services evolving too. Also along these lines it seems to me that there is something that could be said about how multiple queries could end up allowing a client to get a complete overview of the remote data - which can only work if the above cacheability holds I think. For example JavaScript clients may want to make SEARCH requests to get fast and partial answers for very large data sets, and be able to explore the data in small chunks at a time as needed, all in the knowledge that they are getting a better and better view of the remote resource, be it in small chunks. Henry > > Cheers, > >> Otherwise, you cannot assume cacheability because the SEARCH response (a) does not represent the state of the resource identified by the effective request URI and (b) caches are currently unable to vary based on request payload. >> >> On Apr 21, 2015 1:38 PM, "henry.story@bblfish.net" <henry.story@bblfish.net> wrote: >> So the context of this answer is in short the sentence >> "The response to a SEARCH request is not cacheable." >> >>> On 18 Apr 2015, at 23:01, ashok malhotra <ashok.malhotra@oracle.com> wrote: >>> >>> Also. Henry, the response may be the location of the >>> result set as in Example 4.2 >> >> >> True. But that does not really affect the cachability of the response does it? ( I am >> trying to wrap my head around this, so please consider these questions just a dialectical >> method - in the Socratic sense - to see if we can understand this ) >> >> The 303 points to another document that itself can be cacheable. I suppose that would >> in fact be the point of the 303 even, to give a URL for the specific query that can then >> be re-used and sent around - and cached even. >> >> So the 303 in SEARCH does not constitute evidence that SEARCH is not cacheable, just like a 303 in HTTP GET does not show that GET is not cacheable. >> >> So now I wonder why it is that you think SEARCH results cannot be cached? >> They may not be cacheable currently in existing caches, but I fail to see why with proper use >> of etags, they should not be. >> >> Henry >> >> >> Social Web Architect >> http://bblfish.net/ >> >> > > -- > Mark Nottingham https://www.mnot.net/ > > > > Social Web Architect http://bblfish.net/
Received on Saturday, 25 April 2015 18:10:05 UTC