[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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