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"
Dāoh.
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:
client_max_body_size 100m;
Done! Itās so obvious when you know how.
