DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10539>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10539 Active lock discovery returns invalid lock tokens ("dummytoken") [EMAIL PROTECTED] changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|WONTFIX | ------- Additional Comments From [EMAIL PROTECTED] 2003-10-22 11:44 ------- First of all, even if there is a legitimate reason not to reveal the lock token (which?) upon PROPFIND, there are some more considerations. 1) "opaquelocktoken:dummytoken" does not conform the opaquelocktoken URI syntax defined by RFC2518. So if the server doesn't want to reveal the token but chooses to include one in DAV:lockdiscovery, it should generate a legal one (it just needs to be a URI that will never work for UNLOCK). 2) There's also the option not to return the locktoken in DAV:lockdiscovery. See: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2003JulSep/0185.html> --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
