OSX 10.9 - Mavericks webdav client broken

I guess. I had no idea you had to manually enable it.

Dear Microsoft,

What other parts of the 15 year-old HTTP 1.1 standard have to be manually enabled?

And by the way, chunked transfer encoding has absolutely nothing to do with MIME e-mail!

<sigh>

I fix our implemtation of WebDAV which is heavily based on the Tomcat's one by replacing the method which generate the lock token. The generator of Tomcat use a MD5 hash of a concatenation of several informations, key, owner, current time in milliseconds and so on. I replace it with a UUID, the standard one of Java.

The WebDAV specs say the lock token must be: "a Universal Unique Identifier (UUID) mechanism, as described in [ISO-11578]"...

srosse wrote:

I fix our implemtation of WebDAV which is heavily based on the Tomcat's one by replacing the method which generate the lock token. The generator of Tomcat use a MD5 hash of a concatenation of several informations, key, owner, current time in milliseconds and so on. I replace it with a UUID, the standard one of Java.

The WebDAV specs say the lock token must be: "a Universal Unique Identifier (UUID) mechanism, as described in [ISO-11578]"...

You seem to be looking at an old version of the RFC. The current RFC 4918 "encourages" the use of a UUID. I am definitely using a UUID. The RFC examples use a UUID too. Tokens in this form work well:

Lock-Token: <urn:uuid:5B3C191D-E182-4008-A646-9E0D937EADC1>

Interestingly, Mavericks supplies the lock token escaped in the "If" header:

If: (<urn%3Auuid%3A5B3C191D-E182-4008-A646-9E0D937EADC1>)

That might be a bug. I have to study the details on that token.

And I have seen situations where Mavericks issues duplicate LOCK requests. That is definitely a bug but I haven't written a report for it yet. I have been busy with another WebDAV bug that no one else seems to have noticed considering that it dates back to Mountain Lion at least.

Thank you srosse,

I based my WebDav implementation on WD servlet from Tomcat 8 and everything started to work, when I changed format of lock token to UUID format:

/*String lockTokenStr = req.getServletPath() + "-" + lock.type + "-"

+ lock.scope + "-" + req.getUserPrincipal() + "-"

+ lock.depth + "-" + lock.owner + "-" + lock.tokens + "-"

+ lock.expiresAt + "-" + System.currentTimeMillis() + "-"

+ secret;

String lockToken = MD5Encoder.encode(md5Helper.digest(

lockTokenStr.getBytes(StandardCharsets.ISO_8859_1)));*/

String lockToken = UUID.randomUUID().toString();

Finder WD client requires tokens in UUID format.

"The bug with capitol B"

Guys, has anyone had any luck getting MS Office-documents Quick look-feature working under Mavericks? Anyone at all?

Running WebDAV through an Apache web server and this has worked, as mentioned by so many before, perfectly under 10.8.5.

Seems like the Sandboxing under Mavericks does not consider doc/docx, xls/xlsx or ppt/pptx safe..? Something goes wrong during the handling of tokens during Quick look's requests to the Webserver...The only time Finder is able to Quick look these are when the documents are allready opened, and hence the token given in opening the file gives Quick look access...

Is this Bug reported by any of you guys? So very exhausted by trying to crack this nut. Getting to little sleep over this.

I've even tried setting up Apples own WebDAV on a Mac 10.9 Server with the same result. Why is this not a priority Apple?

Anyone?

Help!

:)

OS X 10.9.3 (13D65) I would like to confirm that moving my WebDAV server's lock token format from "opaquelocktoken:..." to "urn:uuid:..." seems to have restored Finder's ability (WebDAVFS/3.0.1) to PUT files. Most annoying and a real time sink until I found this discussion. Thanks.

My investigations shows that in maverics, when you drag and drop a file into finder to upload it via webdav, OS breaks the file into various chunks. Now if your server supports multi-part upload, as in a file can be send in multiple requests and multiple parts and server does the stitching then it should work. Also these chunks can be of any size from 8 mb to bigger. I believe this behavior has caused integration to be broken for many servers.

Yes. That is the chunked transfer-coding from HTTP. WebDAV is an extension to HTTP 1.1, so any WebDAV server should accept "chunked" uploads.

I haven't had a huge amount of time to test it out, but it appears that the WebDAV client in OS X Yosemite Public Beta is working correctly (so far)!

Kenneth Andre wrote:

Seems like the Sandboxing under Mavericks does not consider doc/docx, xls/xlsx or ppt/pptx safe..? Something goes wrong during the handling of tokens during Quick look's requests to the Webserver...The only time Finder is able to Quick look these are when the documents are allready opened, and hence the token given in opening the file gives Quick look access...

There are multiple bugs caused by a bad sandbox configuration. I discovered some on a system, updated step-by-step from snow leopard to yosemite.

The errors are not related to file suffixes, ... however. Quick look works when "documents are already opened", because actual document data takes a valid path from webdav cache to "quicklook". When documents were not already opened, the data takes a path that is inhibited by sandbox configuration.

The actual errors:

1. quicklook-satellite does not have "network-outbound" permission on unix sockets in /private/tmp/,

system.log says:

[...] kernel[0]: Sandbox: QuickLookSatelli(507) deny network-outbound /private/tmp/.webdavUDS.rBUsy5

Solution:

• edit /usr/share/sandbox/quicklook-satellite.sb
• add line: (allow network-outbound (to unix-socket))

This can be restricted to /private/tmp/, or not...

Interestingly, /usr/share/sandbox/quicklook-satellite-legacy.sb already contains this line, but someone somewhere forgot the fact, that the quicklook-satellite on webdav volumes is not so "legacy" anymore. Or something like that.

2. Maybe these point to further issues:

system.log:

[...] kernel[0]: Sandbox: webdavfs_agent(533) deny file-read-metadata /Users[...] sandboxd[456] ([533]): webdavfs_agent(533) deny file-read-metadata /private/var/run/systemkeychaincheck.done[...] kernel[0]: Sandbox: webdavfs_agent(533) deny file-read-metadata /Library

Solution:

Maybe add appropriate rules to /usr/share/sandbox/webdav_agent.sb.
But did not investigate these yet.

I did not (yet) check, whether these errors (especially #1) also apply to fresh installations.

Robert Frunzke wrote:

Kenneth Andre wrote:

Seems like the Sandboxing under Mavericks does not consider doc/docx, xls/xlsx or ppt/pptx safe..? Something goes wrong during the handling of tokens during Quick look's requests to the Webserver...The only time Finder is able to Quick look these are when the documents are allready opened, and hence the token given in opening the file gives Quick look access...

There are multiple bugs caused by a bad sandbox configuration. I discovered some on a system, updated step-by-step from snow leopard to yosemite.

The errors are not related to file suffixes, ... however. Quick look works when "documents are already opened", because actual document data takes a valid path from webdav cache to "quicklook". When documents were not already opened, the data takes a path that is inhibited by sandbox configuration.

The actual errors:

1. quicklook-satellite does not have "network-outbound" permission on unix sockets in /private/tmp/,

system.log says:

[...] kernel[0]: Sandbox: QuickLookSatelli(507) deny network-outbound /private/tmp/.webdavUDS.rBUsy5

Solution:

• edit /usr/share/sandbox/quicklook-satellite.sb
• add line: (allow network-outbound (to unix-socket))

This can be restricted to /private/tmp/, or not...

Interestingly, /usr/share/sandbox/quicklook-satellite-legacy.sb already contains this line, but someone somewhere forgot the fact, that the quicklook-satellite on webdav volumes is not so "legacy" anymore. Or something like that.

Just tested and you are absolutely right!I haven't done any extensive testing yet, but adding the line: (allow network-outbound (to unix-socket)) Gave access to the musch needed /tmp/ area. Is there perhaps a security-reason why Apple suddenly decided to place this very important line in the quicklook-satellite-legacy.sb ?