Re: WGLC #354 - ETags & conditional requests

[Mark Nottingham <[e-mail]>]

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.

Yes. Note that "selected representation" is defined earlier:

> We use the term "selected representation" to refer to the current representation of the target resource that would have been selected in a successful response if the same request had used the method GET and had excluded all of the conditional request header fields. The conditional request preconditions are evaluated by comparing the values provided in the request header fields to the current metadata for the selected representation.

Now, a cache could have multiple representations of a resource stored, but again the selection algorithm again only has one output; see <https://svn.tools.ietf.org/svn/wg/httpbis/draft-ietf-httpbis/latest/p6-cache.html#caching.negotiated.responses>.

Cheers,


> 
> 
>> 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/