Re: Link and Unlink

On 09.10.2012 09:28, James M Snell wrote:
> For review and comment...
>
>   http://www.ietf.org/id/draft-snell-link-method-00.txt
>
> Updated definition of LINK and UNLINK, taking RFC5988 into 
> consideration
> and using language consistent from current httpbis draft (read: 
> shamelessly
> and remorselessly lifted).
>
> Comments and feedback definitely welcome.
>
> - James


Given that LINK/UNLINK contain the active parameters for change in Link 
headers instead of URL I don't believe they are normally cacheable as 
stated in the draft. Only when a proxy cache is performing conditional 
requests to the upstream server does cacheability make sense.


For example; two LINK requests for the same URL with different Link 
header content. Request A and request B.

Request A can happen and have a response. However request B, should not 
(MUST NOT?) be responded to by a proxy cache using a cached response to 
request A since the intended server/target of LINK will never receive 
the (different) request-B Link headers. It is likely that the request B 
will have created a different response body to request A anyway 
(use-case being a registry index of some sort, ie torrent seeders list, 
library index, database table content) - making caching the most 
undesirable of outcomes.

The same use-case applies to UNLINK headers and responses.


Also the referenced part6 draft states
" A cache MUST write through requests with methods that are unsafe
    (Section 5.2.1 of [Part2]) to the origin server; i.e., a cache is 
not
    allowed to generate a reply to such a request before having 
forwarded
    the request and having received a corresponding response.
"

So the non-conditional cases passing the request through and waiting 
for a new 2XX response before responding makes caching the earlier 
response useless. For the browser/client cache situation the response 
would seem to be only needed to update the client state information then 
can be discarded.


On the other hand ...

If the proxy cache were to relay the request but add conditional 
headers. Making request-B potentially not only make the LINK/UNLINK 
update but query whether the cached 2xx response is suitable for sending 
to the client.
NP: only the If-Match/If-None-match conditionals make since for this 
case, the time-based ones would block a clients unconditional change.


That raises the question of whether, being idempotent the server should 
respond with "304 Not Modified" in all cases where the LINK/UNLINK was 
not performed due to the link already existing (or not). 204 seems to be 
a step in that direction while retaining the 200 semantics, but 204 
*replaces* a 200 representation with 'nothing' - whereas 304 would 
simply be a no-op success.

Amos

Received on Tuesday, 9 October 2012 00:50:10 UTC