This one took me a while to track down. My brother uses my subversion repository, and he was trying to commit a 1MB flash file. The TortoiseSVN error he got back was:

This was a bit perplexing. I figured it was some sort of mod_dav setting I had never encountered, so I turned to Google. Google spouted a bunch of stuff about where to put your SSL directives in your Apache configuration, some stuff about Apache not handling the Content-Length header correctly, some promising mailing list threads about using the LimitXMLRequestBody mod_dav directive, and a bunch of stuff about some idiots trying to commit 4GB files to a subversion server running on Windows.

None of these were my problem.

It turns out I needed to add another keyword to my search. After I searched for svn apache nginx “entity too large”, the first hit took me home. Like everyone else who is awesome, I’m using nginx as a proxy to Apache running mod_dav. nginx’s configuration was getting hit first, and Apache and Subversion had nothing to do with anything.

It turns out the default maximum request body size for nginx is 1MB, exactly the size my brother was trying commit to the repository. Adding this one line in my virtual host solved it all:

server {
    listen 80;
    server_name svn.tommymontgomery.com;

    client_max_body_size 10m;

    location / {
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-Host $host;
        proxy_set_header X-Forwarded-Server $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_pass http://svn.tommymontgomery.com:8080;
    }
}

<script type="text/javascript" src="http://linkurious.com/js"></script>

where the src attribute was pointing to an external server; namely, my server. If enough people start using these utilities (extremely unlikely, although they are pretty awesome) it could be a strain on my server.

So I decided to offer a plain text version and a gzipped version. But I didn’t want to store two versions of the scripts in separate places on my server just to satisfy that need. The reasons had nothing to do with disk space or anything tangible; I just didn’t “feel right” doing something so hackish. Damn this ego of mine!

Anyway, once I figured out how to use mod_deflate:

#DER!
SetOutputFilter DEFLATE

I realized that that would make everything gzipped! OH NOES!! But then I noticed you could filter the… er… filter by mimetype, like so:

#only text/html will be gzipped
AddOutputFilterByType DEFLATE text/html

But that still didn’t help me. I needed conditional gzipping, like if the query string said ?gz it would know to serve the document gzipped; otherwise, it would just serve it with no compression. But how to accomplish this? Apache’s docs were no help. Luckily I’m fairly proficient at mod_rewrite, and I’m decently intelligent. Let’s see if I can figure it out (SPOILER: I figured it out; this 1st person past-tense non-omniscient narrative is just a literary technique).

Here were my requirements:

1. A request to http://acronymulator.com/1 would serve the JavaScript document with no compression
2. A request to http://acronymulator.com/1/gz would serve the JavaScript document with gzip compression
3. Only one physical copy of the document exists on the server

Let’s get to work!

First, let’s do the rewrite rules:

RewriteEngine On
RewriteRule ^/([1-9]\d*)(?:/gz)? /acronymulates/$1.js

The first line turns on the rewrite engine. The second line matches anything from the root that is made up of numbers, at least one number long where the first number is not a zero, with an optional /gz on the end. The rule finishes by internally redirecting those to the acronymulates directory, and serves up the JavaScript file whose name is the number with .js at the end. Simple enough, right? Sure.

Hopefully, you’ve deduced that /gz indicates that we want gzip compression; if it’s omitted, we don’t want gzip compression. Notice that it’s redirecting to the real JavaScript file whether the /gz is tacked on the end or not.

Now we need to do the deflate stuff. How we do it? Well, the most obvious solution is something like this:

<Directory /path/to/acronymulates>
    SetOutputFilter DEFLATE
</Directory>

This makes sense because the only thing in the acronymulates directory is the JavaScript files that we want to compress. See?

The files inside the acronymulates directory

However, this will force gzip compression no matter what, and we want it be conditional: only when the /gz is part of the URL. What do we do?

Location to the rescue!

The Location directive accomplishes this for us. more specifically, the LocationMatch directive accomplishes this for us. The difference between Directory and Location is that Directory matches a physical directory on the filesystem, whereas Location just matches a virtual directory (i.e. the path of the URL: /1/gz, in our case). Now it’s fairly obvious what the solution should be:

<LocationMatch /[1-9]\d*/gz>
    SetOutputFilter DEFLATE
</LocationMatch>

And there’s your dynamic gzipping using Apache. Note that these are real life examples (IRL ZOMG). Let’s prove it with Firebug’s help.

Without compression (http://acronymulator.com/1:

Dynamic gzipping: without compression

Without compression (http://acronymulator.com/1/gz:

Dynamic gzipping: with compression

And here’s proof that both URLs serve the same content:

Proof that both URLs serve the same content