Click for text version
Magnus Wedberg / home

GZIP compressed SVG files, the Content-Encoding header and X-Sendfile
A problem had me going for two hours and I couldn't find the answer comprehensibly stated. So here goes.

Suppose that you use, say, Poppler-utils to extract PDF pages, turning them into SVGs.

Also suppose that you notice that a single extracted SVG-page easily can be much, much larger than the 162 page PDF you extract it from.

Suppose that you multiply that SVG-page-size with 162 and remain very unimpressed. Assume that rage enter this equation. Fantasize about XML being purged from the earth.

But I digress. Any sane person will now arrive at GZIPping the file; sure, you can GZIP the transfer in your web server, but that has an overhead and doesn't help storage space. GZIP on disk after conversion is feasible.

Trying to send this resulting file with X-Sendfile will not work however. The browser can't understand the result.

Brilliantly, there is no difference in mime type for .SVG and .SVGZ: they are one and the same. The difference is supposed to be communicated with a "Content-Encoding: gzip" header. There is only one small problem here, and this is actually stated as an official limitation in X-Sendfile, "The Content-Encoding header - if present - will be dropped". Oops. There has been talk about setting an interim header that can communicate Content-Encoding to X-Sendfile, which in turn would set the correct header, but nothing has resulted from this.

The solution? There is no solution. You will have to keep track of your SVGZ files and transfer them with a completely different mechanism than X-Sendfile, in PHP this could be using fopen, fread and fclose as in days of yore.


photos articles services about