Lisa Dusseault schrieb:
My assertion was that if a strong ETag is returned, Xythos WFC assumes
that what it PUT was what the server stored, and it seems you agree.
You found that if a Last-Modified is returned instead, WFC makes the
same assumption -- naturally, they're very similar.
It seems that the client always assumes that the server does no
content-rewriting, no matter what it returns. So it's incorrect to
assume it makes specific assumptions about ETags on PUTs. It doesn't.
You're probably quite right about the general case, that existing WebDAV
clients don't handle content-rewriting servers at all. What's the best
Several clients handle it well, because they don't have a local content
cache. Examples are Microsoft Office, Microsoft Webfolder, and the SAP
Netweaver KM.
thing a content-rewriting server can do in this situation? I would hope
that if a client receives neither an ETag nor a Last-Modified in a PUT
response, then the next time it synchronizes and sees an ETag that it's
never seen before, the client downloads the resource. This allows the
content to eventually get synchronized although perhaps not as fast as
would be ideal.
As there's no guarantee in HTTP about content rewriting not occurring,
clients should always re-sync (at some point of time). An optimization
(which happens to be the one I've been proposing several times now)
would be a way for the server to indicate that content was *not*
rewritten, avoiding the additional retrieval.
But CalDAV clients will have to handle content-rewriting servers at
least handling events (calendar component resources), because during
protocol development we heard from a couple server developers that
they'd need to add custom iCalendar properties to an event as soon as it
was stored, thus rewriting the content.
Yes. I'm not sure how this is different from the generic case, though.
Best regards, Julian
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf