Re: Proposed HTTP SEARCH method update

If the SEARCH response has a Content-Location header and that was used for
the cache, then yes, the response would be cashable. 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/
>
>
>