Subject: i22: ETags on PUT responses

From: Mark Nottingham <[email-masked]>
Date: Fri, 4 Jan 2008 16:19:43 +1100

<http://tools.ietf.org/wg/httpbis/trac/ticket/22>

In Vancouver, discussion focused on the definition of ETag as a  
response header, rather than an entity header; 2616 says:

> The ETag response-header field provides the current value of the  
> entity tag for the requested variant.

and:
> The response-header fields allow the server to pass additional  
> information about the response which cannot be placed in the Status-  
> Line. These header fields give information about the server and  
> about further access to the resource identified by the Request-URI.
>

Below, I'll try to summarise my understanding of where we now sit;  
please correct me if I haven't got it right.

A client sends a PUT request Rq to resource A, returning ETag E in  
response Rs.

E applies not to Rs, nor Rq, but to the response that would be  
generated if a GET request to A were made immediately after the PUT,  
with any selecting headers applied.

Likewise, a client sends a POST request Rq' to resource A, returning  
ETag E' in response Rs', which also contains a Content-Location header  
pointing to A'.

E' applies not to Rs' or to Rq', nor to A', but again to the response  
that would be generated if a GET request to A were made immediately  
after the POST, with any selecting headers applied.

The same not only applies to ETag, but also appears to apply to Vary  
(being a response header, and also being necessary to indicate which  
headers would be used to select the variant).

If this is the case, it seems like the resolution to i22 is to;

1) clarify the nature of ETag as a response header (e.g., giving  
examples, rewording text)
2) note that some implementations may behave differently, based upon  
prior agreement with clients.

#1 is probably going to involve the resolution of i69 to some degree.

Make sense?

--
Mark Nottingham     http://www.mnot.net/

---

From: Julian Reschke <[email-masked]>
Date: Fri, 04 Jan 2008 15:43:13 +0100

Mark Nottingham wrote:
> In Vancouver, discussion focused on the definition of ETag as a response 
> header, rather than an entity header; 2616 says:
> 
>> Line. These header fields give information about the server and about 
>> further access to the resource identified by the Request-URI.
>>
> 
> ...

For the record: this exactly matches my understanding since this topic 
was brought up over two years ago over here.

In particular:

- E does not apply to Rq

- the presence of E in Rs does not necessarily imply that the body sent 
with PUT was stored octet-by-octet

- E does not depend on the request method, just on URI & selecting headers

And yes, this needs to be resolved in sync with 
<http://www3.tools.ietf.org/wg/httpbis/trac/ticket/69>

BR, Julian

---

From: Werner Baumann <[email-masked]>
Date: Fri, 04 Jan 2008 22:14:11 +0100

> - E does not depend on the request method, just on URI & selecting headers
I wonder what the intended use of this Etag, sent in response to a 
PUT-request, would be. As the entity, sent in a subsequent GET is not 
guaranteed to be equal to the body of the PUT-request, not a single 
client knows the entity. But clients get an entity-tag - for an unknown 
entity. What are they supposed to use it for?

Werner

---

From: Julian Reschke <[email-masked]>
Date: Fri, 04 Jan 2008 23:16:48 +0100

Werner Baumann wrote:
> Julian Reschke wrote:
>>
>> In particular:
>>
>> - E does not apply to Rq
>>
>> - the presence of E in Rs does not necessarily imply that the body 
>> sent with PUT was stored octet-by-octet
>>

They can still use it in all kinds of conditional operations. See 
<http://greenbytes.de/tech/webdav/draft-reschke-http-etag-on-write-08.html> 
for examples, and keep in mind that just because a resource supports PUT 
doesn't necessarily mean the server is a replacement for a file server 
-- the storage may be XML based, for instance.

BR, Julian

---

From: Henrik Nordstrom <[email-masked]>
Date: Sat, 05 Jan 2008 22:25:35 +0100

> entity. What are they supposed to use it for?

Thr client knows the entity is a direct derivate of the entity in the
PUT. The version of the server resource entity created by the PUT.

It maybe isn't octet equal with the request entity, but for as long as
the strong etag is the same it's the exact version (in octets) created
by the PUT request.

This ignoring any server-side implementation races when dealing with
multiple concurrent PUT requests for the same resource, those are just
server implementation bugs.

This use of ETag is entirely fine for PUT, but I wonder what to do in
case of PATCH... but I guess that octet based PATCH requests should only
be allowed to servers using an octet based store.. it simply gets too
hairy otherwise,

Regards
Henrik

---

From: Werner Baumann <[email-masked]>
Date: Sat, 05 Jan 2008 22:55:18 +0100

> -- the storage may be XML based, for instance.
I would replace "can" with "could". There is an important precondition:
Clients must know whether and how the server changes the body of the 
PUT-request. Without this knowledge the etag is useless.

http://greenbytes.de/tech/webdav/draft-reschke-http-etag-on-write-08.html 
suggests an additional Entity-Transform-header for this. But there are 
no standardized transformations to transport in this header. The only 
transformation it deals with, is the no-transformation.

Without means to communicate the exact kind of transformation between 
server and client, the only case, where etags on PUT can be useful 
without out-of-band-knowledge, is when the server does no 
transformation, i.e. the next GET will return a body that is 
byte-by-byte identical with the body of the PUT. For WebDAV-clients 
exactly this case is useful and important. And exactly this is 
impossible, if servers send an etag although they changed the content.

When a server changes the body submitted in the PUT-request, it MUST NOT 
send an Etag-header in response, unless it knows that the client is 
aware of this changes and can handle them.

In cases, where server and client know of each other, this is not a 
restriction. Taking examples A.3 and A.4 from 
http://greenbytes.de/tech/webdav/draft-reschke-http-etag-on-write-08.html 
where a server inserts non-standard WebDAV-properties into a document. 
Whether this single server sends an etag to a handful of specially 
crafted clients, is completely out of the scope of standardization.

If there will some day be means, how servers can inform clients about 
transformations, these can be designed to also transport the etag. But 
this hypothetical case must not block what is useful and possible now.

Werner

---

From: Henrik Nordstrom <[email-masked]>
Date: Sat, 05 Jan 2008 23:46:14 +0100

> aware of this changes and can handle them.

I don't agree here. Why do you see this as such big problem?

I am missing a usecase where this really causes a problem. All I see is
plenty of usecases there not sending the ETag would be a major problem.

The use of the ETag returned by PUT is to know that the resource has not
been changed after the PUT request completed. Not that there is
octet-equality between what the client sent and what got stored on the
server.

This ETag is useful for pretty much all operations except ranged
retreival (which is in itself useless here if the client already has the
object). And very useful for subsequent PUT/DELETE requests to avoid the
lost update problem.

The fact that the server issues some kind of transform of the PUT
content is generally not such big deal. Sure, it means the client would
not get the same representation if it issues a GET, but the
representation the client sent is still good enough and SHOULD result in
a at least semanticaly equivalent entity if the PUT is repeated.

It's not a problem for subsequent PUT requests from the same client. The
server SHOULD apply the same kind of transform on those, ending up in
the same result even if the client has not refetched the object before
the next update.

It's certainly not a problem for DELETE.

Regards
Henrik

---

From: Werner Baumann <[email-masked]>
Date: Sun, 06 Jan 2008 13:38:33 +0100

> plenty of usecases there not sending the ETag would be a major problem.
The use case:
A caching WebDAV-client, that has no special knowledge about the server, 
except that it complies to the standards.

The client uses PUT to store a file on server and holds its own copy in 
the cache. It gets a strong etag in response from the server and 
associates it with the cached file. The client now relies, that it can 
use the cached file as if it was retrieved from the server via GET, for 
any practical purpose, without causing confusion or damaging data integrity.

If the client can rely on this, the server SHOULD send the etag. This 
will be an enhancement over the current situation. If the client cannot 
rely on this, the server MUST NOT send an etag, because the client's use 
of the cached file might cause confusion and data loss.

Examples besides delete:
- may the client display the stored file to the user, or will the user 
be confused, when direct access to the server shows different content?

- may the client edit the cached file and then upload it with a 
conditional PUT, using that etag?

- strong validators allow range-requests, even for PUT. Will this work?

Take examples A.3, A.4 in 
<http://greenbytes.de/tech/webdav/draft-reschke-http-etag-on-write-08.html>, 
where a server inserts content. Will it work, when the client inserts 
the same content into the cached copy and then does a conditional PUT, 
or will this end up in inserting the same content twice? If it works, 
the etag is an improvement, if not it causes data corruption.

What I am missing in this statement from Julian
     sent with PUT was stored octet-by-octet
is the guarantee, that the cached body is equal to what the server 
stores for any practical use.

I am maintaining a caching WebDAV-file-system (davfs2), that presents 
WebDAV-resources to none-webdav-aware applications as a local file 
system. What would the responsible behaviour of davfs2 be, when it gets 
an etag in response to a PUT, but has no guarantee, that the cached body 
is identical to the server version for any practical use? Shall it 
present the cached body to the application and risk data corruption? It 
must throw away the cached body and use GET (unconditional) to get the 
real thing.

At the moment, davfs2 is not that responsible for the sake of 
efficiency. But I would be very glad to get a reliable strong etag in 
the PUT-response. An unreliable etag would make things worse.

Werner

---

From: Julian Reschke <[email-masked]>
Date: Sun, 06 Jan 2008 14:20:46 +0100

> any practical purpose, without causing confusion or damaging data 

Right now (IMHO), neither HTTP nor WebDAV give you that guarantee.

CalDAV adds a restriction that gives you that guarantee, while XCAP 
requires the opposite behavior. This is a problem when you want to use 
common libraries to access HTTP resources, or if a server wants to 
implement multiple HTTP extensions for the same URI.

That's the motivation for my proposal.

> of the cached file might cause confusion and data loss.

That rules out lots of interesting use cases (when the storage is not 
binary-based, such as in XCAP (XML), CalDAV (calendar store), AtomPub 
(can be based ony many mechanisms...), JCR...) .

> be confused, when direct access to the server shows different content?

Of course that's hard for the server to know. Will an out-of-date 
revision control info confuse the user? Will reformatting of XML confuse 
the user? Will resorting lines in an ICS file confuse the user?

> conditional PUT, using that etag?

That's not a problem, as long as the entity transformation done by the 
server falls into the category described in 
<http://greenbytes.de/tech/webdav/draft-reschke-http-etag-on-write-08.html#rfc.section.1.2.p.11> 
-- are there examples for other transformations you can think of.

> - strong validators allow range-requests, even for PUT. Will this work?

Unlikely if the content was rewritten. A server can protect itself from 
that by generating the strong etag in a manner that guarantees that a 
range request will fail.

> the etag is an improvement, if not it causes data corruption.

If the client has out-of-band knowledge how to do the transform locally, 
it would work. However it seems unwise to build a system like that, 
unless you have close coupling between client and server, such as in 
Subversion.

How would the absence of the ETag help here, btw?

> stores for any practical use.

The problem is to define what "any practical use" means. I'm totally 
with you that with RFC2616 has to offer here isn't sufficient for 
authoring resources on servers that *do* entity transforms. Thus the 
proposed extension.

> must throw away the cached body and use GET (unconditional) to get the 

Unless it has knowledge that the cached copy is indeed identical.

> the PUT-response. An unreliable etag would make things worse.

Right now you just don't know. There are HTTP servers out there that 
happily return a strong etag although the content was rewritten, and 
RFC2616 (IMHO) allows that.

BR, Julian

---

From: Werner Baumann <[email-masked]>
Date: Sun, 06 Jan 2008 17:20:34 +0100

Hello Julian,

all your examples rely either on an extension protocol or on some 
out-of-band agreement between server and client. But this is about pure 
HTTP, without extensions and additional agreements.

Extension protocols are free to make their own rules about when it is 
sensible to send an etag and what it can be used for.

My proposal
 > When a server changes the body submitted in the PUT-request, it
 > MUST NOT send an Etag-header in response, unless it knows that
 > the client is aware of this changes and can handle them.
is meant to allow for just this freedom, but to prevent servers without 
this additional knowledge from sending useless etags, what would render 
all etags in PUT-responses useless for many clients. Of course there may 
be a better wording.

The only use case, where a client can make use of the etag without 
further knowledge and guarantee is DELETE. It suffices to know, that the 
resource has not been modified by someone else in between. In all other 
use cases, the client must know, whether there are manipulations by the 
server that might conflict with what the client wants to do.

When server and client share additional information and agreements, they 
are free to do anything and may even ignore the specifications, as long 
as they do not communicate with the world outside.

Werner

---

From: Julian Reschke <[email-masked]>
Date: Sun, 06 Jan 2008 17:33:56 +0100

> HTTP, without extensions and additional agreements.

I'm not sure I understand; maybe you could be more specific. The 
examples I'm giving are all allowed by what RFC2616 says.

> sensible to send an etag and what it can be used for.

Yes, but when they start making conflicting requirements (and they do), 
writing generic clients/libraries/middleware/intermediates becomes 
problematic.

> all etags in PUT-responses useless for many clients. Of course there may 

My understanding is that your proposal changes the semantics of RFC2616, 
  breaks existing servers, and rules out lots of applications what work 
fine today.

> server that might conflict with what the client wants to do.

That is incorrect (really!). There are many examples where servers do 
not store the content octet-by-octet, but strong ETags just work fine.

You seem to argue from the POV of a WebDAV client implementor. There's 
nothing wrong with that, but filesystem-semantics-over-HTTP is just one 
out of many use cases.

Best regards, Julian

---

From: Werner Baumann <[email-masked]>
Date: Sun, 06 Jan 2008 20:55:15 +0100

>  breaks existing servers, and rules out lots of applications what work 
Your examples:
XCAP, CalDAV and AtomPub. They are protocols, defined in an RFC. These 
protocols (hopefully) clear the matter of rewriting by the server. When 
a client and a server use one of these protocols, this is clearly caught 
by "unless it knows that the client is aware of this changes and can 
handle them". There is no conflict and nothing is ruled out.

I don't know about JCR, JCS and ICS. Please give me the full names.

Example A.1 and A.2 of draft-reschke-http-etag-on-write-08 is about 
version control. There are protocols for this. See above.

Example A.3, A.4 is an example that will not work without additional 
knowledge. It is some kind of server-side-include and not very 
realistic. Authors of a website will want to use WebDAV to edit the 
*sources* and not the output from server-side processing of this sources 
(which is intended for normal, none-WebDAV-access with GET).

Other examples? Clients that just know about RFC 4918 and that use 
simple WebDAV-servers like Apache/mod_dav/mod_dav_fs or IIS for 
distributed authoring. They will never be able to make use of etags in 
PUT-responses, when it is defined according to your proposal.

Werner

---

From: Julian Reschke <[email-masked]>
Date: Sun, 06 Jan 2008 22:02:40 +0100

Werner Baumann wrote:
> 
> Julian Reschke wrote:
>> My understanding is that your proposal changes the semantics of 
>> RFC2616,  breaks existing servers, and rules out lots of applications 
>> what work fine today.
>>
> Your examples:

Some do. But how, in general, does this help a client that doesn't have 
out-of-band knowledge what the resource is?

A CalDAV resource is a WebDAV resource, however it's likely to rewrite 
the content upon PUT. But then, maybe the implementors did the 
additional work to preserve the binary you sent in PUT. You just don't 
know, and RFC2616 doesn't give you any information *on the wire* to find 
out. So if you *need* to know, you'll have to do the additional GET.

> handle them". There is no conflict and nothing is ruled out.

So what do you do in a library that doesn't know the specifics of these 
protocols? Or in a server that attempts to support multiple protocols in 
the same URL space?

> I don't know about JCR, JCS and ICS. Please give me the full names.

JCR - Java Content Repository - an hierarchical store that's likely to 
expose content rewriting when accessed over HTTP.

JCS - no idea. Did I say that?

ICS is the file format you'll usually manipulate over CalDAV.

> version control. There are protocols for this. See above.

I'm not sure how the fact that there are protocols for that invalidates 
the point. As a matter of fact, the only sort-of-standard for that I'm 
aware of would be RFC3253, and a versioning server supporting keyword 
expansion and RFC3253 would expose exactly that behavior.

> (which is intended for normal, none-WebDAV-access with GET).

Well, it has been implemented, so I'm not sure how you can say it's not 
"realistic". And it has nothing to do whatsoever with 
server-side-includes, but with automatic extraction of meta data from 
content, and automatic insertion of meta data into content.

> PUT-responses, when it is defined according to your proposal.

You are still focused on HTTP-as-a-filesystem-replacement. That's really 
only one use case.

And, btw, the proposal I'm making in my internet draft tries to 
*address* the issue. It would give clients the information that's 
currently not on the wire.

BR, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 7 Jan 2008 09:35:54 +1100

Upon what basis does the client cache the representation it sent, if  
it's just working within the standards? I.e., how does it derive a  
freshness lifetime?

At best, it seems to me that it could cache what it sent as stale, but  
it'd need to validate the ETag it was given before serving it as fresh.

I suppose it could compute a synthetic Last-Modified and base  
heuristic freshness from that, but most sane heuristics I've seen  
treat something that was just modified as fairly suspect of being  
changed again.

Of course, it could be operating as an offline cache, in which case it  
wouldn't need to validate, but in doing so it'd have to be willing to  
take some variation from what the server might actually send back to a  
new GET (sending Warning, etc.) -- which falls nicely within this  
scenario.

On 06/01/2008, at 11:38 PM, Werner Baumann wrote:

> The use case:
> A caching WebDAV-client, that has no special knowledge about the  
> server, except that it complies to the standards.
>
> The client uses PUT to store a file on server and holds its own copy  
> in the cache. It gets a strong etag in response from the server and  
> associates it with the cached file. The client now relies, that it  
> can use the cached file as if it was retrieved from the server via  
> GET, for any practical purpose, without causing confusion or  
> damaging data integrity

---

From: Henrik Nordström <[email-masked]>
Date: Mon, 07 Jan 2008 00:17:02 +0100

> that by generating the strong etag in a manner that guarantees that a 

Which is pretty much the same as disabling Range request on the resource
entirely, as returning a different strong ETag on a GET request without
any modifications to the resource would be even more confusing and
damaging.

To be honest this sounds quite much like a actual use-case for weak
etags returned by the PUT and upgraded to strong ETag on GET, if it
wasn't for that odd restriction that weak etags isn't allowed in
If-Match (required to chain PUT/DELETE/... request).

I still maintain that the use of weak ETags should be extended to allow
them in If-Match. The two representations is meant to be equal for all
meaningful purposes, and I don't see why If-Match need to act
differently than If-None-Match. Why would replacing, updating
(properties) or removing a equivalent but possibly not octet equal
resource be handled differently than retreival of the same?

Sorry for coming back to this for some touchy subject of weak etags..
but I do consider them more useful than harmful, if it wasn't for that
If-Match restriction...

Regards
Henrik

---

From: Henrik Nordström <[email-masked]>
Date: Mon, 07 Jan 2008 00:29:31 +0100

> server that might conflict with what the client wants to do.

PUT is also in this category, same as DELETE. The transform applied by
the server on the stored resource MUST be repeatable and not dependent
on seeing that transform in future PUTs to the same resource.

This comes from partially the fact that PUT is a non-indempotent
request, just as GET/DELETE. There must be no harm done on the server by
repeating the same PUT.

Regards
Henrik

---

From: Henrik Nordström <[email-masked]>
Date: Mon, 07 Jan 2008 00:35:35 +0100

> it'd need to validate the ETag it was given before serving it as fresh.

Yes, and such validation would say "Not modified, and fresh for X amount
of time". Even if the resource representation on the server differs from
what the client sent in the PUT.

Freshness is a different question really.

Regards
Henrik

---

From: Julian Reschke <[email-masked]>
Date: Mon, 07 Jan 2008 07:56:33 +0100

> any modifications to the resource would be even more confusing and

Would it? How?

> If-Match (required to chain PUT/DELETE/... request).

Note they are allowed in "If" headers (RFC4918).

> resource be handled differently than retreival of the same?

Agreed.

> but I do consider them more useful than harmful, if it wasn't for that

Yes. We need to resolve all these issues (weak vs if-none-match, the 
matching function, the "requested variant", Etag...) in a coherent way.

BR, Julian

---

From: Henrik Nordstrom <[email-masked]>
Date: Mon, 07 Jan 2008 14:12:49 +0100

> > any modifications to the resource would be even more confusing and

Well, perhaps not damaging, but at least confusing.

For one thing intermediary caches will get confused on If-None-Match
requests, and either return a the transformed representation to the
client even if it hasn't really changed from what the client PUT, or
flush it's own cache if the request gets forwarded as the 304 response
indicates the object has changed compared to the cached representation
held in the intermediary cache.

It's no problem for chained authoring requests using PUT/DELETE/etc
however, only conditional If-None-Match cache validation GET requests.

> Note they are allowed in "If" headers (RFC4918).

True, but If is not in HTTP/1.1, and is more tailored for WebDAV than
general HTTP.

> matching function, the "requested variant", Etag...) in a coherent way.

The "requested variant" is pretty clear. The variant returned had the
request been a GET request, or in case of the ETag returned by PUT a GET
request immediately after completion of the PUT.

And no, this do not fit entirely with WebDAV properties, but I am sorry,
that's a WebDAV fault, not HTTP.

It's also clear that PUT, DELETE etc is not designed to work with
negotiated resources, and is meant to be used on the individual resource
location (i.e. Content-Location of a negotiated resource). However, due
to security concerns Content-Location can never be considered to be a
substitute for the Request-URI except in cache invalidations even if
clients MAY use the Content-Location URI in future references to the
same variant or variant version depending on the server implementation.

But it's not obvious how to get this down in the correct wording..

It's also not clear how to handle ETag then a client makes a transition
from Request-URI to Content-Location URI for the purpose of authoring a
negotiated resource or similar.

Rgards
Henrik

---

From: Jamie Lokier <[email-masked]>
Date: Mon, 7 Jan 2008 11:57:34 +0000

> handle them". There is no conflict and nothing is ruled out.

The problem is middleware, such as generic HTTP protocol libraries,
generic HTTP caching libraries, and HTTP proxies: these can handle
Etags and conditional requests themselves, but such middleware doesn't
know about the different types of server.  That's why it's called
generic.

-- Jamie

---

From: Jamie Lokier <[email-masked]>
Date: Mon, 7 Jan 2008 12:05:43 +0000

> request, just as GET/DELETE. There must be no harm done on the server by

I think you meant "PUT is idempotent, just as GET/DELETE".

Idempotence doesn't imply the byte transformation is repeated exactly.

For example, it's perfectly reasonable for the server to replace each
occurence of "$PUT-Date$" in the entity with the actual date when it
received the entity.  That needn't be byte identical between requests,
but also it doesn't cause any harm if the PUT is repeated.

It's not even detectable by the client which repeated the PUT request,
assuming it didn't do any other operations in between.  (And RFC2616
notes that idempotence isn't expected when an operation is repeated
with others in between).

-- Jamie

---

From: Julian Reschke <[email-masked]>
Date: Mon, 07 Jan 2008 14:24:44 +0100

> True, but If is not in HTTP/1.1, and is more tailored for WebDAV than

Understood; I just keep mentioning it because it's good enough for 
WebDAV clients (such as Werner's).

> that's a WebDAV fault, not HTTP.

I'm totally happy with that clarification, but I think Roy was arguing 
differently.

> location (i.e. Content-Location of a negotiated resource). However, due

Agreed. A server that supports authoring negotiated resources better 
supply URIs of non-negotiated resources through Content-Location.

> negotiated resource or similar.

Good point. That would require a new HTTP feature, right?

BR, Julian

---

From: Henrik Nordstrom <[email-masked]>
Date: Mon, 07 Jan 2008 14:56:37 +0100

> I think you meant "PUT is idempotent, just as GET/DELETE".

Yes, I did. The word is a bit alien to me and I frequently get it
wrong..

> Idempotence doesn't imply the byte transformation is repeated exactly.

No, but predictably and not dependent on itself which was the point I
was trying to make.

Regards
Henrik

---

From: Henrik Nordstrom <[email-masked]>
Date: Mon, 07 Jan 2008 15:13:50 +0100

> Good point. That would require a new HTTP feature, right?

Not sure. I don't think so. Just clarification I guess.

The natural thing for most implementers I guess is to assume equalivence
between the two locations (Request-URI and Content-Location) when moving
from Request-URI to a direct Content-Location reference, but the correct
thing here is to discard any response received from the negotiated
Request-URI when moving to the direct Content-Location URI, and only at
most use ETag as a "weak" comparision locally in the client to verify
that the new response makes sense without using it in any HTTP
conditions.

But yes, there may be a need for a HTTP extension defining reliable URI
namespaces, but that's probably outside our charter and more a topic for
possibly the next generation WebDAV trying to do things more inline with
HTTP.. 

  - How to express negotiated resources better
  - How to express when a resource exists at multiple URIs
  - Derived/related resources such as properties of the resource
  - And to fit all this into both addressability and cache
invalidations..

Regards
Henrik

---

From: Werner Baumann <[email-masked]>
Date: Tue, 08 Jan 2008 22:01:57 +0100

> You are still focused on HTTP-as-a-filesystem-replacement. That's really 
Didn't know that distributed authoring is the same as 
"HTTP-as-a-filesystem-replacement". Besides, my opinion on that matter 
is well documented in the davfs2-README-file. You might have looked at 
e.g. 
http://dav.cvs.sourceforge.net/dav/davfs2/README?revision=1.27&view=markup 
before inventing my opinion by your own.
As I understand, making up of offending nonsense like "You are still 
focused on HTTP-as-a-filesystem-replacement." is meant to terminate 
communication. Agreed.

Werner