Dealing With Dashcode, Part 3: Dashcode, WebDAV, and Trailing Slashes
(This is a continuation of a previous post. You may want to read the first post in this series for an overview of the architecture.)
At this point, I had a WebDAV-accessible directory that I had configured Dashcode to deploy to. It worked to deploy once, but after that, future deploys would fail. A dialog box would appear with the title, "An error occured while deploying the project to the server." and the text, "The folder “myapp” cannot be created on the server." After that, the status at the top of the Run & Share page would show "Last deploy attempt failed: The folder “myapp” cannot be created on the server."
The problem is that Apple's WebDAVFS will send a WebDAV PROPFIND request for "serv/myapp" (which is a folder), get a 301 redirect to "serv/myapp/" (with a trailing slash this time), and then send a PROPFIND for "serv/myapp/", but using credentials which are only valid for "serv/myapp". Apache doesn't like that, sends a 401 Forbidden response, and WebDAVFS gives up and sends an error to Dashcode. (I'm not sure whether this particular problem of retaining credentials across redirects is specific to WebDAVFS, or if it's actually in CFNetwork.)
The solution is to not have Apache send the 301 redirect. Adding this to the Location section for my DAV URL does the trick:
After this, I could deploy repeatedly from Dashcode with no problems.
This is as much as I needed to deploy my app. Debugging it, though, was still of an issue. See the next post!
At this point, I had a WebDAV-accessible directory that I had configured Dashcode to deploy to. It worked to deploy once, but after that, future deploys would fail. A dialog box would appear with the title, "An error occured while deploying the project to the server." and the text, "The folder “myapp” cannot be created on the server." After that, the status at the top of the Run & Share page would show "Last deploy attempt failed: The folder “myapp” cannot be created on the server."
The problem is that Apple's WebDAVFS will send a WebDAV PROPFIND request for "serv/myapp" (which is a folder), get a 301 redirect to "serv/myapp/" (with a trailing slash this time), and then send a PROPFIND for "serv/myapp/", but using credentials which are only valid for "serv/myapp". Apache doesn't like that, sends a 401 Forbidden response, and WebDAVFS gives up and sends an error to Dashcode. (I'm not sure whether this particular problem of retaining credentials across redirects is specific to WebDAVFS, or if it's actually in CFNetwork.)
The solution is to not have Apache send the 301 redirect. Adding this to the Location section for my DAV URL does the trick:
<Location /myapp-devel/dav/>This is probably a good thing to do on all DAV directories, since redirection isn't exactly a great thing to do within a filesystem.
</Location># In addition to the DAV-related directives# I talked about in Part 1, add:DirectorySlash Off
After this, I could deploy repeatedly from Dashcode with no problems.
This is as much as I needed to deploy my app. Debugging it, though, was still of an issue. See the next post!
Comments