Re: Summary of ETag related issues in RFC2518bis

I'd like clarification as well.

It's fine for WebDAV to place additional requirements on base HTTP  
servers. I don't see anything in the definition of PUT or of the Etag  
header that would prevent Etag being returned by PUT.

- Jim

On Dec 19, 2005, at 2:11 PM, 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?

Received on Monday, 19 December 2005 22:21:02 UTC