Re: Proposed HTTP SEARCH method update

> 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.

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/

Received on Tuesday, 21 April 2015 23:23:46 UTC