[#116] ETags and concurrency control

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 UTC