- From: <bugzilla@soe.ucsc.edu>
- Date: Tue, 14 Feb 2006 07:17:15 -0800
- To: w3c-dist-auth@w3.org
http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=143
julian.reschke@greenbytes.de changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
Resolution|FIXED |
Version|-10 |-13
------- Additional Comments From julian.reschke@greenbytes.de 2006-02-14 07:17 -------
I know it's late to revisit this issue, but I'm pretty sure it's gonna be raised
in Last Call...
It's undisputed that RFC2518's concept of lock refresh is a mess. We have thrown
away implicit lock refreshs (not used by clients, potentially expensive). This
is good.
This issue is about whether explicit lock refresh requests should use the
Lock-Token request header instead of the If header. I think everybody agrees
that it would have been better to use Lock-Token in the first place, because
- using the If header for refresh adds yet another thing to something that is
already too complex
- using the If header also means it's hard to specify what a server is supposed
to do if the If header as multiple lock tokens, or lock tokens in tagged lists
referring to other resources
On the other hand:
- none of the servers I regularily test with (SAP KM, Xythos, Apache/moddav,
IIS) support the LOCK refresh with Lock-Token header as of today
- RFC2518bis thus "encourages" servers to support the old behaviour
(<http://greenbytes.de/tech/webdav/draft-ietf-webdav-rfc2518bis-12.html#rfc.section.9.10.2>)
- Clients as of today send the LOCK refresh with the If header
With the current wording, new servers (class 3) are not required to honor the If
header for LOCK refresh, thus clients would need to be updated to either send
both headers (hoping this doesn't break old servers), or to check the server
version first. None of these options is really pleasant.
Summary: it seems that this change trades a bit of consistency with lots of
potential interop problems. Thus, it may be wiser to back it out, and to clarify
the old behaviour instead.
(note: I came across this issue when working on class 3 conformance for our
server, so this isn't a purely theoretical argument)
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.
Received on Tuesday, 14 February 2006 15:17:23 UTC