Re: WGLC #354 - ETags & conditional requests

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 <mnot@mnot.net> 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
--

Received on Friday, 22 June 2012 11:45:59 UTC