serviceWorkers posts

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]); 
        });
    }); 
});

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"