This weekend I attended the first Oxford Indieweb camp, kindly organised by Garrett.

Day 1

Due to an early start, and not enough coffee, I had left my phone at home, and so couldn’t log into anything. Two factor auth on things is great, but I think I’ve just spotted a flaw.

Anyway.

I didn’t go with much of a plan, except to meet some techy folk. So that much I achieved.

I had some thoughts about maybe looking into federalisation – cross user login, friend/follow etc. But I also sensed this was going to likely be more than was achievable in the time I had.

During introductions, I mentioned to folk that I was a contributor to Known and gave the project a bit of a shill, since I figured it might be interesting to folk by way of giving them a head start on a few things. So, spent the day helping one of the attendees write their first plugin for it.

After a day of discussion and coding, we retired to a local pub for some more relaxed conversation.

Day 2

Rain stopped play, which was a shame. Many folk decided to stay home. Nevertheless, had a pleasant morning chat over coffee and bagel with Beverley, hiding from the rain.

After braving the shops, and meeting up with a catch up with other friends, I went home and started sketching out some federation / Vouch ideas I had after some interesting discussions.

Great weekend of techy fun, more again soon, please!

I have previously talked about speeding up your site by using Squid as a reverse proxy to cache served pages. This is a great thing to do, but presents a problem now that all sites are moving over to HTTPS, since for various technical reasons reverse proxies can’t really handle HTTPS.

These days the standard way of doing this seems to be using Varnish as a cache, and Squid seems to be a little “old hat”, however I have several client estates which were set up before Varnish came on the scene, so I needed a solution I could get up and running very quickly.

Terminating HTTPS

Thankfully, the solution is very similar whatever reverse proxy you’re using. The solution is simple, you need to install something that terminates and handles the HTTPS session before sending it to your proxy. The simplest way to do this is to install NGINX and configure it to handle HTTPS sessions.

1) Disable Apache’s handling of HTTPS (if you’ve got an existing, un-cached, HTTPS server).

2) Install the basic nginx apt-get install nginx-light

3) Configure nginx to forward to your proxy (which you have previously configured to listen on port 80)

After restarting nginx, you should be able to see https requests coming in on your squid proxy logs.

Gotchas

The biggest gotcha that you’re going to hit is that if you’re checking whether a request is HTTPS in your app (e.g. for automatically forwarding from insecure to secure), you’re not going to be able to use the standard protocol checks. The reason being is that HTTPS is being terminated by nginx, so by the time the session hits your app, it will not be seen as secure!

To perform such a test, you’re instead going to have to check for the X-Forwarded-Proto header instead ($_SERVER['HTTP_X_FORWARDED_PROTO'] in PHP).

I recently did a little bit of work to help speed up some things in Known, those of you watching the project will have seen work to minimise things like javascript and css.

Anyway, I ran Google insights over my Known install, and was surprised that files weren’t being compressed. It used to be the case that all you had to do was enable mod_deflate or mod_gzip on apache, but somewhere along the line the configuration must have changed.

Long story short, I needed to enable it by creating a /etc/apache2/conf.d/deflate.conf file… here’s mine: