Category: Uncategorized
6 Nabin Nepal (Starx) apache cache css htacces javascript js php stylesheet versioning web-development
June 28, 2017

Auto version your JavaScript or Stylesheet files using .htaccess

Usually, developers can maintain the cache they maintain themselves at the backend but cannot control the cache held by the browser as freely as they want unless there is proper version control. Here is a quick drop in solution in `.htaccess` file until you have proper versioning.

Most of the applications have one or many layers of cache for their system. The cache that application developer can maintain is at the backend (the server) level. However, you cannot control the cache held by the browser as freely as you want unless you version the files as well.

Versioning the files is definitely the best way to solve this problem because it is a very efficient solution which guarantees that browser will fetch the new resource when you want it to. But there are cases where this is not an easy step to be taken, for example, in a legacy app which resources are included in line the page.

So, is there a quick way to fix the problem until you go to proper versioning?

Yes! there is.

Using .htaccess we can auto version the files and force the browser to fetch files down to every second if we need to.

Here is how:

We can use server variables such as TIME_YEAR, TIME_MONTH to create an automatic version of your resource. These are variables that the web server provide to be used where suitable. And now, let’s see how to do this.

RewriteCond %{QUERY_STRING} !(v=(.<em>))
Rewriterule ^(js|scripts|css|styles)(.</em>)$ /$1$2?v=%{TIME_YEAR}%{TIME_MON}%{TIME_DAY}%{TIME_HOUR} [r=302,nc]`

Open your .htaccess files and paste those two lines in. What these are doing is:

  • If a request comes to the server that starts with js, scripts, css or styles then rewrite the request by appending an auto-created version at the end.
  • IF a request comes with the version already in the request then don’t do anything because we don’t want it to keep rewriting the request.

Simple as that. So for example: if the request comes to https://abc.com/js/main.js it gets served as https://abc.com/js/main.js?v=2017062811. Same goes for any request coming to other paths as well. This example ensures that browser will fetch the resource again every hour. But if you add variables like TIME_MINUTE or TIME_SECOND or TIME browser will keep fetching the content more frequently.

To see what other server variables can be used visit https://httpd.apache.org/docs/trunk/expr.html#vars

Nabin Nepal (Starx) docker docker-compose insecure-origin node.js service-worker udacity
June 30, 2016

How to run Witter app from Udacity “Offline Web Applications” course using docker?

This blog post shows how you can run the Wittr application from a Udacity course called ‘Offline Web Applications’ using docker. This is helpful if your development stack does not run on localhost and you want to overcome `insecure origin` issue of the browsers.

Note: This is blog post, so I have written a bit back story as well. If you don’t want to read about that clone https://github.com/starx/wittr.git run docker-compose up -d Done!

I was trying a course from udacity called “Offline Web Applications” and I got stuck in the point where I was trying to register the service worker. That was because the request to register the service worker was coming form an insecure origin. Nowadays, modern browser browswer have started to deprecate powerful web feature on insecure origin (more here)) and the course fails to address this issue because the developer’s stack can vary. So the question is What is secure origin?

In chrome “Secure origins” are origins that match at least one of the following (scheme, host, port) patterns: more here

(https, *, *)
(wss, *, *)
(*, localhost, *)
(*, 127/8, *)
(*, ::1/128, *)
(file, *, —)
(chrome-extension, *, —)

So it still supports developer in a way that is does not restrict request from localhost 127... or ::1. Which was another thing to fix because my development stack is not be the most common one as I don’t use localhost to test my work. I do these through vms, vagrant and nowadays from docker as well. This means that most of the time the test url is anything but localhost. So stuck on this for a while I tries several things, like trying to turn off insecure origin flag on flag, proxy, trying to point localhost to another ip is windows 10 bunch of bullshit which is just lost time. So I created a docker configuration to run the witter project.

file: Dockerfile

FROM node:latest

# Create app directory
RUN mkdir -p /usr/src/app
WORKDIR /usr/src/app

# Install app dependencies
COPY ./* /usr/src/app/
RUN npm install

# Bundle app source
COPY . /usr/src/app

EXPOSE 8888 8889
CMD [ "npm run serve" ]

Simple enough for those who know docker basics. It binds with the ports in the host, so the project will run as localhost:8888 and localhost:8889 as the course wants. But if you want to know what it does, I am happy to explain it.

I have forked the course repo and have added this (with a docker-compose.yml as well) to the project itself at:

https://github.com/starx/wittr

Clone https://github.com/starx/wittr.git rather than the one provided in the course and run docker-compose up -d and continue with the course. I have also have created a pull request to help others but there is already 2 previous pull request pending without any comments, So I doubt it will be pulled.

Comments appreciated.

...

Please fill the form - I will response as fast as I can!