Late Night Links – Sunday June 28, 2015

It’s been a busy weekend and as I write this it’s evening, Charlie Brown is going to want to go for his pre-bed time walk soon, and I’m going to want to retire to the air conditioned bliss that is the bedroom. Only one thing stands in my way, and that’s my regularly scheduled late night links post, so let’s end the preamble here and proceed, shall we.

And we’re done! Have a great week internet folk, I’ll be back next week – same time, same place.


WebDAV Woes with Nginx, Sabre/Dav

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
, 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

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:, server:, request: "PUT /Calendars/Williams_Jason_Calendar.ics HTTP/1.1", host: ""


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.


How email became the most reviled communication experience ever

This is an interesting read.

At Google I/O in 2009 Google introduced Google Wave, a re-imagining of email. I still maintain this was a much better tool for business communication than email is. The product was killed off only about a year later. Wave had some great technology, but Google failed to even try to sell it to the enterprise. Ultimately the problems Wave solved weren’t technical ones, they were business ones.

That all being said, is the way to solve the current problems with email overload really to replace it with a different tool? I don’t know the solution, but I certainly agree there’s a problem.

How email became the most reviled communication experience ever


Late Night Links – Sunday June 21st, 2015

It’s a lazy Sunday in the @Jaywll, @asiancwgrl, @SnoopysBF household, but there’s always* time for some late night links. Let’s get started!

And we’re done for another week, folks! See you next time.

* Usually