- From: Jason Crawford <ccjason@us.ibm.com>
- Date: Wed, 27 Jun 2001 12:39:03 -0400
- To: "Stefan Eissing" <stefan.eissing@greenbytes.de>
- Cc: "WebDAV WG" <w3c-dist-auth@w3.org>
> Well, thanks for the warning. Which server(s) would that be? I don't know if there are any now. Perhaps someone will speak up. I doubt a server would be configured this way by default, but I wouldn't be surprised if some were to be configurable in this regard so as to leave it up the administrator to deal with situations local to his sites if the need develops. The spec left this option open intentionally for the reasons described in section 7.6. << And will they prevent a client application/operating system/network connection from crashing or will they have another method to discover locks and unlock resources? >> Of course not. The thinking was that problems of the ilk you described could be addressed in several ways: 1) the locks can time out 2) the server administrator can break a lock 3) a client can store it's lock tokens persistantly in what they deem to be an adequately secure fashion. The the most compeling case against it was the case of clients who store their tokens locally and whose users switch between machines (home vs work) often and know their applications won't interact in bad ways. ("Drat! I left my token on my office machine! I really want to put my updated file back on the server! Grumble.") There are of course ways around this, but it's doubtful that these approaches would be used. I believe that's pretty much the history and it answers your question. My thinking is that section 7.6 might be a red herring and this last case certainly can be common. But we did leave the final decision up to the server developer and administrator. I personally feel the behavior you expect should be the default. But I also believe that administrator should be able to configure this if they discover there is a need to hide the tokens. I also believe that clients should not be written to be dependent on the visibility of the token. So what are clients to do? In your case, you could probably use an IF header in a quick benign operation to determine if the lock is still there before you do the expensive operation. In JimW's case, he just needs to make sure his client doesn't do anything if the lock-discovery doesn't reveal the token. And generically client apps should request appropriate lock timeout periods and keep a persistant vault of their tokens if they feel they or their OS are prone to crashing. BTW... this topic is a tangent and not the reason I asked my original question. :-) J.
Received on Wednesday, 27 June 2001 13:54:12 UTC