Re: Proposed HTTP SEARCH method update

On Sat, Apr 25, 2015 at 11:56 AM, Mark Nottingham <mnot@mnot.net> wrote:
>
>> On 26 Apr 2015, at 6:49 am, henry.story@bblfish.net wrote:
>>
>> If search is cacheable when the Conent-Location of the response matches the effective request uri, how does that show that the SEARCH response is not cacheable?
>
> It is cacheable — in the sense that it can be stored. However, that stored response can only be used to satisfy future GET requests to the same URI — which is probably not what you want.
>

It definitely is not what we want. The SEARCH response is a not
representation of the resource. It's NOT what you'd expect to get back
when sending a GET to the same URI.

- James

> HTTP caching operates upon representations of resource state, which means accessing the contents of the cache is always GET (or HEAD).
>
> This makes methods that also return things that look like representations difficult to work with — e.g., OPTIONS, PROPFIND. Generally, the better way to do things like this is to make them proper resources, and use links to relate them to the resource they're "talking" about.
>
> Cheers,
>
> --
> Mark Nottingham   https://www.mnot.net/
>
>
>
>

Received on Saturday, 25 April 2015 19:11:08 UTC