I’m giving up on trying to get my Oddmuse:WebDAV Extension to work with OSX. See Oddmuse and WebDAV.
I have tried both OSX Finder and TextEdit, but they both fail. The first workarround involved sending the DAV 2 header in replies to OPTIONS, because a DAV 1 header would get interpreted as a read-only collection. Next I noticed that I would have to fiddle with the PROPFIND replies. When saving from TextEdit, for example:
PROPFIND /dav/
depth: infinity
<?xml version="1.0" encoding="utf-8" ?>
<D:propfind xmlns:D="DAV:">
<D:prop>
<D:getlastmodified/>
<D:getcontentlength/>
<D:resourcetype/>
</D:prop>
</D:propfind>
RESPONSE: 207
<?xml version="1.0" encoding="utf-8"?>
<D:multistatus xmlns:D="DAV:">
<D:response>
<D:href>http://localhost:80/cgi-bin/wiki/dav/</D:href>
<D:propstat>
<D:prop>
<D:getlastmodified>Thu, 01 Jan 1970 00:00:00 GMT</D:getlastmodified>
<D:getcontentlength/>
<D:resourcetype>
<D:collection/>
</D:resourcetype>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
</D:response>
</D:multistatus>
The wiki is empty, and I’m faking getlastmodified. We’re returning one response for the collection. This is correct.
---
PROPFIND /dav/
depth: 1
<?xml version="1.0" encoding="utf-8" ?>
<D:propfind xmlns:D="DAV:">
<D:prop xmlns:A="http://www.apple.com/webdav_fs/props/">
<D:getlastmodified/>
<D:getcontentlength/>
<D:resourcetype/>
<A:appledoubleheader/>
</D:prop>
</D:propfind>
RESPONSE: 207
<?xml version="1.0" encoding="utf-8"?>
<D:multistatus xmlns:D="DAV:">
<D:response xmlns:i0="http://www.apple.com/webdav_fs/props/">
<D:href>http://localhost:80/cgi-bin/wiki/dav/</D:href>
<D:propstat>
<D:prop>
<D:getlastmodified>Thu, 01 Jan 1970 00:00:00 GMT</D:getlastmodified>
<D:getcontentlength/>
<D:resourcetype>
<D:collection/>
</D:resourcetype>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
<D:prop>
<i0:appledoubleheader/>
</D:prop>
<D:status>HTTP/1.1 404 Not Found</D:status>
</D:propstat>
</D:response>
</D:multistatus>
The same request as before, but with a an added namespace. Something about Apple properties. While a waste of bandwidth, this is legal. In my response, we’re telling Apple that we don’t know about the properties it is asking us about.
---
PROPFIND /dav/Ohne Titel 2.rtf depth: infinity <?xml version="1.0" encoding="utf-8" ?> <D:propfind xmlns:D="DAV:"> <D:prop> <D:getlastmodified/> <D:getcontentlength/> <D:resourcetype/> </D:prop> </D:propfind> RESPONSE: 404
Apple tries to verify that the file does not exist. Makes sense.
---
PROPFIND /dav/Ohne Titel 2.rtf depth: infinity <?xml version="1.0" encoding="utf-8" ?> <D:propfind xmlns:D="DAV:"> <D:prop> <D:getlastmodified/> <D:getcontentlength/> <D:resourcetype/> </D:prop> </D:propfind> RESPONSE: 404
Apple tries to verify that the file does not exist, *again*. This is weird...
---
PROPFIND /dav/Ohne Titel 2.rtf depth: infinity <?xml version="1.0" encoding="utf-8" ?> <D:propfind xmlns:D="DAV:"> <D:prop> <D:getlastmodified/> <D:getcontentlength/> <D:resourcetype/> </D:prop> </D:propfind> RESPONSE: 404
Apple tries to verify that the file does not exist, *again*. This must be wrong...
---
PROPFIND /dav/Ohne Titel 2.rtf depth: infinity <?xml version="1.0" encoding="utf-8" ?> <D:propfind xmlns:D="DAV:"> <D:prop> <D:getlastmodified/> <D:getcontentlength/> <D:resourcetype/> </D:prop> </D:propfind> RESPONSE: 404
Apple tries to verify that the file does not exist, *again*. WTF!?
---
PROPFIND /dav/data0263.007 depth: infinity <?xml version="1.0" encoding="utf-8" ?> <D:propfind xmlns:D="DAV:"> <D:prop> <D:getlastmodified/> <D:getcontentlength/> <D:resourcetype/> </D:prop> </D:propfind> RESPONSE: 404
Instead of saving the file, Apple now switches to some weird data file, which does not exist either.
---
PUT /dav/data0263.007 RESPONSE: 201
Apple tries to write the weird data file with 0 bytes of content. Oddmuse refuses to create a new empty page and fakes a successfull save.
---
PROPFIND /dav/data0263.007 depth: infinity <?xml version="1.0" encoding="utf-8" ?> <D:propfind xmlns:D="DAV:"> <D:prop> <D:getlastmodified/> <D:getcontentlength/> <D:resourcetype/> </D:prop> </D:propfind> RESPONSE: 404
Unfortunately our cheating is discovered. Apple realizes that something is wrong and prints an error telling me that the filename is probably wrong. I guess the weird data file is just a test for filename format.
And this is where it ends.
So why did Apple never attempt to save the orginal file?
Just to make sure, I change Oddmuse’s default behaviour. Instead of silently faking the save of empty files, I’ll return a 400 (Bad Request) instead.
PUT /dav/data0263.009 RESPONSE: 400
Let’s see what happens now.
---
PROPFIND /dav/Ohne Titel 2.rtf depth: infinity <?xml version="1.0" encoding="utf-8" ?> <D:propfind xmlns:D="DAV:"> <D:prop> <D:getlastmodified/> <D:getcontentlength/> <D:resourcetype/> </D:prop> </D:propfind> RESPONSE: 404
This time Apple will not mention problems with the name, it will just tell me that there were problems saving the document under that name.
Gahhh!
This kind of reverse engineering is frustrating work.
#WebDAV #Wikis