I’m in the process of moving my hosting to a new server, because I wanted one that offers me more flexibility, and the ability to grow the server and add resources to it during spikes in demand. I’ve chosen to go with Vultr (I recorded a screencast about six weeks ago showing how easy it is to set up a new server on their platform). I’ve also moved some non-essential hosting duties to another provider altogether, CloudAtCost.
Anyway, this is not really my point.
One of the things on the server I’m going to be decommissioning is a private WebDAV store. I don’t use it for much, just moving the occasional file between computers and “publishing” my work Outlook calendar so that I can subsequently synchronize it back to my Google calendar and get notifications on my wrist. It’s the WebDAV server that I’ve been setting up this week.
Most of the stuff that I’m moving to new servers is being moved as-is: this is not an exercise in updating stuff, it’s about making sure I’m done with the old server by the time my lease on it expires, but there were some things about the WebDAV share that I really wanted to update, so I took the opportunity.
The main thing I wanted to achieve was to use my Windows domain username and password on the site. Most of my password-protected web tools are already set up that way, but the WebDAV share was lagging behind. Since this means I have to use “basic” authentication instead of the “digest” authentication I previously had set up this posed another problem. Windows’ built-in WebDAV client doesn’t allow basic authentication on unencrypted connections (because that means the password is sent in the clear), so I had an SSL certificate issued. Then I found out that the Windows WebDAV client doesn’t support server name identification, which meant some additional reconfiguration, and since I was doing that I figured I may as well take the opportunity to update to the latest version of sabre/dav, which is the PHP-based WebDAV server I use (I find it much easier to set this up than to use the built-in WebDAV functionality on web server software, which I’ve never been able to get working no matter which server software I’m using).
I set all this up this week, tested it out by adding it as a network location on my personal and work laptops, and, once I was satisfied it was all working well, pointed the domain name at the new server and deleted the files from the old one.
Then I fired up Outlook, and hit the button to publish my calendar.
It didn’t work.
It ended up creating a file with the right name, but a size of zero bytes. A quick google search revealed there could be many reasons for this, and since I’d made the rookie mistake of changing everything I really didn’t know where to start, not to mention that by this time I’d deleted the original files and so I couldn’t go backward. I tried everything, with no success. I spent a good chunk of my day on Tuesday troubleshooting.
All along I’d been convinced that the issue was with sabre/dav. After all, all the other server functionality was working, so what other explanation could there be for the one bit of it that sabre/dav was responsible for being non-functional?
After a few hours though I was pretty sure that I had it set up correctly, and I was convinced that I’d either found a bug in sabre/dav or nginx. I checked the nginx logs.
2015/06/23 16:24:41 [error] 18736#0: *33 client intended to send too large body: 1945486 bytes, client: 75.159.xxx.xxx, server: xxxxxx.jnf.me, request: "PUT /Calendars/Williams_Jason_Calendar.ics HTTP/1.1", host: "xxxxxx.jnf.me"
All the files I’d tested the share with were very small, but my published calendar with 30 days history and 60 days of future events was 1.85mb. The server was configured to accept uploads with a maximum size of 1mb.
I added a single line to my nginx server configuration:
Done! It’s so obvious when you know how.