Subject: [Bug 143] LOCK_RENEWAL_SHOULD_NOT_USE_IF_HEADER

From: [email-masked]
Date: Tue, 14 Feb 2006 07:17:15 -0800

http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=143

[email-masked] changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|FIXED                       |
            Version|-10                         |-13

------- Additional Comments From [email-masked]  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.