- From: <henry.story@bblfish.net>
- Date: Tue, 21 Apr 2015 22:33:23 +0200
- To: ashok.malhotra@oracle.com
- Cc: ietf-http-wg@w3.org
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/
Received on Tuesday, 21 April 2015 20:33:56 UTC