In this week's episode of I hate repeating myself I'll explain how to make Apache send the right headers. With the correct headers SVG and SVGZ can be displayed directly in all browsers which support it.
I'll try to keep it as brief as possible and as detailed as necessary. If there are any questions feel free to ask.
To check the current situation and to verify the results of our changes we need to know how the desired result should look like.
| File Extension | Required (Additional) Response Header(s) |
|---|---|
| svg | Content-Type: image/svg+xml |
| svgz | Content-Type: image/svg+xml Content-Encoding: gzip |
As you can see the Content-Type headers for SVG and SVGZ are identical, but SVGZ also comes with a Content-Encoding header, which is used by the client to determine how to decode the data.
Unfortunately Opera doesn't rely on the Content-Encoding header to determine the encoding. It always probes the data and gunzips it automatically. This means you cannot verify if it works correctly with Opera itself. I really wish they hadn't done that.
So, for verification I recommend to use Firefox and the awesome Web Developer Extension. With that extension you can easily view the response headers via:
Information -> View Response Headers
Be also sure to clear the cache each time you change Content-Type or Content-Encoding headers, because CT/CE caching is a bit aggressive. That function is accessible via:
Miscellaneous -> Clear Private Data -> Cache
Without the Web Developer Extension it's a bit more long-winded:
Tools -> Options... -> Advanced -> Network -> Cache -> Clear Now
.htaccess is pretty unproblematic and it can be also often used on cheap shared hosting. Additionally, no restart is necessary. The .htaccess file can be placed in any directory and all changes are applied to this directory and all of its subdirectories (as long as the rules aren't overwritten again via another .htaccess file).
AddType image/svg+xml svg svgz AddEncoding gzip svgz
If you already have some .htaccess in your root directory just add those lines at the beginning.
Some FTP clients don't show the .htaccess file, which is sorta troublesome if you want to download the currently used one. The reason for this is that files starting with a '.' are "hidden" on unixoid file systems. To show hidden files check the view menu. In Filezilla's case it's Server -> View hidden files. (Interestingly the file is visible either way with the version of Filezilla I'm currently using. It wasn't like that with older versions.)
Clear the browser's cache, reload, and check the headers.
httpd.conf is located at "apache/conf/httpd.conf". You should have there a <IfModule mime_module> (or similar) section. Ensure that these two lines are there:
AddType image/svg+xml svg svgz AddEncoding gzip svgz
Alternatively you can only add the AddEncoding line and take care of the mime type via mime.types in the same directory. Ensure that the following line is there:
image/svg+xml svg svgz
Restart Apache then clear the browser's cache, reload, and check the headers.
If both options aren't available just nicely ask the provider/hoster to fix this issue. In many cases they are surprisingly cooperative and fix it in a matter of hours (or days - be a bit patient ;)).
If you're fixing this for someone else you need of course some test data:
test_data.zip (2kb)
Comments
Thanks!
Many thanks for this hint!
Under debian/etch I just needed to add an AddEncoding gzip svgz right under AddType application/x-gzip .gz .tgz - /etc/mime.types was already ok. After /etc/init.d/apache2 reload it works now :)
with best greatings from inkscape-forum.de
ThorstenS
This corrected in apache since August 27
The SVGZ are now in standard httpd distribution config files (mime.types)
(This is at least in the httpd-2.2.6)
Changes In 2.2.x branch :
http://svn.apache.org/viewvc?view=rev&revision=570217
In trunk :
http://svn.apache.org/viewvc?view=rev&revision=570206
Errata
Forgot to post this. As the previous poster pointed out the mime types for SVG and SVGZ are set by default with recent versions of Apache. However, the Content-Encoding for SVGZ isn't set.
It appears that they aren't sure if it's required by the specs and therefore they are unsure if it should be added. Well, there is some finger-pointing involved and I'm also not quite sure about this aspect.
But most implementations need it. So, there is really no option but setting the CE to gzip.
I'd think switching svg and svgz is preferable
I think it's actually better to (non-intuitively) have Apache add gzip (or deflate) encoding to svg and NOT svgz, like so:
AddType image/svg+xml svg svgz
AddEncoding gzip svg
Think about it. The svgz you're serving is already compressed, so no need to have Apache and the browser compress/decompress it again, it's just adding another layer of compression. The svg you're serving is plaintext XML and so you WANT to have Apache compress it and the browser decompress it transparently, just as you would for css or js.
This guy at wikimedia came to somewhat the same conclusion: http://www.mail-archive.com/wikibugs-l@lists.wikimedia.org/msg02011.html
- Scott Stafford
re: I'd think switching svg and svgz is preferable
Ahm...
AddEncoding gzip svgzdoesn't cause any compression (it's part of mod_mime). It merely tells Apache to set theContent-Encodingheader togzipif a file of that type is requested.On-the-fly compression is handled by mod_deflate by the way. One shouldn't use on-the-fly compression for static resources; it's wasteful.
The link you've posted explains the same thing in the first paragraph. SVGZ uses the same mime type as SVG. The only difference is that it's gzipped, which in turn needs a matching
Content-Encodingheader if a browser is used which doesn't do any encoding sniffing.Opera for example doesn't need it since it detects gzipped stuff automatically. Firefox, however, does need it, because expects the headers to be correct.
Post new comment