WWW posts page 29

Logging service worker cache headers

As part of the service worker API, a cache interface has been provided to manage cached request-response pairs. In working on the service worker for my site, I wanted to see what headers the cached requests and responses had, but due to the asynchronous way many of the cache properties are accessed, this was a bit verbose. I wrote out a script that I could paste in the JS console to look at all stored request-response pairs in a given cache so I could examine them:

caches.open('cache-name').then(function(_cache){ 
    _cache.keys().then(function(_keys){ 
        _keys.forEach(function(_request){
            var _requestLog = [];
            _requestLog.push(['request', _request.url, _request]); 
            _request.headers.forEach(function(){ 
                _requestLog.push(['request header', arguments]); 
            }); 
            _cache.match(_request).then(function(_response){ 
                _requestLog.push(['reponse', _response]); 
                _response.headers.forEach(function(){ 
                    _requestLog.push(['response header', arguments]); 
                }); 
            }).then(function(){
                _requestLog.forEach(function(_item){
                    console.log.apply(console, _item);
                });
            });
        });
    }); 
});

Replace cache-name with whatever key you’re using for your cache. Be warned that this will produce a long log if you’ve got more than a few items in the cache. You can also see just the requests you have a cache for with something like:

caches.open('cache-name').then(function(_cache){ 
    _cache.keys().then(function(_keys){ 
        _keys.forEach(function(_request){
            console.log(['request', _request.url, _request]); 
        });
    }); 
});

Self-signed certificate for testing

In playing with service workers, I set up a self-signed SSL certificate for my local development environment. I used instructions from debian.org. It was very simple, since I didn’t need the security involved with a real operating site. Creating the certs took a single command:

openssl req -new -x509 -days 365 -nodes -out /path/to/server/config/certs/sitename.pem -keyout /path/to/server/config/certs/sitename.key

You then just need to set things up in the server configuration (Apache in my case). mod_ssl must be installed and enabled, which looks something like:

Continue reading post "Self-signed certificate for testing"

First play with service workers

I started playing with service workers as a client side cache manager a bit tonight. I’m using this Smashing Magazine article as a guide. I’ve been reading a bit here and there about them, intrigued by their role in making web sites installable as apps and their ability to allow sites to function even while offline. However, my site’s current lack of pages and other priorities plus the learning curve and things that have to be done to set them up kept me from playing with them until now.

Workers require HTTPS, unless, luckily, you are serving from localhost. I had to modify my local app install to use that instead of the more site-indicative name it was using. They also require placement at or above the path level they apply to, or theoretically a Service-Worker-Allowed header, though I was unable to get that working. I’m assuming this is for some security reason. Because my file is stored in a Symfony bundle and because I am serving multiple sites with the same application, I didn’t want an actual file in my web root. I made a Symfony route and action that passes through the file, like:

Continue reading post "First play with service workers"

On my site, I’m using Apache’s ‘mod_deflate’ and ‘mod_filter’ to compress my compressible responses (mostly text), with a setup based on h5bp’s server config. I got my sites running over HTTPS recently, and today, when looking at my site performance with webpagetest.org, I noticed that my content wasn’t compressing. It was still working fine over HTTP. I noticed in h5bp’s comments that <IfModule mod_filter.c> could be removed in Apache versions below 2.3.x. I removed it, and sure enough, compression was working again. I’m not sure why it’s different depending on what protocol I use. Perhaps Dreamhost has separate versions of Apache running for the two protocols. Or perhaps it’s just something different about the configuration in the virtual hosts. Regardless, it’s working now. I just hope this doesn’t cause problems whenever they move to Apache 2.4.


Used SSL Labs’ SSL Server Test to analyze my site now that I have LetsEncrypt certificates installed. Got an A. The only things of note it mentioned were:

  • My HSTS is too short. It considers less than 180 too short. The cert isn’t even valid for 180 days (90 for LetsEncrypt). My HSTS is actually only one day, and I will probably leave it on the short side until I’m sure things are safe.
  • It is an SNI certificate, so it will not be supported by some old browsers. 94%+ is good enough for me when I still support HTTP.

Went to a refresh cleveland event tonight, ReactJS: A hands on introduction. We worked on a simple contact list application tutorial created by the speaker. It was a nice simple introduction to React JS and ES6. I paired with someone, and we made it about halfway through. I will have to look at it in more depth later.

React JS is a view library for javascript that uses virtual DOM diffing with the real DOM to increase rendering performance. It also uses JSX to combine templates with view controller logic. I have been interested in it for a while but never really played with it where I got to actually use it. This was in part because I was most interested in server-side rendering with it and couldn’t get that to work, and because it requires some transpiling to use it in browsers when using JSX.

This was also my first time really using ES6. I’ve been reading a lot about it. Some of it looks interesting, but it also requires transpiling to work in many browsers. Some of it can be cool, but also foreign and hard to parse for someone new to it. I’ve thought it would be cool to write in ES6, transpile to ES5 and ES3, and then use mustard cutting to determine which to serve. It’s hard to figure out how to transpile to ES3 though, and that would significantly complicate my workflow. It doesn’t seem to offer quite enough to be worth it for me.


Struggling to figure out why every response from my Symfony application is showing up in the log files as a ‘200’ status. I thought it was related to this and this, since I’m running under FastCGI on Dreamhost, but attempting to set a Status header didn’t help. Setting a regular response header in a plain PHP file does work, in fact. If I use ‘mod_rewrite’ to write another URL to load that same plain file, however, the status shows as ‘200’, so it must have something to do with ‘mod_rewrite’. Must get to bed though, so I will have to try another day.


My sites now HTTPS with LetsEncrypt

My sites are now HTTPS-enabled with LetsEncrypt. It was easy to set up with Dreamhost’s panel. It was just a few clicks and some waiting. This is the first time my own sites have been available over HTTPS. I’ve been wanting to do it for a while, but it was kind of costly until the free LetsEncrypt became available. This brings my sites in line with the “HTTPS Everywhere” movement. I’ve also been wanting to play with the new installable apps forming standard for making web apps installable almost like native apps.

I had written a post before about how I’m setting my security-related headers. I’ve now added an HTTPS related header in a similar manner: Upgrade-Insecure-Requests and HSTS.

Continue reading post "My sites now HTTPS with LetsEncrypt"