Re: etags in If: headers (was: 54th IETF Meeting Information, and RFC2518 open issues)

Yves, Greg, thanks for the link and the explanation.

So I change my mind and am in favour of keeping If: headers
functionality as they are described in 2518.

Regarding potential length of this header: would it be ok
to allow whitespace between tokens, so that the header can
be more easily split on several lines?

//Stefan

Am Donnerstag den, 25. April 2002, um 09:20, schrieb Yves Lafon:

> On Wed, 24 Apr 2002, Greg Stein wrote:
>
>> On Mon, Apr 22, 2002 at 06:53:34PM +0200, Stefan Eissing wrote:
>>> Am Montag den, 22. April 2002, um 18:36, schrieb Lisa Dusseault:
>>> ...
>>> If headers with ETags do not add any value to the protocol. For
>>> GET rfc2616 already defines If-Match and friends. Since the ETag
>>> only captures content changes (property changes have undefined
>>> effect on ETags), IF headers for ETag lack a use case.
>>
>> An etag in an If: header can be used to assert that a file has been
>> unchanged since you last fetched it. Specifically, that you still 
>> have the
>> locktoken *or* (you lost it and) it is unchanged.
>
> You can also see the following note on this subject:
> http://www.w3.org/1999/04/Editing/
> Thanks,
>
> --
> Yves Lafon - W3C
>

Received on Thursday, 25 April 2002 04:18:34 UTC