Re: Proposed HTTP SEARCH method update

> On 26 Apr 2015, at 17:51, Ashok Malhotra <ashok.malhotra@oracle.com> wrote:
> 
> Hello Henry:
> I understand that you want intelligent caches that use knowledge about the
> resource and the results.  This is a fine goal but our priority now is to get
> the SEARCH proposal accepted with the existing infrastructure. Let's work on
> getting that done.  Then we can work on intelligent caching.
> All the best, Ashok

Well it looks like there is support for SEARCH which is good news :-)

Btw. one should count to existing infrastructure web servers that need to
write web proxies that cache remote results in order for JS apps to be 
able to work on distributed data.

I tend to think that it can't harm to think a bit about how SEARCH fits 
into the wider set of IETF specifications and if it does then that is even 
better news, and could be very useful in helping define what it is. 

For example, my intuition that SEARCH returns a partial representation 
has led us  to discover ( thanks to Amos Jeffries ) that we should look 
to adopt  a 206 status code as defined in RFC 7233.

Does this mean that example 4.1 from draft-snell [1] where the SEARCH returns 
a 200 is wrong? Or is it correct that SEARCH is not cacheable other than
via a 206 route? Is this something one can add later, or may not specifying
this now lead to problems further down the road?

The best time to answer this is now, rather than later, to make sure these 
extensions that don't make it into the spec can be specified later.

Henry

[1] http://datatracker.ietf.org/doc/draft-snell-search-method/?include_text=1

Social Web Architect
http://bblfish.net/

Received on Sunday, 26 April 2015 16:21:19 UTC