RE: ETags and concurrency control

+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 :)
-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.

-pablo


-----Original Message-----
From: Julian Reschke [mailto:julian.reschke@gmx.de]
Sent: Friday, May 02, 2008 7:59 AM
To: Mark Baker
Cc: Henrik Nordstrom; Robert Siemer; Brian Smith; Pablo Castro; atom-protocol@imc.org; HTTP Working Group
Subject: Re: ETags and concurrency control

Mark Baker wrote:
> ...
>>  Not convinced. The current limitations on weak etags is just silly with
>>  the exception of If-Range..
>>
>>  In my view it's a specification error that validators based on
>>  Last-Modified is allowed in more places than weak etag based ones.
>
> Well said.  The meaning of any non-range conditional request message
> using a weak validator is unambiguous.
>
> So would this be a "clarify conformance criteria" fix per the charter?
>  Those MUST NOTs seem to make no sense AFAICT, unless there's
> implementation issues I'm not aware of.
> ...

+1.

In particular, it would be sufficient to *allow* servers to support weak
entity tags in these cases. This change wouldn't break (IMHO) any
existing compliant HTTP/1.1 client/server.

BR, Julian

Received on Friday, 2 May 2008 15:54:22 UTC