Remove version number from CSS URLs

[e2jk]

Copied from #89:

From @nicolasdanelon:

@nodiscc @e2jk this is the last comment here. I promise. if we obscure the version N° in the footer what about this?

thanks! :) good work, I will use community version in my server since tomorrow

From @nodiscc:

@nicolasdanelon Well spotted! I'll remove that, not because it discloses the current version, but because it has no purpose. It's there to prevent browser from using old, cached stylesheets, but anyway we use the no-cache HTTP header that prevents caching (even if this is bad for performance, we re-download the CSS on every page request).

[e2jk]

We should not use no-cache, if that is truely the case.

Looking at my Shaarli running still 0.0.42, these are some of the headers sent out on a query for /:

Connection: keep-alive
If-Modified-Since: Wed, 30 Jul 2014 06:06:36 GMT
If-None-Match: "53d88b6c-431a"
Cache-Control: max-age=0

And I got a 304 response back. So we are using the cached version, but we are also sending a query out which should send us the new version, if there was a new one since July 2014 (in this case).
So it seems fine to me in the current situation.

Including some kind of variable/hash for CSS and JS resources is a widely-used webdev practice.

You could argue that even a hashed version of the CSS would still allow "the misterious cracker" to figure out which version of Shaarli is running, but as @nodiscc stated in #89 (comment) trying to absolutely hide any version number is pointless.

So the question is: is there anything we need to do on this issue?

[nodiscc]

I get a 200 response with the no-cache header on / everytime I refresh the page. I get 304 not modified responses on resources (images, CSS...). I think it's fine. Browsers should pick up new CSS versions if there are any. I don't know why the ?version=x.x.x was there in the first place. Any idea?

[e2jk]

Reason: Cachebusting.
As this is working as designed (cached CSS, non-cached Index.php) and we're not going to further remove version numbers ("Resistance. Is. Futile." mantra), I'm closing this issue.

[nodiscc]

From your link:

Traditionally, if you use a far future Expires header you have to change the component's filename whenever the component changes

I don't think we set a Expires header at all. I can't see it in my HTTP response headers. So can this be removed? If the file changes, the server should reply with 200 instead of 304 on the CSS file, right?

[e2jk]

This is what I get back from my Shaarli, running with Nginx:

Connection: keep-alive
Date: Wed, 04 Mar 2015 08:55:09 GMT
Etag: "53d88b6c-431a"
Last-Modified: Wed, 30 Jul 2014 06:06:36 GMT
Server: nginx/1.6.2

So I don't get an Expires header, and I get both Etag and Last-Modified back from the server.
In short, removing the version number should not negatively affect my setup.
I have no clue how Apache would handle this (but I suppose it would be fine also).
If we can get an Apache example, we can potentially remove the version number from the CSS as well (that removes one more thing to update prior to releasing a new version, making our workflow easier ;) )

[nodiscc]

I get the same Response headers on apache 2.2. The Request headers explicitly specify If-Modified-Since: Mon, 02 Mar 2015 14:08:56 GMT, which is the last modification date of my shaarli.css. I tried changing a single character in the file and refreshing the page, and the new CSS was fetched.

I'll remove the ?version= in the next PR. Thanks for your help @e2jk

[nicolasdanelon]

We do not need to add anything. Server Configuration establishes how to cache things. Through .htaacess archvos or * .conf in the server side configuration.

But it is a good idea to try to force once a month, _if the user to update Shaarli And we change the CSS styles_, the stylesheet is re-download

[nicolasdanelon]

Each server returns the files according to _his_ configuration. Is useless to compare what everyone sees in localhost or on your shared server.

Shaarli should not force any header or any cache. The end user must be able to decide what to do in his server configuration :)

[nodiscc]

@nicolasdanelon Patches welcome.

[nicolasdanelon]

ok. workin on that brunch asap!