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=21284>.
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=21284

WebDAV dummy lock token not good for MacOS X and Dreamweaver 6

           Summary: WebDAV dummy lock token not good for MacOS X and
                    Dreamweaver 6
           Product: Tomcat 4
           Version: 4.1.24
          Platform: Other
        OS/Version: Other
            Status: NEW
          Severity: Normal
          Priority: Other
         Component: Servlets:WebDAV
        AssignedTo: [EMAIL PROTECTED]
        ReportedBy: [EMAIL PROTECTED]


Both Mac OS X and Dreamweaver 6 are treating the lock tokens sent out by the
WebDAV servlet in a way the servlet doesn't expect.

When uploading a file:

Client says (C), Server responds (S).

C: LOCK /afile.txt
S: HTTP/1.1 200
and in the dav XML response we can find something along the lines of:
<locktoken><href>opaquelocktoken:a6cc8b92be7dd19949adb401164c4312</href></locktoken>

Both Mac OS X and Dreamweaver are being defensive and do a:
C: PROPFIND /afile.txt
S: HTTP/1.1 207
and the server now responds:
<locktoken><href>opaquelocktoken:dummytoken</href></locktoken>

Both Mac OS X now choses the dumytoken in preference to the previous one and
consequently fails to manipulate the file further.

There is a quick fix, which is to always present the real token and never the
dummy one. There is even boolean arguments in place to do so:

$ diff -u WebdavServlet.java-2003-07-01 WebdavServlet.java
--- WebdavServlet.java-2003-07-01       2003-07-01 11:37:34.000000000 +0100
+++ WebdavServlet.java  2003-07-02 15:10:30.000000000 +0100
@@ -2667,7 +2715,7 @@
          * append an XML fragment to the given XML writer.
          */
         public void toXML(XMLWriter generatedXML) {
-            toXML(generatedXML, false);
+            toXML(generatedXML, true);
         }
   
----------------

I don't know what impact this has on any security considerations etc. I assume
the dummytoken is there so that only the locking client has the real one.

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to