- From: Mark Nottingham <mnot@mnot.net>
- Date: Sun, 26 Apr 2015 06:56:51 +1200
- To: henry.story@bblfish.net
- Cc: James M Snell <jasnell@gmail.com>, ashok malhotra <ashok.malhotra@oracle.com>, ietf-http-wg@w3.org
> 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. 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 18:57:20 UTC