WGLC #354 - ETags & conditional requests

<http://trac.tools.ietf.org/wg/httpbis/trac/ticket/354>; related text is at <https://svn.tools.ietf.org/svn/wg/httpbis/draft-ietf-httpbis/latest/p4-conditional.html#header.if-match>

Usually, this isn't a problem, because If-Match is only used with methods that to be written through to the origin server. E.g., when you PUT or POST something. 

However, we shouldn't count on that.

One way to address this would be to target the requirements at "origin server" rather than "server"; i.e. to say that we don't expect intermediaries to process If-Match.

Thoughts?


On 24/04/2012, at 3:47 AM, Ben Niven-Jenkins wrote:

> Hi,
> 
> Apologies that this mail misses the WG LC deadline, in Velocix we're reviewing all the HTTPBIS documents but we're a little behind, hence the late comments, sorry. (we're still reviewing so might have more comments as we work through the documents)
> 
> On page 14 of P4 it states:
> 
>  If none of the entity-tags match, or if "*" is given and no current
>  representation exists, the server MUST NOT perform the requested
>  method.  Instead, the server MUST respond with the 412 (Precondition
>  Failed) status code.
> 
> This appears to apply to intermediates, but If-Match has a problem
> here that If-Unmodified-Since does not. If a proxy has a cached
> entity which has a newer Last-Modified timestamp it *knows* that
> the conditional has failed and can generate the required
> 412 Precondition Failed response itself. Otherwise it can satisfy
> the request from cache. Or relay if there is no current cached
> version.
> 
> But because multiple responses with different ETags may exist then a cache receiving If-Match with one etag, when it has a different etag cached, can not know for sure that the request etag does not exist. If it were to respond with a 412 status it would effectively be preventing the use of that conditional.
> 
> It would appear that the only two options available to an intermediate are to satisfy the request in the case of a known match, and relay upstream in all other cases (which would be in conflict with the spec as quoted above).
> 
> Thanks
> Ben
> 
> 

--
Mark Nottingham   http://www.mnot.net/

Received on Thursday, 21 June 2012 03:48:14 UTC