Subject: Summary of ETag related issues in RFC2518bis

From: Julian Reschke <[email-masked]>
Date: Mon, 19 Dec 2005 20:07:10 +0100

Hi,

below is a summary of issues related to changes to ETag handling 
requirements. Feedback appreciated.

Best regards, Julian

-- cut --

RFC25128bis has some new server requirements, and some more are 
currently discussed. All of them fall into the category of transforming 
WebDAV into a kind of distributed file system. I absolutely agree that 
this is one important scenario, and that many clients already assume 
that they can rely on these things. So it's a real-world use case, I 
just happen to think there are lots of others, and making WebDAV 
incompatible with these would be a step into the wrong direction.

The individual changes that have been discussed (or dropped into the 
draft are):

R1) Require servers to support strong entity tags,

R2) Require servers to return entity tags for PUT requests,

R3) Require ETags not to change when only properties or lock state change,

R4) Require servers to store arbitrary binary content,

R5) Require servers to store dead properties,

R6) Require servers to use persist Content-Type upon PUT.

(If there are more, please let me know).

Let's discuss them one by one:

R1) Require servers to support strong entity tags

Weak ETags are adequate for cacheing (optimizing GET operations), but 
not authoring (they can't be used with PUT):

"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."

So I do agree that putting in a SHOULD support strong ETags makes sense, 
as long as we don't make existing compliant servers non-compliant. That 
is, we shouldn't require them to return anything upon PUT, and we also 
should let them upgrade weak ETags to strong ETags if that makes sense 
to them.

R2) Require servers to return entity tags for PUT requests

The idea is that a client that did a PUT immediately will know the etag 
for the entity, and can use that in future requests for syncing. The 
trouble here is that RFC2616 doesn't really define what it means to 
return an ETag upon PUT, see discussion thread at 
<http://lists.w3.org/Archives/Public/ietf-http-wg/2005OctDec/thread.html#13>. 
So, at a minimum the WebDAV WG will have to clarify what it means, and 
make *absolutely* sure that this clarification is added to the RFC2616 
errata.

Assuming we had consensus on what an ETag upon PUT means (such as "an 
ETag for the entity you'd get upon a subsequent GET"), I'm still not 
sure how this helps with syncing. Servers are allowed to rewrite content 
upon PUT, so a client would still need to do another GET in order to 
retrieve the new entity body (that is, except if we also require R4).

R3) Require ETags not to change when only properties or lock state change

This is just broken spec writing, sorry. The guarantee that HTTP gives 
us that the ETag will change if the content changes, that's it. Of 
course it's sub-optimal if the etag changes when the content didn't, but 
a server may have very good reasons to do so. So yes, if the Etag 
changes the client may have to resync, just to find out that nothing 
changed, after all.

I do understand that clients ran into problems because of repeating the 
sequence

   PUT, then PROPPATCH

assuming that PROPPATCH wouldn't modify the ETag. As far as I can tell, 
a safe way to do this seems to be

   PUT, the PROPPATCH and HEAD to get the current ETag

(potentially with a WebDAV lock).

R4) Require servers to store arbitrary binary content

There are servers that don't, examples may be Atom servers, Calendaring 
servers, and any kind of server that uses HTTP/Webdav to expose specific 
types of resources with no generic store available.

Even if this would not be the case, I have to point out that the spec 
currently mentions scenarios where servers may rewrite content without 
notice (see 
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-rfc2518bis-09.html#rfc.section.19.8>).

R5) Require servers to store dead properties

RFC2518 says this is a SHOULD. Meaning, servers may not allow it, and I 
think this clearly reflects reality. Checking for PROPPATCH in the 
"Allow" header will not always work, because there may be servers which 
support PROPPATCH for just a limited set of properties (such as a server 
that only supports setting properties in a single namespace - no 
kidding, that one exists).

R6) Require servers to use persist Content-Type upon PUT

I think that's the best thing to do, but there are servers / resource 
types which will ignore that, and (try to) detect the type on their own. 
  IMHO that's not optimal, but given the fact it's the preference stated 
in an upcoming TAG finding 
(<http://www.w3.org/2001/tag/doc/mime-respect-20051205>), I don't think 
we can make this more than a SHOULD.

So what next?

I strongly object to any attempt to transform WebDAV into something like 
NFS over HTTP. WebDAV is an *extension* to HTTP; and HTTP has been 
designed for a wide variety of resource types, not only serving files. 
The good thing is that I'm almost sure that the IESG wouldn't let us do 
that anyway.

On the other hand, I do understand that certain types of clients will 
not work well with servers that can't provide some of these features. 
Those who like to add new requirements thus should gather feedback from 
the client implementors, collecting information so that we really 
understand what these requirements are (right now it seems we're still 
guessing). My feeling is that this will include

a) support for strong etags
b) some way of discovering whether a given resource will allow storing 
arbitrary contents, or just some specific content type
c) some way of discovering whether a given resource will allow storing 
arbitrary dead properties

If this is what these clients need, let's extend the spec so that they 
can find out. But if we can't finish this within the next few weeks, 
then I certainly think that we should leave things as they were in 
RFC2518, and have a separate spec take care of this.

---

From: Lisa Dusseault <[email-masked]>
Date: Mon, 19 Dec 2005 11:23:18 -0800

Most of these things came up in interoperability tests, and it seems  
from those experiences that most existing WebDAV clients expect servers  
to behave as remote file systems.  It's the most common use case out  
there and the reason why WebDAV is now deployed on all Windows and Mac  
platforms.

Other uses of WebDAV are emerging and sometimes these do not need all  
these requirements or some such requirements might even be harmful to  
certain cases as you point out.

Thus, I'd be happy with a new compliance class that a server could use  
to advertise this set of capabilities.  Some existing servers would be  
able to advertise that almost immediately.  That new compliance class  
probably shouldn't be called 'bis' - perhaps we can come up with  
another word or declare this as level 3 because it's still rather core  
stuff.

Lisa

On Dec 19, 2005, at 11:07 AM, Julian Reschke wrote:

> currently discussed. All of them fall into the category of  
> transforming WebDAV into a kind of distributed file system. I  
> absolutely agree that this is one important scenario, and that many  
> clients already assume that they can rely on these things. So it's a  
> real-world use case, I just happen to think there are lots of others,  
> and making WebDAV incompatible with these would be a step into the  
> wrong direction.
>
> validators or strong validators. Clients MUST NOT use weak validators  
> in other forms of request."
>
> So I do agree that putting in a SHOULD support strong ETags makes  
> sense, as long as we don't make existing compliant servers  
> non-compliant. That is, we shouldn't require them to return anything  
> upon PUT, and we also should let them upgrade weak ETags to strong  
> ETags if that makes sense to them.
>
>
> The idea is that a client that did a PUT immediately will know the  
> etag for the entity, and can use that in future requests for syncing.  
> The trouble here is that RFC2616 doesn't really define what it means  
> to return an ETag upon PUT, see discussion thread at  
> <http://lists.w3.org/Archives/Public/ietf-http-wg/2005OctDec/ 
> thread.html#13>. So, at a minimum the WebDAV WG will have to clarify  
> what it means, and make *absolutely* sure that this clarification is  
> added to the RFC2616 errata.
>
> sure how this helps with syncing. Servers are allowed to rewrite  
> content upon PUT, so a client would still need to do another GET in  
> order to retrieve the new entity body (that is, except if we also  
> require R4).
>
>
> course it's sub-optimal if the etag changes when the content didn't,  
> but a server may have very good reasons to do so. So yes, if the Etag  
> I do understand that clients ran into problems because of repeating  
> the sequence
>
>   PUT, then PROPPATCH
>
> assuming that PROPPATCH wouldn't modify the ETag. As far as I can  
> tell, a safe way to do this seems to be
>
> There are servers that don't, examples may be Atom servers,  
> Calendaring servers, and any kind of server that uses HTTP/Webdav to  
> expose specific types of resources with no generic store available.
>
> RFC2518 says this is a SHOULD. Meaning, servers may not allow it, and  
> I think this clearly reflects reality. Checking for PROPPATCH in the  
> "Allow" header will not always work, because there may be servers  
> which support PROPPATCH for just a limited set of properties (such as  
> a server that only supports setting properties in a single namespace -  
> no kidding, that one exists).
>
>
> types which will ignore that, and (try to) detect the type on their  
> own.  IMHO that's not optimal, but given the fact it's the preference  
> stated in an upcoming TAG finding  
> (<http://www.w3.org/2001/tag/doc/mime-respect-20051205>), I don't  
> think we can make this more than a SHOULD.
>
>
>
> So what next?
>
> I strongly object to any attempt to transform WebDAV into something  
> like NFS over HTTP. WebDAV is an *extension* to HTTP; and HTTP has  
> been designed for a wide variety of resource types, not only serving  
> files. The good thing is that I'm almost sure that the IESG wouldn't  
> let us do that anyway.
>
> Those who like to add new requirements thus should gather feedback  
> from the client implementors, collecting information so that we really

---

From: Jim Whitehead <[email-masked]>
Date: Mon, 19 Dec 2005 13:20:55 -0800

Julian,

Thank you for posting this issue summary.

 From a client perspective, what they need is a reliable Etag be  
returned by a successful PUT. I believe it's fine if that Etag is  
either weak or strong -- what is damaging for clients is when the  
Etag changes from weak to strong at some point after a successful  
PUT, since there is no reliable mechanism for the client to discover  
this has happened (yes, you can use polling, but there is no  
guarantee for how long you need to perform polling before you know  
you've received the final Etag).

The main client use for the Etag returned by PUT is ensuring that  
their locally cached state is the same as that held by the server.  
This requirement goes across multiple client types, and is not  
limited just to filesystem-like clients.

As a result, my views on the requirements below are as follows:

Not needed -- weak Etags are as good as strong etags for most uses.

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.

> This is just broken spec writing, sorry. The guarantee that HTTP  
> gives us that the ETag will change if the content changes, that's  
> it. Of course it's sub-optimal if the etag changes when the content  
> didn't, but a server may have very good reasons to do so. So yes,  
> if the Etag changes the client may have to resync, just to find out  
> that nothing changed, after all.

It is quite clear from reading RFC 2616 and RFC 2518 that the use of  
Etags was intended to describe the entity due to a GET response. The  
definitions of entity and etags are below (RFC 2616, section 1.3,  
3.11, 7.1).

entity
       The information transferred as the payload of a request or
       response. An entity consists of metainformation in the form of
       entity-header fields and content in the form of an entity- 
body, as
       described in section 7.

    A "strong entity tag" MAY be shared by two entities of a resource
    only if they are equivalent by octet equality.

    A "weak entity tag," indicated by the "W/" prefix, MAY be shared by
    two entities of a resource only if the entities are equivalent and
    could be substituted for each other with no significant change in
    semantics. A weak entity tag can only be used for weak comparison.

    Entity-header fields define metainformation about the entity-body  
or,
    if no body is present, about the resource identified by the request.
    Some of this metainformation is OPTIONAL; some might be REQUIRED by
    portions of this specification.

        entity-header  = Allow                    ; Section 14.7
                       | Content-Encoding         ; Section 14.11
                       | Content-Language         ; Section 14.12
                       | Content-Length           ; Section 14.13
                       | Content-Location         ; Section 14.14
                       | Content-MD5              ; Section 14.15
                       | Content-Range            ; Section 14.16
                       | Content-Type             ; Section 14.17
                       | Expires                  ; Section 14.21
                       | Last-Modified            ; Section 14.29
                       | extension-header

        extension-header = message-header

 From these definitions, it's clear that HTTP intended for only the  
metadata in the entity-header fields to be considered part of the  
entity. In particular, there are other kinds of metadata that are  
*not* included in the definition of an entity.

It seems to me we have a few choices.

* Stick closely to the HTTP notion of entity, in which case changes  
to the DAV:getcontentlanguage, DAV:getcontenttype,  
DAV:getcontentlength, and DAV:getlastmodified MUST affect the Etag,  
and changes to other properties MUST NOT affect the etag.

* Make a clear distinction between WebDAV properties and HTTP  
entities, stating that changes to WebDAV properties MUST NOT cause  
changes to HTTP entities.

* Consider WebDAV properties to be part of the state of the resource,  
even though they (except for the properties listed above) do not  
affect the entity (as defined by HTTP), and hence any change to a  
property MUST cause a change to the Etag.

I'll note that the third option seems to be the hardest one to defend  
based purely on the language of the HTTP specification.

Another solution is to introduce a new state token representing the  
dead property state. This token could be retrieved from a property,  
or available in a response header (perhaps for PROPFIND). This would  
allow WebDAV to discuss the impact of property changes on a state  
token without having to alter the definition of entity in HTTP.

This seems too strong to me. I think the requirement should be for  
clients to discover when a server does not accept arbitrary binary  
content, either by an appropriate error code for PUT, or via some  
other discovery mechanism (a property that exists that describes  
acceptable MIME types and/or XML schemas?)

Same as for R4.

> R6) Require servers to use persist Content-Type upon PUT.

I agree this is a SHOULD level requirement.

> been designed for a wide variety of resource types, not only  
> serving files. The good thing is that I'm almost sure that the IESG  
> wouldn't let us do that anyway.
>

I believe that these issues are more broad than just filesystem-like  
vs non-filesystem-like, and hence framing the issue as "what those  
filesystem-like clients need" is not productive.

- Jim

---

From: Julian Reschke <[email-masked]>
Date: Mon, 19 Dec 2005 22:50:31 +0100

Jim Whitehead wrote:
> returned by a successful PUT. I believe it's fine if that Etag is either 
> weak or strong -- what is damaging for clients is when the Etag changes 
> from weak to strong at some point after a successful PUT, since there is 
> no reliable mechanism for the client to discover this has happened (yes, 
> you can use polling, but there is no guarantee for how long you need to 
> perform polling before you know you've received the final Etag).

Note that weak ETags indeed can't be used with PUT (I was wrong on that 
in previous messages).

The weak-to-strong propagation in Apache IMHO is technically sound, as 
the semantics is compliant to HTTP, and (non-authoring) clients get the 
best out of it. The question is how to change this so that authoring 
clients will be happy as well.

Special-casing things IMHO will not work. In Apache, ETags are generated 
by httpd, not moddav, and thus are optimized for GET, not authoring.

> The main client use for the Etag returned by PUT is ensuring that their 
> locally cached state is the same as that held by the server. This 
> requirement goes across multiple client types, and is not limited just 
> to filesystem-like clients.
> 
> 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.

> definitions of entity and etags are below (RFC 2616, section 1.3, 3.11, 
> 7.1).
> 
> entity
>       entity-header fields and content in the form of an entity-body, as
>       described in section 7.
> 
> 
>    Entity-header fields define metainformation about the entity-body or,
> entity. In particular, there are other kinds of metadata that are *not* 
> included in the definition of an entity.
> 
> * Stick closely to the HTTP notion of entity, in which case changes to 
> the DAV:getcontentlanguage, DAV:getcontenttype, DAV:getcontentlength, 
> and DAV:getlastmodified MUST affect the Etag, and changes to other 
> properties MUST NOT affect the etag.

Jim, where does the "MUST NOT" come from??? A server that changes the 
ETag although the entity didn't change is completely compliant to the 
spec. Only the other direction (content change -> etag change) is a 
MUST, because it's relevant for interoperability (cache correctness).

A server that changes ETags although that wasn't necessary causes cache 
misses, that's it. It only becomes an issue for authoring clients.

> * Make a clear distinction between WebDAV properties and HTTP entities, 
> stating that changes to WebDAV properties MUST NOT cause changes to HTTP 
> entities.

I still don't see why we're using RFC2119 syntax here...

Anyway, if the issue is with clients that do a sequence of PROPPATCH/PUT 
(or the other way around), and we want them to be able to use the ETag 
in an "If" header, why don't we simply tell servers to return the ETag 
upon PROPPATCH if it changed?

In that case the client will always have the latest ETag, and it doesn't 
matter at all whether it changes with PROPPATCH or not.

> even though they (except for the properties listed above) do not affect 
> the entity (as defined by HTTP), and hence any change to a property MUST 
> cause a change to the Etag.

I don't think anybody likes that idea.

> Another solution is to introduce a new state token representing the dead 
> property state. This token could be retrieved from a property, or 
> available in a response header (perhaps for PROPFIND). This would allow 
> WebDAV to discuss the impact of property changes on a state token 
> without having to alter the definition of entity in HTTP.

That's also an interesting idea. I don't think it's relevant to this 
discussion, as servers that currently change ETags upon PROPPATCH do not 
do this because they feel it's a good idea, but because changing 
properties indeed causes a change to their backend that *results* in the 
ETag changing. So introducing a new state token wouldn't change that 
situation at all.

> content, either by an appropriate error code for PUT, or via some other 

<http://greenbytes.de/tech/webdav/rfc2616.html#status.415>

> discovery mechanism (a property that exists that describes acceptable 
> MIME types and/or XML schemas?)

Something like that. Certainly not in scope for RFC2518bis, right?

> R5) Require servers to store dead properties,

Yep.

> I agree this is a SHOULD level requirement.

So do I. Any help in arguing this with RoyF appreciated :-).

> I believe that these issues are more broad than just filesystem-like vs 
> non-filesystem-like, and hence framing the issue as "what those 

Point taken; but I still think we really need to make sure other use 
cases will not break. That would take away a lot of WebDAV's (and 
HTTP's) flexibility.  I really think that what we're talking about is a 
specific profile. Should we be able to converge on what the feature set 
is, all that's left to do is to give it a name and make it easily 
discoverable upfront.

Best regards, Julian

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 19 Dec 2005 14:07:49 -0800

Let's say Alice has a compliant webdav client that stores gif files, and Bob
has a compliant dav server? Will these things work together?

I can imagine a couple answers:

1) we don't know, it might work, it might not - there is really no way to
know

2) no Alice's client is not compliant because the only thing a webdav server
has to store is HTML

3) yes, given it passes policy constraints, such as no virus in gif file,
size of file, total size amount of quota, valid account and password, all is
fine...

I'm confused - which one of these does the WG want. This is actually a
specific instance of a meta issue. The meta issue is are we making things
easy for both client and server side in a way that causes it to be unclear
if the a client and server can actually work together.

I may not understand the issue here and I don't care how we solve it, but it
seems to me that a client and server should be able to work together.

few bits inline ...

> types of resources with no generic store available.

This seems irrelevant. They are not DAV servers, they are complain to some
other RFC that does use DAV as the protocol but adds additional constraints,
extensions, and semantics such as only iCal files can exists at a given URI.

> <http://greenbytes.de/tech/webdav/draft-ietf-webdav-rfc2518bis-09.html#rfc.sec

Again this example is more along the lines of a specific policy modification
that was done to the data to meet certain security requirements.

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 19 Dec 2005 14:11:45 -0800

> 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?

---

From: Jim Whitehead <[email-masked]>
Date: Mon, 19 Dec 2005 14:20:46 -0800

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

---

From: Julian Reschke <[email-masked]>
Date: Mon, 19 Dec 2005 23:50:30 +0100

> header that would prevent Etag being returned by PUT.

That's not the issue here.

The question here is whether an ETag returned upon PUT is for the entity 
the client sent (1), or for the entity the server would send upon a 
subsequent GET (2).

There are cases where both will not be the same, so this needs to be 
clarified. In case of (2), a client will need a subsequent GET if it's 
planning to use the ETag for subsequent GET/Range requests.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Mon, 19 Dec 2005 23:53:15 +0100

> 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

---

From: Julian Reschke <[email-masked]>
Date: Tue, 20 Dec 2005 00:03:39 +0100

> 1) we don't know, it might work, it might not - there is really no way to

As of now (RFC2616 + RFC2518), we don't know. A server is free to reject 
whatever it feels to. If anybody thinks this is not the case, please 
back that up with references to normative specification text.

But is it good that a client won't know until it tries, potentially 
getting a 415 status code? No, thus the proposal to make that feature 
discoverable.

> 2) no Alice's client is not compliant because the only thing a webdav server

Nobody is saying that, as far I can tell.

> size of file, total size amount of quota, valid account and password, all is

Nope.

> if the a client and server can actually work together.

I want servers to be able to do (1). I want clients to be able to detect 
(3). I want as many clients as possible to talk to servers that do not 
guarantee (3).

> seems to me that a client and server should be able to work together.

Yes.

> extensions, and semantics such as only iCal files can exists at a given URI.

I think there's a broad consensus that Calendaring servers and Atom 
servers should be able to be WebDAV servers as well.

> that was done to the data to meet certain security requirements. 

How does this make a difference to the client? It may either have to 
manage to live with a 4xx upon PUT, or with content being different from 
what he thought he stored. Yes, that's an edge case, but it's VERY 
similar to the case where a Calendaring server or an Atom server drops 
parts of the content that was PUT because it didn't fit with the 
servers's internal data model.

Best regards, Julian

---

From: Ted Hardie <[email-masked]>
Date: Mon, 19 Dec 2005 15:06:28 -0800

At 11:50 PM +0100 12/19/05, Julian Reschke wrote:
>>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.
>
>The question here is whether an ETag returned upon PUT is for the entity the client sent (1), or for the entity the server would send upon a subsequent GET (2).

I have personally always assumed that an ETag returned on a PUT is for the entity the client sent , and that if what the client would get at a subsequent GET was different, the ETag changed.  It's not clear to me how a subsequent range request would work interoperably if this were not the case, as it seems to require that the client understand what transformation the server is going to perform (that is, the client would have to somehow know what the bits would be after its PUT).   It certainly seems easier to me to code a conditional with this assumption.

Just my personal opinion,
			regards,
				Ted Hardie

---

From: Yves Lafon <[email-masked]>
Date: Tue, 20 Dec 2005 00:09:12 +0100 (MET)

On Mon, 19 Dec 2005, Julian Reschke wrote:

>> 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.
>
> The question here is whether an ETag returned upon PUT is for the entity the 
> client sent (1), or for the entity the server would send upon a subsequent 
> GET (2).

My implementation returns the ETag that asubsequent GET would see, so 
option (2). Ans I am in the case where the PUT entity and the served 
entity will not be the same, as there are CVS actions done during the PUT, 
so possible keyword extensions, etc...

-- 
Yves Lafon - W3C
"Baroula que barouleras, au tiéu toujou t'entourneras."

---

From: Ted Hardie <[email-masked]>
Date: Mon, 19 Dec 2005 15:20:02 -0800

At 12:09 AM +0100 12/20/05, Yves Lafon wrote:
>
>
>My implementation returns the ETag that asubsequent GET would see, so option (2). Ans I am in the case where the PUT entity and the served entity will not be the same, as there are CVS actions done during the PUT, so possible keyword extensions, etc...

Are these property changes, or changes to the entity itself?  If to the entity, how does a get-range work?
			regards,
					Ted Hardie

---

From: Julian Reschke <[email-masked]>
Date: Tue, 20 Dec 2005 00:18:24 +0100

> Just my personal opinion,

Ted,

thanks a lot for the feedback. As a matter of fact, I thought the same 
until recently when I asked on the HTTP mailing list. Scott Lawrence 
(<http://lists.w3.org/Archives/Public/ietf-http-wg/2005OctDec/0014.html>), 
  Mark Baker 
(<http://lists.w3.org/Archives/Public/ietf-http-wg/2005OctDec/0016.html>), 
and Henrik Frystyk Nielsen 
(<http://lists.w3.org/Archives/Public/ietf-http-wg/2005OctDec/0017.html>) 
  disagreed with that point of view (and this was the only feedback, 
except for agreement that RFC2616 should be clarified).

This is why I think that we shouldn't PUT^h^h^hput in this requirement 
unless we tell people what it means, and we make sure we are in 
agreement with what a potential revision of RFC2616 is going to say 
about it.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Tue, 20 Dec 2005 00:28:52 +0100

> Are these property changes, or changes to the entity itself?  If to the entity, how does a get-range work?

My interpretation is that a GET/Range will not work, that is, a client 
which obtained an ETag upon PUT will have to *know* that the content may 
have been rewritten before the ETag as assigned.

This is exactly why I'm keep telling people that we need to decide what 
the ETag means, and also make sure that what we're saying is the same 
thing that RFC2616bis is going to say (should it ever become reality).

Best regards, Julian

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 19 Dec 2005 16:11:48 -0800

> getting a 415 status code? No, thus the proposal to make that feature

Ok, so what is your advice to client implementers? Do you want to specify
something they can count on working? XML works? 7 bit ascii works? XHTML
works? Getting a 415 might tell you the end user why it failed (though
probably not given most client software) but it is not going to make it
work. 

If people are comfortable with there is no guarantee that even the most
trivial things will interoperate with this protocol, I'm not pushing it. I'm
just a checking that I correctly understand this as I find it slightly
surprising. 

Cullen

---

From: Wilfredo Sánchez Vega <[email-masked]>
Date: Mon, 19 Dec 2005 17:13:48 -0800

There is no such thing as a final etag value.  Why pretend there  
is?  The tag could change for any number of reasons, including  
someone coming along and changing the content right after your PUT.

   Absent some reliable notification mechanism, there is no way to  
know that your locally cached copy is what's presently on the server,  
regardless of whether the server gives you a stable etag in the PUT  
response or not.  So this requirement doesn't get you what you are  
wishing for.

	-wsv

On Dec 19, 2005, at 1:20 PM, Jim Whitehead wrote:

> 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.

---

From: Wilfredo Sánchez Vega <[email-masked]>
Date: Mon, 19 Dec 2005 17:13:39 -0800

The second option seems impossible.  If modifying the last- 
modified time on an HTTP entity MUST change the etag and modifying  
DAV:getlastmodified MUST NOT, that's contradictory, give the  
definition of DAV:getlastmodified.

   I don't think any of these three options makes sense as a  
requirement.

	-wsv

On Dec 19, 2005, at 1:20 PM, Jim Whitehead wrote:

> * Consider WebDAV properties to be part of the state of the  
> resource, even though they (except for the properties listed above)  
> do not affect the entity (as defined by HTTP), and hence any change  
> to a property MUST cause a change to the Etag.
>
> I'll note that the third option seems to be the hardest one to  
> defend based purely on the language of the HTTP specification.

---

From: Jim Whitehead <[email-masked]>
Date: Mon, 19 Dec 2005 18:11:02 -0800

Julian,

Thanks for making this more clear -- you're right, there is a  
significant issue here.

> The question here is whether an ETag returned upon PUT is for the  
> entity the client sent (1), or for the entity the server would send  
> upon a subsequent GET (2).
>
> There are cases where both will not be the same, so this needs to  
> be clarified. In case of (2), a client will need a subsequent GET  
> if it's planning to use the ETag for subsequent GET/Range requests.
>

I think option #2 is the best one here (the Etag returned by PUT is  
the one a subsequent GET would retrieve).

- Jim

---

From: Jim Whitehead <[email-masked]>
Date: Mon, 19 Dec 2005 18:16:03 -0800

If I'm a client that has an exclusive write lock, then if I PUT to  
that resource, the stored entity should not be modified by anyone  
other than the server. In this case, which is the most common one for  
DAV-based editing, it's still very useful for the client to receive  
the final etag value in the response to PUT. Why? It saves the client  
from having to poll an uncertain number of times before it receives  
the final, stable etag value.

I still feel that R2 is required.

- Jim

On Dec 19, 2005, at 5:13 PM, Wilfredo Sánchez Vega wrote:

> know that your locally cached copy is what's presently on the  
> server, regardless of whether the server gives you a stable etag in  
> the PUT response or not.  So this requirement doesn't get you what  
> you are wishing for.
>
> 	-wsv
>
>
>> 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.
>

---

From: "Dan Brotsky" <[email-masked]>
Date: Mon, 19 Dec 2005 18:23:58 -0800

I strongly agree with Jim's use case and conclusion.  That's the key issue: the client shouldn't have to poll to wait for the etag to stabilize.

    dan

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Jim Whitehead
> Sent: Monday, December 19, 2005 18:16
> To: Wilfredo Sánchez Vega
> Cc: Julian Reschke; WebDav WG
> Subject: Re: Summary of ETag related issues in RFC2518bis
> 
> 
> If I'm a client that has an exclusive write lock, then if I 
> PUT to that resource, the stored entity should not be 
> modified by anyone other than the server. In this case, which 
> is the most common one for DAV-based editing, it's still very 
> useful for the client to receive the final etag value in the 
> response to PUT. Why? It saves the client from having to poll 
> an uncertain number of times before it receives the final, 
> stable etag value.
> 
> >   There is no such thing as a final etag value.  Why 
> pretend there is?  
> > The tag could change for any number of reasons, including someone 
> > coming along and changing the content right after your PUT.
> >
> >   Absent some reliable notification mechanism, there is no 
> way to know 
> > that your locally cached copy is what's presently on the server, 
> >> 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.
> >
> 
> 
>

---

From: Wilfredo Sánchez Vega <[email-masked]>
Date: Mon, 19 Dec 2005 18:57:34 -0800

OK, I follow.

   The question then is how one would implement than on a server  
using a filesystem as the backing store, which is a *very* common  
case (Apache).  The information have from the filesystem doesn't seem  
to give us enough data without doing something like checksumming the  
file.  The performance implications of that solution are rather drastic.

   Absent a workable solution, we're going to be moving Apache into  
the non-compliant category if this is a MUST-level requirement.

	-wsv

On Dec 19, 2005, at 6:16 PM, Jim Whitehead wrote:

> other than the server. In this case, which is the most common one  
> for DAV-based editing, it's still very useful for the client to  
> receive the final etag value in the response to PUT. Why? It saves  
> the client from having to poll an uncertain number of times before  
> it receives the final, stable etag value.
>

---

From: "Dan Brotsky" <[email-masked]>
Date: Mon, 19 Dec 2005 21:15:39 -0800

>    The question then is how one would implement than on a 
> server using a filesystem as the backing store, which is a 
> *very* common case (Apache).  The information have from the 
> filesystem doesn't seem to give us enough data without doing 
> something like checksumming the file.  The performance 
> implications of that solution are rather drastic.

First of all, there are many filesystems in the world that accurate to way more than 1 millisecond, so I don't think a general statement such as "the filesystem doesn't seem to give us enough data" is really applicable.

Second, even in filesystems with millisecond resolutions, all the filesystem has to do is support exclusive write-locking and you can build a compliant server.  The server must simply keep the file locked long enough to avoid the milllisecond window and then set the time back to the write time in order to ensure that any interference is noticeable.

I don't have any problem with a standard that can't be implemented in the simplest possible way against the weakest possible resources.  All we are saying is that, if you really have a filesystem that allows multiple writers to interfere with one another undetectably, then you can't build a compliant WebDAV server against that filesystem.  And that's just a fact: the server certainly can't guarantee anything without support from the filesystem.

> 
>    Absent a workable solution, we're going to be moving 
> Apache into the non-compliant category if this is a 
> MUST-level requirement.

I think there are many workable solutions over standard filesystems for this problem.

    dan

---

From: Julian Reschke <[email-masked]>
Date: Tue, 20 Dec 2005 09:00:44 +0100

> just a checking that I correctly understand this as I find it slightly

Please do not forget telling people what the alternative is. For 
instance, that you can't use a Microsoft WebFolder client for uploading 
to or namespace operations on your server, just because it happens to be 
   a special type of server.

For instance, would you rule out flickr.com allowing renaming (MOVE), 
metadata administration (PROPFIND/PROPPATCH) or uploading (PUT) using an 
off-the-shelf WebDAV client, just because it won't be able to work with 
anything except image files?

That's what making support for arbitrary content required would mean, 
and server implementors would only have the choice to remove WebDAV 
support, or to break the spec.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Tue, 20 Dec 2005 09:03:55 +0100

Jim Whitehead wrote:
> I think option #2 is the best one here (the Etag returned by PUT is the 
> one a subsequent GET would retrieve).

So given the fact people like Ted and myself got this wrong, and that 
people on the HTTP WG seem to agree this area is underspecified, what do 
we do?

-1 on putting in new requirements into the spec that may be incompatible 
with RFC2616. +1 on getting that clarified in RFC2616's errata. Volunteers?

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Tue, 20 Dec 2005 09:06:07 +0100

Jim Whitehead wrote:
> 
> If I'm a client that has an exclusive write lock, then if I PUT to that 
> resource, the stored entity should not be modified by anyone other than 
> the server. In this case, which is the most common one for DAV-based 
> editing, it's still very useful for the client to receive the final etag 
> value in the response to PUT. Why? It saves the client from having to 
> poll an uncertain number of times before it receives the final, stable 
> etag value.

Well. If the client has the lock, why would it need the ETag in the 
first place?

 > ...

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Tue, 20 Dec 2005 09:46:52 +0100

> First of all, there are many filesystems in the world that accurate to way more than 1 millisecond, so I don't think a general statement such as "the filesystem doesn't seem to give us enough data"…

Depends on what the target platform is. Apache is built on top of APR, 
(Apache Portable Runtime) as I recall, and that API may not have a 
guarantee of a higher timer resolution. What would be your proposal to 
the Apache guys how to handle that?

> Second, even in filesystems with millisecond resolutions, all the filesystem has to do is support exclusive write-locking and you can build a compliant server.  The server must simply keep the file…

You mean "second" resolution, right? Two problems here:

1) Doing that may not be acceptable for mass uploads, where millions of 
documents need to be uploaded (don't tell me this isn't a use case...).

2) Even then, it's not that simple. ETag and Last-Modified also have to 
be adjusted after COPY and notably MOVE (!).

But it seems that there's a simple way to fix this (for Apache): should 
a client require a strong ETag upon PUT, it could make that explicit in 
the request (new header?), so that the server can just special-case 
this, and do what's needed to ensure the ETag is stable. Wilfredo?

> I don't have any problem with a standard that can't be implemented in the simplest possible way against the weakest possible resources.  All we are saying is that, if you really have a filesystem t…

I disagree with the statement that this kind of server is non-compliant. 
Are you saying that Apache/moddav is non-compliant?

> I think there are many workable solutions over standard filesystems for this problem.

This discussion isn't new. As a matter of fact, it started at least two 
years ago. As of now, nothing in Apache/moddav has changed. I take that 
as indication that changing the server may not be as trivial as some 
people think.

So, Dan, can you make a concrete proposal how to change Apache/moddav?

Best regards, Julian

---

From: Wilfredo Sánchez Vega <[email-masked]>
Date: Tue, 20 Dec 2005 13:54:49 -0800

I don't see how that would help.  For one, I suspect may clients  
will ask for this all the time, so then why not do it for all clients  
all the time?  I'm not opposed to giving you the strong ETag, I just  
don't know how to do it.

   One possibility is not to return an ETag at all on PUT, nor for  
GET requests in the first second, and only return the strong ETag  
once we know what it is.  This eliminates the weak ETag altogether.

   The advantage here is that while the client would have to poll a  
few times to get the ETag, it would now when it got the "final" ETag  
that Jim is advocating for, once it got any ETag at all.  However,  
for the first second, the file would not be cacheable, which is more  
or less correct anyway.

	-wsv

On Dec 20, 2005, at 12:46 AM, Julian Reschke wrote:

> But it seems that there's a simple way to fix this (for Apache):  
> should a client require a strong ETag upon PUT, it could make that  
> explicit in the request (new header?), so that the server can just  
> special-case this, and do what's needed to ensure the ETag is  
> stable. Wilfredo?

---

From: Lisa Dusseault <[email-masked]>
Date: Tue, 20 Dec 2005 14:06:27 -0800

Perhaps Content-MD5 would help solve a number of these issues in a much 
cleaner way.  It doesn't do away with ETags I suspect, but can help 
with PUT equivalence.

Lisa

On Dec 20, 2005, at 1:54 PM, Wilfredo Sánchez Vega wrote:

>   One possibility is not to return an ETag at all on PUT, nor for GET 
> requests in the first second, and only return the strong ETag once we 
> know what it is.  This eliminates the weak ETag altogether.
>
>   The advantage here is that while the client would have to poll a few 
> times to get the ETag, it would now when it got the "final" ETag that 
> Jim is advocating for, once it got any ETag at all.  However, for the 
> first second, the file would not be cacheable, which is more or less 
> correct anyway.
>
> 	-wsv
>
>
>> special-case this, and do what's needed to ensure the ETag is stable. 
>> Wilfredo?
>
>

---

From: Wilfredo Sánchez Vega <[email-masked]>
Date: Tue, 20 Dec 2005 15:14:07 -0800

This makes sense, assuming Content-MD5 on the PUT response  
describes what the server is storing.  The client can then use that  
to compare with what they send and thus detect that the server stored  
something different.  This would avoid the need for a subsequent GET  
request if the checksum matches what was sent.

	-wsv

On Dec 20, 2005, at 2:06 PM, Lisa Dusseault wrote:

>
> Perhaps Content-MD5 would help solve a number of these issues in a  
> much cleaner way.  It doesn't do away with ETags I suspect, but can  
> help with PUT equivalence.
>
> Lisa
>
>> will ask for this all the time, so then why not do it for all  
>> clients all the time?  I'm not opposed to giving you the strong  
>> ETag, I just don't know how to do it.
>>
>> few times to get the ETag, it would now when it got the "final"  
>> ETag that Jim is advocating for, once it got any ETag at all.   
>> However, for the first second, the file would not be cacheable,  
>> which is more or less correct anyway.
>>
>> 	-wsv
>>
>>
>>> should a client require a strong ETag upon PUT, it could make  
>>> that explicit in the request (new header?), so that the server  
>>> can just special-case this, and do what's needed to ensure the  
>>> ETag is stable. Wilfredo?
>>
>>
>

---

From: Julian Reschke <[email-masked]>
Date: Wed, 21 Dec 2005 01:32:21 +0100

Wilfredo Sánchez Vega wrote:
> 
>   I don't see how that would help.  For one, I suspect may clients will 
> ask for this all the time, so then why not do it for all clients all the 
> time?  I'm not opposed to giving you the strong ETag, I just don't know 
> how to do it.

You could do it for the case of PUT by pausing for 1 second, right? This 
is exactly why I wouldn't want that to be the default.

> first second, the file would not be cacheable, which is more or less 

That's correct, but how is a client supposed to know that retrying will 
return a strong ETag later? It may talk to a resource that doesn't have 
ETags at all.

Best regards, Julian

---

From: Wilfredo Sánchez Vega <[email-masked]>
Date: Tue, 20 Dec 2005 16:56:16 -0800

Yeah, but I don't think I could sell that implementation to the  
rest of httpd-dev, even optionally.

	-wsv

On Dec 20, 2005, at 4:32 PM, Julian Reschke wrote:

> You could do it for the case of PUT by pausing for 1 second, right?  
> This is exactly why I wouldn't want that to be the default.

---

From: "Dan Brotsky" <[email-masked]>
Date: Tue, 20 Dec 2005 21:51:35 -0800

> Well. If the client has the lock, why would it need the ETag 
> in the first place?

Because servers can still write files when they are locked, and because losing a lock doesn't mean that you don't have up-to-date content.

One of the primary uses, if not *the primary use*, of etags in a collaborative authoring environment is so clients can know whether or not they have current content.  When a client authors a file and places it on the server, it doesn't want to have to fetch the file again unless necessary, and it doesn't want to have to do more roundtrips before continuing with work on that and other files.

Let me ask the  converse question: If the server has the file, why can't it send the etag?  That's all the spec is saying it should do.

    dan

---

From: "Dan Brotsky" <[email-masked]>
Date: Tue, 20 Dec 2005 22:03:31 -0800

> Depends on what the target platform is. Apache is built on 
> top of APR, (Apache Portable Runtime) as I recall, and that 
> API may not have a guarantee of a higher timer resolution. 
> What would be your proposal to the Apache guys how to handle that?

I gave one below.

> Second, even in filesystems with millisecond resolutions, 
> all the filesystem has to do is support exclusive 
> write-locking and you can build a compliant server.  The 
> server must simply keep the file locked long enough to avoid 
> the milllisecond window and then set the time back to the 
> write time in order to ensure that any interference is noticeable.
> 
> You mean "second" resolution, right?

No, I meant millisecond.  Perhaps you are sugggesting that APR only supports 1-second resolution?  Why would that be?  I know of no filesystems with that kind of resolution.

> Two problems here:
> 
> 1) Doing that may not be acceptable for mass uploads, where 
> millions of documents need to be uploaded (don't tell me this 
> isn't a use case...).

Sure it's a use case.  But you don't explain why it's not acceptable.

> 
> 2) Even then, it's not that simple. ETag and Last-Modified 
> also have to be adjusted after COPY and notably MOVE (!).

It's exactly that simple.  Because COPY and MOVE don't suffer the non-interference problem (on the target, that is), because the target doesn't exist for someone to have open.

> > I don't have any problem with a standard that can't be 
> implemented in the simplest possible way against the weakest 
> possible resources.  All we are saying is that, if you really 
> have a filesystem that allows multiple writers to interfere 
> with one another undetectably, then you can't build a 
> compliant WebDAV server against that filesystem.  And that's 
> just a fact: the server certainly can't guarantee anything 
> without support from the filesystem.
> 

I have no opinion about this.  If I were working on Apache I never would have been returning weak etags in the first place.  I would be putting together the timestamp and filesize returned by the fs and using that as the etag in the first place.  If someone complained that they ran into a case where some other process wrote the file at exactly the same millisecond and exactly the same size and I reported the same etag when in fact they claimed the content was different, then I would say "whoops, sorry, that's a bug, and it's a never-fix bug because the use cases where it's a problem so rare and so hard to fix (see pain-in-the-rear solution above) that it's not worth fixing.  If you want to make that bug go away use a real filesystem with microsecond resolution for your server."

> Apache into 
> This discussion isn't new. As a matter of fact, it started at 
> least two years ago. As of now, nothing in Apache/moddav has 
> changed. I take that as indication that changing the server 
> may not be as trivial as some people think.

No, I take that as an indication that everyone agrees that this bug is only there conceptually and that it never actually occurs in the field.  I know for a fact that the Adobe client implementations just ignored the weak marking on the etag and that's why they were interoperable with Apache.

> So, Dan, can you make a concrete proposal how to change Apache/moddav?

Yes: stop returning weak etags.  See above.

    dan

---

From: Yves Lafon <[email-masked]>
Date: Wed, 21 Dec 2005 11:05:08 +0100 (MET)

> No, I meant millisecond.  Perhaps you are sugggesting that APR only supports 1-second resolution?  Why would that be?  I know of no filesystems with that kind of resolution.

Well, the issue started with Apache using weak ETags, then strong ones. 
Note that the ETag is an opaque string, the way it is computed is up to 
the server. If a server want to use the md5 sum as the ETag, it is 
entirely possible, the choice to use the timestamp and length is part of 
Apache's design. Try to use "ContentDigest on" on big files and you will 
understand why.

My server knows how to handle x != GET(PUT(x)) for subsequent revision 
(well because cvs knows), it handles itself the issue, without any need 
from the client to know what's really going on behind the scene.

The discussion boils down to:
After a PUT, is it safe to continue to edit the resource without doing 
a reload?
And the server should give the answer. 205 if it is not safe, 204 
otherwise, with the ETag that someone will get in a subsequent GET.

> Yes: stop returning weak etags.  See above.

"on PUT". Agreed.

---

From: Yves Lafon <[email-masked]>
Date: Wed, 21 Dec 2005 11:11:33 +0100 (MET)

On Mon, 19 Dec 2005, Ted Hardie wrote:

>> entity will not be the same, as there are CVS actions done during the 
>> PUT, so possible keyword extensions, etc...
>

To the entity itself, a GET-range based on what has been PUT will 
obiouvsly fail (but it can fail for many other reason, like going through 
a proxy cache that goes offline between the PUT and the GET and serv stale 
content).

---

From: Julian Reschke <[email-masked]>
Date: Wed, 21 Dec 2005 16:23:01 +0100

>> What would be your proposal to the Apache guys how to handle that?

Sorry, I don't understand what your proposal exactly is.

> No, I meant millisecond.  Perhaps you are sugggesting that APR only supports 1-second resolution?  Why would that be?  I know of no filesystems with that kind of resolution.

I'm not sure why that would be, but the code in http_etag.c certainly 
uses a hardwired constant for this. Maybe this is fixable, in which case 
the problem would go away. Wilfredo?

> Sure it's a use case.  But you don't explain why it's not acceptable.

On a fast link, it would slow down mass uploads unacceptably.

> It's exactly that simple.  Because COPY and MOVE don't suffer the non-interference problem (on the target, that is), because the target doesn't exist for someone to have open.

I'm not sure I understand this. Let's try again; the considerations for 
generating valid ETags apply to all methods that change URL mappings 
(COPY, MOVE, PUT) as well. Are you disagreeing with that?

> Yes: stop returning weak etags.  See above.

So instead return nothing at all, or a strong one?

Best regards, Julian

---

From: Lisa Dusseault <[email-masked]>
Date: Wed, 21 Dec 2005 08:37:54 -0800

> otherwise, with the ETag that someone will get in a subsequent GET.
Thanks Yves, I can't believe nobody noticed the relevance of 205 
earlier in these discussions.  It would indeed be a good response to 
use and could even include an ETag if we define what that means.

Lisa

---

From: Julian Reschke <[email-masked]>
Date: Thu, 22 Dec 2005 07:30:46 +0100

> Because servers can still write files when they are locked, and because losing a lock doesn't mean that you don't have up-to-date content.

1) If a server changes the contents of the file, and the client updates 
it again, without resyncing, why would that be a problem? I would assume 
that after applying the server-rewrite functionality (keyword expansion, 
virus checking, script stripping, property inclusion into the 
resource....), the result will be the same in both cases.

2) I still think that losing a lock is an edge case that we don't need 
to optimize for.

Yes.

> Let me ask the  converse question: If the server has the file, why can't it send the etag?  That's all the spec is saying it should do.

1) RFC2518 isn't saying it
2) RFC2616 doesn't say what that means (or if it does it's doing that in 
such a vague way that reasonable people disagreed about what it means)
3) The most widely deployed servers do not return an ETag (IIS 5.1, does 
anybody know about IIS 6), or return a weak ETag first

So this would be a normative change introducing a less-than-well-defined 
requirement, which doesn't even reflect what most servers do today.

So my proposal is to resolve 2) first, and then discuss an extension of 
RFC2518 that relies on it (conceivably containing other stuff like the 
requirement to store arbitrary dead properties and such). I really don't 
see how we can get this done in the time that has been allocated to us.

Best regards, Julian

---

From: Geoffrey M Clemm <[email-masked]>
Date: Thu, 22 Dec 2005 09:00:24 -0500

I agree with Julian that this is not something we should try to resolve
in 2518bis, and given the need to focus this group on 2518bis, 
I will restrain myself from using up any additional working group 
bandwidth
on this (from my perspective, interesting) topic until 2518bis (and BIND)
is finalized.

Cheers,
Geoff

Julian wrote on 12/22/2005 01:30:46 AM:
> > Let me ask the  converse question: If the server has the file, why
> > can't it send the etag?  That's all the spec is saying it should do.
>

---

From: Wilfredo Sánchez Vega <[email-masked]>
Date: Thu, 22 Dec 2005 17:24:51 -0800

Well, if it's fixable it's fixable down to one millisecond instead  
of second.  I'm not sure why the window is one second.  I agree that  
would be better, but you still have a (shorter) window.

   I can ask on the httpd list to see if anyone knows why our window  
is one second when apr_time_t is in milliseconds... but I'll wait to  
do that after the holiday break.  I'm betting there's some filesystem  
with a one second resolution out there...  If it's an OS limitation  
(as opposed to a filesystem one) we can probably contain the damage  
to that OS.

	-wsv

On Dec 21, 2005, at 7:23 AM, Julian Reschke wrote:

> I'm not sure why that would be, but the code in http_etag.c  
> certainly uses a hardwired constant for this. Maybe this is  
> fixable, in which case the problem would go away. Wilfredo?

---

From: "Dan Brotsky" <[email-masked]>
Date: Thu, 22 Dec 2005 18:49:02 -0800

I agree we won't get this done for 2518bis.  Too bad.  Clients will just
have to keep sending head after put, and hoping nothing changed in
between.
 
    dan

________________________________

	From: [email-masked]
[mailto:[email-masked]] On Behalf Of Geoffrey M Clemm
	Sent: Thursday, December 22, 2005 06:00
	To: webdav
	Subject: Re: Summary of ETag related issues in RFC2518bis

	I agree with Julian that this is not something we should try to
resolve 
	in 2518bis, and given the need to focus this group on 2518bis, 
	I will restrain myself from using up any additional working
group bandwidth 
	on this (from my perspective, interesting) topic until 2518bis
(and BIND) 
	is finalized. 
	
	Cheers, 
	Geoff