Re: Proposed HTTP SEARCH method update

[sorry, just found in my output and pushed it out the door]

* James M Snell <jasnell@gmail.com> [2015-04-21 16:27-0700]
> Ah Yeah, good point... Pretty much underscores that the SEARCH response
> itself is not cacheable.

Shouldn't C-L == effective request URI be the common case (and a
desirable one at that)? I expect that the current cachability of `GET
/thing?foo=1` is a reasonably large source of cache hits. SEARCH would
allow us to extend that to include trivial rearrangements like

  GET/thing?foo=1&bar=2
  GET/thing?bar=2&foo=1

SEARCH-aware clients and proxies would check for rearrangements before
accepting a C-L that was a rearrangement of the effective request URI.
This is a linear opperation which can improve the utility of SEARCH.


Julian Reschke <julian.reschke@gmx.de>, Ashok Malhotra <ashok.malhotra@oracle.com>


> On Apr 21, 2015 4:23 PM, "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.
> >
> > 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/
> >
> >
> >
> >
> >

-- 
-ericP

office: +1.617.599.3509
mobile: +33.6.80.80.35.59

(eric@w3.org)
Feel free to forward this message to any list for any purpose other than
email address distribution.

There are subtle nuances encoded in font variation and clever layout
which can only be seen by printing this message on high-clay paper.

Received on Monday, 1 June 2015 13:05:31 UTC