Having an odd problem with dreamweaver on what is currently building as rc1; been having it for about two versions now. We mount dav up as http://<server>/app/dav; dav is correctly configured for every other client that I can use to lock/unlock with. For some reason, Dreamweaver doesn't seem to recognize its own lock; on retrieval, it unlocks the file and grabs it, but doesn't seem to recognize the lock token, nor does it pass that lock token back on put. Hence, I'm unable to actually modify and upload content via dreamweaver when dreamweaver is set to use locking. Is Dreamweaver one of the tested apps for slide? Do people expect that it should work, or is there a known problem I haven't been able to find reference to anywhere?
Just guessing, but if locks are involved maybe it is the same as with OS X as described in http://jakarta.apache.org/slide/faq.html As it is rather unlikely that any one of the Slide developers have access to Dreamweaver you would have to supply a HTTP trace of what DreamWeaver sends to find out what goes wrong.
Yes, I thought that too. No, the problem doesn't seem to be that. I went through those trace logs earlier; I didn't see anything wrong with the request, nor the response. I had the *gut feeling* that the problem was the cdata in the lock; the other server I tested against (Apple's .mac DAV implementation) didn't use a cdata section, but just returned the contents, and locking/unlocking seemed to work without a hitch. So, best guess, it's that. When I get into the office tomorrow, I'll generate some traces and see where it leads me.
(clarification) Up until the put/unlock stage, everything DW did against Slide was the same as it did against .mac; but upon being provided the lock information, DW "understood" the lock. On Slide, DW seems to not recognize the lock; in fact, when hovering over the locked file, it reports (in a status bar) that it's checked out by "Unknown Owner"... None of which makes any sense, because the responses to the lock request were identical save one thing: The username in the lock, "gblock@ctoforaday.com", was in a cdata section.
Created attachment 13591 [details] A trace of Dreamweaver's behavior during an unlock attempt.
Created attachment 13592 [details] A trace of dreamweaver's behavior during locking a file. These two files cover Dreamweaver's behavior during lock/unlock. Note that it closes the connection each time; in addition, each request is listed in the files once for each time it appeared over the network; I didn't accidentally duplicate the same packets twice. :) It's odd. Can't put my finger on what's going wrong, but I'm going to guess it's the lock contents. Also note that I've tried this with the principal URL stuff both on and off, and it makes no difference; whatever's going on here is more unusual than that.
Hmmm, judging from the trace principal-URL still is transmitted. Please switch that off, try again and send the new trace.
Created attachment 13622 [details] Dreamweaver lock, again, this time without PrincipalURL.
Created attachment 13623 [details] Dreamweaver unlock, again, this time without Principal URL. There's no actual change; as I said before, PrincipalURL seems to have no effect on Dreamweaver (it fails regardless). I *think* it's the cdata in the owner. Gut feeling.
Gut feeling is dead right on this, I've just manually recreated this in Apple's iDisk. - Dreamweaver requires that lock/unlock operations can only be performed if the user specifies, in his DAV connection options, an e-mail address. - Dreamweaver sends that address during lock. - When showing the contents of the locks, Dreamweaver will show the visible contents of that lock only if it can be parsed; Dreamweaver is unable to see the cdata content, and is reporting an unknown lock owner. - If you lock something in iDisk, and then disconnect and change your e-mail address, it behaves in an identical way - it thinks it isn't the lock owner, and doesn't attempt to do anything at all. I'm 99.9% convinced here that Dreamweaver is expecting the contents of the owner tag to *exactly* match the e-mail address configured in the user's connection options; when that differs in any way, Dreamweaver refuses the unlock operation.
Hey, even the new patches seem to contain principal url tags. How come?
Created attachment 13624 [details] Whoops. Dreamweaver unlock. The right file this time. :) No principal url. Oops. Too many files on the desktop. :)
Just hacked up the PropertyHelper; no change when it's not in cdata. Could really use some advice on where the difference might be. :)
There is another difference, the lock discovery contains xmlns:D="DAV:" in <D:href xmlns:D="DAV:">gblock@ctoforaday.com</D:href> which is not present in the lock request.
Which, however, is introduced while parsing the request and thus is very hard to remove :( (In reply to comment #13) > There is another difference, the lock discovery contains > > xmlns:D="DAV:" > > in > > <D:href xmlns:D="DAV:">gblock@ctoforaday.com</D:href> > > which is not present in the lock request.
To see if the non-verbose reproduction really is your problem I would recommend to have something like owner.addContent("<href>gblock@ctoforaday.com</href>"); // try { // Document d = // new SAXBuilder().build( new StringReader(objectLockToken.getOwnerInfo()) ); // owner.addContent(d.getRootElement()); // } // catch( Throwable e ) { // owner.addContent(new CDATA(objectLockToken.getOwnerInfo())); // } in PropertyHelper. If this works, then it really is the non-verbose thing. Gregory, would you please try?
Ok, now it's changed (just saw your patch go by)... <?xml version="1.0" encoding="UTF-8"?> <D:multistatus xmlns:D="DAV:"> <D:response xmlns:D="DAV:"> <D:href>/sisp/dav/clients/wow/services/static/dnsfaq.html</D:href> <D:propstat> <D:prop> <D:lockdiscovery> <D:activelock> <D:locktype> <D:write /> </D:locktype> <D:lockscope> <D:exclusive /> </D:lockscope> <D:depth>0</D:depth> <D:owner> <D:href>/sisp/davgblock%40mac.com</D:href> </D:owner> <D:timeout>Infinite</D:timeout> <D:locktoken> <D:href>opaquelocktoken:a478c68d5d8248512b0fe6d086fac924</D:href> </D:locktoken> </D:activelock> </D:lockdiscovery> </D:prop> <D:status>HTTP/1.1 200 OK</D:status> </D:propstat> </D:response> </D:multistatus> Still no match, and that's well wrong. :)
Well, I suppose the owner now literally is what you sent as owner right? But wait, what about the whitespaces? .... (In reply to comment #16) > Ok, now it's changed (just saw your patch go by)... > > <?xml version="1.0" encoding="UTF-8"?> > <D:multistatus xmlns:D="DAV:"> > <D:response xmlns:D="DAV:"> > <D:href>/sisp/dav/clients/wow/services/static/dnsfaq.html</D:href> > <D:propstat> > <D:prop> > <D:lockdiscovery> > <D:activelock> > <D:locktype> > <D:write /> > </D:locktype> > <D:lockscope> > <D:exclusive /> > </D:lockscope> > <D:depth>0</D:depth> > <D:owner> > <D:href>/sisp/davgblock%40mac.com</D:href> > </D:owner> > <D:timeout>Infinite</D:timeout> > <D:locktoken> > <D:href>opaquelocktoken:a478c68d5d8248512b0fe6d086fac924</D:href> > </D:locktoken> > </D:activelock> > </D:lockdiscovery> > </D:prop> > <D:status>HTTP/1.1 200 OK</D:status> > </D:propstat> > </D:response> > </D:multistatus> > > > Still no match, and that's well wrong. :)
To check that, set the format of the XMLOutputter in the propfind method to raw. In CVS HEAD this is in line 298 org.jdom.output.Format format = org.jdom.output.Format.getRawFormat(); instead of org.jdom.output.Format format = org.jdom.output.Format.getPrettyFormat(); (In reply to comment #17) > Well, I suppose the owner now literally is what you sent as owner right? But > wait, what about the whitespaces? > > ....
No, I think now that /sisp/dav thing getting appended is buggering everything up. I'm not quite sure where it's coming from - I think I've hacked up something in my codebase and not cleared it away. It looks positive, though.
Ok, "/sisp/dav" is the root context; I'm going to take a punt and guess that something is calling the bit that makes URIs "path local" on the contents of owner, somehow - because I've just done a clean build, and I'm still seeing it. It's even happening to DAV Explorer, now.
Looks like the <href></href> content in the owner is getting auto-rewritten to append the path to it. Anyone know where that's being done? :)
Slide CVS head is ok. Most likely the owner has been set to /sisp/dav/... and this is just being returned no matter what client you use. (In reply to comment #20) > Ok, "/sisp/dav" is the root context; I'm going to take a punt and guess that something is calling the bit > that makes URIs "path local" on the contents of owner, somehow - because I've just done a clean build, > and I'm still seeing it. > > It's even happening to DAV Explorer, now.
No, I don't think so. The problem that I'm seeing is that I can *manually* put absolutely anything into <owner/>, and it will be automatically transformed by convertHrefValueToAbsoluteURL - even though, quite frankly, the contents of <owner/> should be touched. This is happening because Slide believes it's not the root servlet; however, this is the one instance in which it isn't correct to perform that translation/replacement. But that method thinks that all content inside an <href/> is fair game. Definitely broken.
(of course, this worked before because it was inside a cdata section, thereby protecting it from that method, which walks the dom.)
Index: PropertyRetrieverImpl.java =============================================================== ==== RCS file: /home/cvspublic/jakarta-slide/src/webdav/server/org/apache/slide/webdav/util/ PropertyRetrieverImpl.java,v retrieving revision 1.39 diff -r1.39 PropertyRetrieverImpl.java 641c641,642 < convertHrefValueToAbsoluteURL(child, servletContextPath, config); --- > if (!(element.getName().equals("activelock") && child.getName().equals("owner"))) > convertHrefValueToAbsoluteURL(child, servletContextPath, config);
Yup. That patch fixes it for me. I don't know whether it's *correct* behavior - I assume that the contents of the owner *should* be identical to what was provided, and therefore the patch is correct; but it does belie an underlying possible problem with the assumption that all <href> need to be translated when processing... Where else will this happen? Anyways, please review and apply patch, and then you can call yourselves Dreamweaver-happy on ship. :) (And someone send a nastygram to those idiots at Macromedia while we're at it. :)
(In reply to comment #26) > Anyways, please review and apply patch, and then you can call yourselves Dreamweaver-happy on ship. > :) Applied to both Slide CVS HEAD and release branch. So we *all* can call ourselves Dreamweaver-happy as you obviously are part of the community as well. > (And someone send a nastygram to those idiots at Macromedia while we're at it. :) Hmmm, part of the problem was Slide. Anyway, great that you have fixed that :)