Re: WGLC #354 - ETags & conditional requests

[Mark Nottingham <[e-mail]>]

Haven't heard any objection, so I've assigned for incorporation in -20.


On 22/06/2012, at 9:45 PM, John Sullivan wrote:

> Mark Nottingham wrote:
>> Of course, thanks; I always forget about the Range cases.
>> 
>> How about:
>> 
>> """
>> If any of the entity-tags listed in the If-Match field value match (as per Section 2.3.2) the entity-tag of the selected representation for the target resource, or if "*" is given and any current representation exists for the target resource, then the server may perform the request method as if the If-Match header field was not present.
>> 
>> Origin servers must not perform the requested method if none of the entity-tags match, or if "*" is given and no current representation exists; instead, they must respond with the 412 (Precondition Failed) status code.
>> 
>> Proxy servers using a cached response as the selected representation must not perform the requested method if none of the entity-tags match, or if "*" is given and no current representation exists; instead, they must forward the request towards the origin server.
>> """
> 
> That sounds good to me - just a minor question about the wording:
> 
>    If any of the entity-tags listed in the If-Match field value match
>    (as per Section 2.3.2) the entity-tag of the selected representation
>    for the target resource
> 
> That makes it sound like, in cases where the server has multiple
> representations available, it will first choose one, *then* compare
> with If-Match. (So if several equivalent versions are available and
> If-Match contains one ETag, and the server chooses the "wrong" one
> in step 1, it will always fail to match in step 2.) I just wondered
> whether the opposite way is specifically excluded: search the available
> versions for one matching an ETag present in If-Match, which will always
> succeed if a matching representation is present.
> 
> 
>> On 22/06/2012, at 1:43 AM, Zhong Yu wrote:
>> 
>>> A valid use case for GET + If-Match may be a range request.
>>> 
>>> If the intermediary has a cached representation with matching tag,
>>> which it has reason to believe would be the "selected representation"
>>> from the original server, the intermediary may safely do the shortcut.
>>> Otherwise the request has to be forwarded to the original server.
>>> 
>>> Zhong Yu
>>> 
>>> On Wed, Jun 20, 2012 at 10:47 PM, Mark Nottingham <[e-mail]> wrote:
>>>> <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/
>>>> 
>>>> 
>>>> 
>>>> 
>> 
>> --
>> Mark Nottingham   http://www.mnot.net/
>> 
>> 
>> 
>> 
>> 
> 
> 
> John
> -- 
> 

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