BigSmoke » Apache

Safari: don’t give gzipped content a .gz extension

Rowan Rodrik — Sun, 15 Jan 2012 22:39:13 +0000

Yesterday, while helping Caloe with the website for her company De Buitenkok, I came across the mother of all stupid bugs in Safari . Me having recently announced payformystay.com, I loaded it up in Apple’s hipster browser only to notice that the CSS wasn’t loaded. Oops!

Reloading didn’t help, but … going over to the development version, everything loaded just fine. Conclusion? My recent optimizations—concatenating + gzipping all javascript and css—somehow fucked up payformystay for Safari users. The 14 Safari visitors (16.28% of our small group of alpha users) I received since the sixth must have gotten a pretty bleak image of the technical abilities of payformystay.com’s Chief Technician (me).

The old `cat | gzip`

So, what happened?

To reduce the number of HTTP requests per page for all the JavaScript/CSS stuff (especially when none of it is in the browser cache yet), I made a few changes to my build file to scrape the of my layout template (layout.php), which I made to look something like this:

 if (DEV_MODE): ?>
  "stylesheet" type="text/css" href="/layout/jquery.ui.selectmenu.css" />                                   
  "stylesheet" type="text/css" href="/layout/fancybox/jquery.fancybox-1.3.4.css" />                         
  "stylesheet" type="text/css" href="/layout/style.css" />                                                  
 
                                            
                                               
                                 
                                        
                                               
                              
                                    
                               
 else: # if (!DEV_MODE) ?>
  "/layout/motherofall.css.gz?2" rel="stylesheet" type="text/css" />
  
 endif ?>

It’s very simple: All the files with a “&lt!--MERGE ME-->” comment on the same line got concatenated and gzipped into motherofall.css.gz and 3rdparty.js.gz respectively, like so:

MERGE_JS_FILES := $(shell grep '' layout/layout.php|sed -e 's/^.*

I chose to directly reference the gzipped version of the css/js, even though I had a .htaccess files in place (within /layout/) which was perfectly capable of using the right Content-Encoding for each Accept-Encoding.

`$ cat /layout/.htaccess`

AddEncoding gzip .gz
 
RewriteEngine On
 
RewriteCond %{HTTP:Accept-Encoding} gzip
RewriteCond %{REQUEST_FILENAME}.gz -f
RewriteRule ^(.*)$ $1.gz [QSA,L]
 

ForceType text/css

 

ForceType application/javascript

You may notice that the .htaccess file contains some configuration to make sure that the .gz files are not served as something like application/gzip-compressed.

Anyway, I went to see if there were any browsers left that do not yet Accept-Encoding: gzip and could find none. When, yesterday, I was faced with an unstyled version of my homepage, my first reaction was (after the one where I was like hitting reload 20 times, embarrassedly mumbling something about “those damn browser-caches!”): “O then, apparently, Safari must be some exception to the rule that browsers have all been supporting gzip encoding for like forever!”

No, it isn’t so. Apparently Safari ignores the Content-Type header for any resource with an URL ending in .gz. Yes, that’s right. Safari understand Content-Encoding: gzip just fine. Not problems. Just don’t call it .gz.

The new `cat ; gzip`

So, let’s remove the .gz suffix from these files and be done with it. The .htaccess was already capable of instructing all necessary negotiations to be able to properly serve the gzipped version only when it’s accepted (which is always, but I digress).

A few adjustments to my Makefile:

MERGE_JS_FILES := $(shell grep '' layout/layout.php|sed -e 's/^.*

That’s it. I welcome back all 14 Safari users looking for paid work abroad! Be it that you’re looking for international work in Africa, in America, in Asia or in Europe, please come visit and have a look at what we have on offer.

Allowing apache to set Nagios cmd file

halfgaar — Tue, 28 Dec 2010 21:13:19 +0000

On debian, to prevent:

Error: Could not stat() command file ‘/var/lib/nagios3/rw/nagios.cmd’!

Do:

/etc/init.d/nagios3 stop
dpkg-statoverride --update --add nagios www-data 2710 /var/lib/nagios3/rw
dpkg-statoverride --update --add nagios nagios 751 /var/lib/nagios3
/etc/init.d/nagios3 start

source.

Apache rewrite rule to rewrite to sub dir

halfgaar — Mon, 27 Sep 2010 14:38:03 +0000

One one particular site, I wanted to rewrite all requests to a sub dir. It took me over an hour, because of some obscure problem I haven’t been able to identify.

# The main site located in the /site dir. The .* after the ^ is weird, but without it, it wouldn't work.
RewriteCond %{REQUEST_URI} !^.*/site/.*
RewriteRule ^(.*)$ site$1 [L,R=permanent]

My guess is it has to do with:

AddHandler php-cgi-script .php
Action php-cgi-script /php5/php5-cgi

Rewrite rules to redirect to a temporary offline page

halfgaar — Wed, 22 Sep 2010 12:29:56 +0000

Sometimes you want to take a site offline for a while. You can put this in .htaccess or the vhost config:

ErrorDocument 503 "Site is temporarily offline."
        RewriteEngine On
        RewriteRule .* - [R=503,L]

When using .htaccess, be sure to have AllowOverride All.

Or when using HTML files and images:


  ServerAdmin webmaster@ytec.nl
  ServerName www.example.nl
 
  DocumentRoot /var/www/down/
 
  ErrorDocument 503 /maintenance.html
 
  RewriteCond %{REQUEST_URI} =/maintenance.html [OR]
  RewriteCond %{REQUEST_URI} =/logo.jpg
  RewriteRule (.*) $1 [L]
 
  RewriteEngine On
  RewriteRule .* - [R=503,L]

Preventing IOerror on stdout with modWSGI

halfgaar — Fri, 10 Sep 2010 15:57:09 +0000

By default, you can’t use prints in a django app, because mod_wsgi restricts that. You can change that by putting this in your configuration:

WSGIRestrictStdout Off

Changing an apache virtual host to ssl

halfgaar — Tue, 07 Sep 2010 13:07:05 +0000

To change a virtual host in apache to ssl:

#Redirect all normal traffic to the https site.
80>
  RewriteEngine on
  RewriteRule ^/(.*) https://%{HTTP_HOST}/$1 [L,R]

 
# This virtual host was *:80 first
443>
   DocumentRoot /bla
 
   # These lines were added to make it SSL
   SSLEngine on
   SSLCertificateFile    /etc/ssl/certs/ssl-cert-snakeoil.pem
   SSLCertificateKeyFile /etc/ssl/private/ssl-cert-snakeoil.key
   # if you have an official certificate, also add some of these:
   SSLCertificateChainFile /etc/ssl/certs/bla
 
   
      Order allow,deny
      Allow from all
      AllowOverride None
      Options -MultiViews FollowSymlinks Indexes

Redirect multiple domains to one

halfgaar — Tue, 07 Sep 2010 09:38:54 +0000

When a site is available under multiple domains, it is usually bad idea to not have them all redirect to one domain. In apache, do this:

RewriteEngine On
RewriteCond %{HTTP_HOST}   !=www.domain.com
RewriteRule ^(.*)$         http://www.domain.com$1 [L,R=permanent]

Disabling debug for mod wsgi

halfgaar — Fri, 06 Aug 2010 15:41:50 +0000

For the record, when deploying mod wsgi apps, remember to enable optimizations in mod_wsgi.conf. Otherwise debug will be true.

Generating a self-signed SSL certificate

halfgaar — Sun, 16 May 2010 21:42:51 +0000

This article explains nicely how to make a self-signed SSL certificate, for Apache for instance:

openssl genrsa -des3 -out server.key 2048
openssl req -new -key server.key -out server.csr
cp server.key server.key.org
openssl rsa -in server.key.org -out server.key # remove passphrase from key
openssl x509 -req -days 3650 -in server.csr -signkey server.key -out server.crt

However, later I found this to generate a CSR and key:

openssl req -nodes -newkey rsa:2048 -keyout bla.key -out bla.csr

MediaWiki thumb.php and rewrite rules

Rowan Rodrik — Sun, 07 Mar 2010 18:40:26 +0000

May, last year, I created an empty draft for this post, because, around that time, I had gone through quite some effort before I got thumbnails for foreign file repos working just right. Now, I’m taking a dive into my MediaWiki working dirs in preparation of the creation of a separate development environment, so it’s a good moment to rehash the past experience (almost as good as when I’d have done it right away).

This is how I configured the foreign file repo to be able to use images uploaded to the English wiki from the Dutch wiki:

$wgHashedUploadDirectory = false;
 
$wgForeignFileRepos[] = array(
    'class' => 'ForeignDBRepo',
    'name' => 'en',
    'url' => "http://wiki.hardwood-investments.net/media",
    'hashLevels' => 0,
    //'thumbScriptUrl' => "http://wiki.hardwood-investments.net/thumb.php",
    'transformVia404' => true,//!$wgGenerateThumbnailOnParse,
    'dbType' => $wgDBtype,
    'dbServer' => $wgDBserver,
    'dbUser' => $wgDBuser,
    'dbPassword' => $wgDBpassword,
    'dbName' => 'hardwood',
    'tablePrefix' => 'mw_',
    'hasSharedCache' => false,
    'descBaseUrl' => 'http://wiki.hardwood-investments.net/Image:',
    'fetchDescription' => false
);

To make thumbnails be generated by thumb.php on request I added the following to my .htaccess at the other end (and visa versa, because the Dutch wiki actually contains most of the images):

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^media/thumb/([^/]+)/([0-9]+)px-.*$ /thumb.php?f=$1&width=$2 [L,QSA]