On 10/07/2011 12:51 PM, Fabián Mandelbaum wrote: > Bonjour Hussein, > > as usual, thanks a lot for your prompt and complete answer. Here's > mine, between lines: > > 2011/10/7 Hussein Shafie<[email protected]>: >> On 10/07/2011 12:58 AM, Fabián Mandelbaum wrote: >>> >>> >>> Other DAV clients work OK (tested with cadaver under Linux, and with >>> Windows XP's "web folders"). Any ideas? >>> >> >> --> Despite the fact that it works with Cadaver and Windows Web Folders, the >> WebDAV server you use is not conforming to this very basic point of the >> specification: >> >> http://www.webdav.org/specs/rfc2518.html#METHOD_PROPFIND >> --- >> 8.1 PROPFIND >> >> The PROPFIND method retrieves properties defined on the resource identified >> by the Request-URI, if the resource does not have any internal members, or >> on the resource identified by the Request-URI and potentially its member >> resources, if the resource is a collection that has internal member URIs. >> --- >> >> In a nutshell, the list returned by your WebDAV server is missing the item >> concerning the Collection which is the subject of the PROPFIND request >> ("http://localhost:9000/workspaces/W1/classifications/"; in the above >> example). >> >> We strongly urge you to report this bug to the developers of your WebDAV >> server. (By the way, which is this WebDAV server?) >> > > The WebDAV server is an own implementation "on top" of the rest of our > system. I'm the developer myself, and I may have ommited more > conformance stuff than 'just' this one. I'll fix this ASAP, thank you > for pointing me to the relevant part of the spec. > >> --> It worked with XXE v4.9.1 because the old WebDAV virtual drive plug-in >> had a *workaround* for this bug. We have rewritten the WebDAV virtual drive >> plug-in in order to better support the new "Open Folder" feature found in >> XXE v5. We have omitted to port the workaround, thinking that after all >> these years, WebDAV servers could not possibly have such trivial bug. We >> were wrong. >> > > It's not your fault that we developers don't understand the specs > properly, or don't read 'em as thoroughly as we should have... > (sometimes ;-)) > >> We'll port the workaround today[*] and point you to the new WebDAV virtual >> drive plug-in (v2.1.5). Because we have no way to test this workaround, >> please be kind enough to confirm that it actually solves your problem. After >> you do that, we'll officially publish the new plug-in on our Web sites, >> making it available to all users. >> > > Hum... considering the point you describe in your [*] call above, I > don't think it's a good idea... unless my DAV server is not the only > one having this problem. I'll let you know when I work on the fix on > MY side, which is the right thing to do. > >> Thank you in advance. >> > > Thank you. > >> --- >> [*] This is probably wrong as this encourages the developers of WebDAV >> servers not to fix their bugs. >> > > I cannot but agree with you, and that's why I think you should not > port the workaround to the new DAV vdrive plugin, please let me fix my > mistake, and keep your DAV vdrive plugin without the workaround > (again, unless there's more than my DAV implementation with this > issue). > > Will return to you as soon as I fix my DAV implementation and check it > works OK with both 4.9.1 and 5.0.0. > > Merci beaucoup ! >
I'm really glad you have adopted this approach. Thank you for that. -- XMLmind XML Editor Support List [email protected] http://www.xmlmind.com/mailman/listinfo/xmleditor-support
