W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2008

[#116] ETags and concurrency control

From: Mark Nottingham <mnot@mnot.net>
Date: Fri, 9 May 2008 15:46:16 +1000
Cc: Pablo Castro <Pablo.Castro@microsoft.com>, Mark Baker <distobj@acm.org>, Henrik Nordstrom <henrik@henriknordstrom.net>, Robert Siemer <Robert.Siemer-httpwg@backsla.sh>, Brian Smith <brian@briansmith.org>, "atom-protocol@imc.org" <atom-protocol@imc.org>, HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <92BCACAD-5F1A-4E9D-B044-98FC5997E966@mnot.net>
To: Julian Reschke <julian.reschke@gmx.de>

I think this is a somewhat different issue, but it is certainly related.

See:
   http://www3.tools.ietf.org/wg/httpbis/trac/ticket/116

The relevant text seems to be:

p4 section 5:
> Clients MAY issue simple (non-subrange) GET requests with either  
> weak validators or strong validators. Clients MUST NOT use weak  
> validators in other forms of request.

Proposal:

Clients MUST NOT use weak validators in range requests [ref to p5].

> A cache or origin server receiving a conditional request, other than  
> a full-body GET request, MUST use the strong comparison function to  
> evaluate the condition.
Proposal:

A cache or origin server receiving a conditional range request [ref to  
p5] MUST use the strong comparison function to evaluate the condition.


p4 section 7.4:
> See Section 5 for rules on how to determine if two entities tags  
> match. The weak comparison function can only be used with GET or  
> HEAD requests.

Proposal:

See Section 5 for rules on how to determine if two entity tags match.



On 03/05/2008, at 4:36 AM, Julian Reschke wrote:

>
> Pablo Castro wrote:
>> +1
>> That would solve the scenarios we've been struggling with lately.  
>> In the context of Astoria we'd produce week ETags if we can't  
>> guarantee full coverage of the values that form a resource.
>> Two "style" questions about how to proceed:
>> -Does it seem reasonable to go ahead and include this in the  
>> implementation at this point? In the end, somebody has to go first :)
>
> I don't think that would be a problem.
>
> If you fear doing something RFC2616 says you shouldn't, there's a  
> workaround you may want to consider: instead of RFC2616's "If-*"  
> headers, use the "If" header defined in WebDAV (<http://greenbytes.de/tech/webdav/rfc4918.html#rfc.section.10.4 
> >).
>
> This one lets you do the checks you need, even with weak entity tags.
>
>> -About adding the clarification itself, how does that happen? We've  
>> been trying hard to avoid being "creating" about interpreting  
>> specs, so if we'll introduce this change in the implementation it  
>> would be great to know the path from now until the clarification  
>> makes it to the right place.
>
> In general, I see it like this:
>
> a) raise the issue over here on the mailing list (done)
>
> b) get rough consensus that we should do something (partly done)
>
> c) get it onto the issues list (I think it's part of issue 101, <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/101 
> >)
>
> d) achieve rough consensus for new text
>
> e) editors apply change, new draft is published some time later
>
> ...
>
> x) IESG Last Call
>
> y) IESG approval
>
> z) RFC publication
>
> (I omitted a few steps :-)
>
> BR, Julian
>


--
Mark Nottingham     http://www.mnot.net/
Received on Friday, 9 May 2008 05:46:55 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:50:47 GMT