Russell McClellan

Thanks for your time. I really appreciate the consideration and thought, as well as the rest of the work the editors do on this document. I completely see your point...

Transmit iOS app and the mac os finder (which uses WebDAVLibs: https://opensource.apple.com/source/webdavfs/webdavfs-293/webdavlib/webdavlib.c) use unauthenticated `OPTIONS`.

Note that this seems to be a sandstorm-specific issue, all these clients respond correctly when running davros outside of sandstorm.

Reading the apple code, it seems like it would accept either 401 unauthorized or 200 with the proper DAV headers. Responding with 200 with no dav headers makes apple think...

Uh-oh! What's the right behavior for a DAV server that requires auth? Should we return 401 on `OPTIONS`?

So, transmit as far as I know is totally closed source. Reading the code more deeply, the apple webdavfs library does seem to work so long as we never return...

Definitely any browser-based clients want a 200 response to unauthenticated OPTIONS since CORS pre-flights don't send authentications.

Hey, I've been looking at this a little bit more, focusing on the Mac Finder. It seems like auth is actually okay on the branch with the unauthenticated DAV headers,...

I've spent some time now debugging the Transmit client. It looks like they have an issue where they never send auth headers if the auth realm in the response has...

This is the same root cause as #2. I'll fix this later this week (probably thursday). Thanks for trying it out!