Re: Summary of ETag related issues in RFC2518bis

Cullen Jennings wrote:
> On 12/19/05 1:50 PM, "Julian Reschke" <julian.reschke@gmx.de> wrote:
> 
>>> R2) Require servers to return entity tags for PUT requests
>>>
>>> Required. Or, put another way, what clients need is the ability to know
>>> the final value of the etag assigned to the server's representation of
>>> the resource created by a successful PUT. It seems that the best way to
>>> do this is to have the server respond with that Etag in the PUT
>>> response. What might also work is for there to be a guarantee that this
>>> final etag will be available within a given time period, and hence
>>> clients will only need to perform a single follow-on request to get this
>>> etag. However, protocol requirements involving timing are usually very
>>> hard to get right -- it's not my first choice. That's why I think
>>> returning the etag in the PUT response is the best way to communicate
>>> this final etag value.
>> Again, if we require this, we'll have to make sure everybody agrees on
>> what this means. That, at a minimum, requires getting consensus on the
>> HTTP mailing list, and getting that consensus into the RFC2616 errata.
> 
> Help me understand the logic of why we need RFC2616 errata on this. Are we
> going to do something that is a violation of 2616 or just something that a
> 2616 server would not typically do? 

If we're saying that a server SHOULD return an ETag, we'll have to take 
a position about what that ETag is for. So if we do (I'm not saying we 
necessarily shouldn't), we better make sure it's compliant to what a 
potential revision of RFC2616 is going to say. The best way to achieve 
this is to agree on that clarification, and to put it into RFC2616's errata.

Best regards, JUlian

Received on Monday, 19 December 2005 23:01:37 UTC