tags:

views:

94

answers:

3

ETags allow browsers to perform conditional GETs. Only if the resource in question has been altered will the resource have to be re-downloaded. However, the browser still has to wait for the server to respond to its request.

An alternative to ETags is to introduce a token into the URL pointing to the resource:

http://example.com/css/styles.css?token=134124134

or

http://example.com/css/134124134/styles.css

Both approaches avoid having to re-download an unchanged resource.

However, using URLs with tokens allows the server to set a far-future expiry header on the resource. This saves the round trip taken up by a conditional GET - if the resource is unchanged then the URL pointing to it will be unchanged.

Are there any advantages to using ETags over URLs with tokens?

A: 

Have a constant URI?

jldupont
Does it matter if my URIs change? By having changing URIs I'm saying that each version of the file is a seperate resource. Is there any problem with that?
ctford
depends which sort of resources I guess: for CSS/JS, it probably doesn't matter that much.
jldupont
+1  A: 

I think the biggest difference/potential advantage would be configuration; The URL setting must be configured/setup inside the application (eg, the HTML actually must include the value). ETags are configured for the entire web server, and the HTML doesn't have to be modified to take advantage of them.

Also, the ETags will (assuming they are configured correctly) change when the file pointed at changes; Adding a token to the URL will require some additional "thing" that tells it to change (either a person editing the HTML or some configuration setting, etc).

Chris Shaffer
+1  A: 

The major downside for read-only resources that I see is that if we all took this approach for all static resources then client caches would start to fill with all sorts of out-dated resources.

Also, think of all the intermediary caches that would start holding loads of useless files.

You are fighting against the web with this approach and if it became popular then something would have to change because it is not a scalable solution.

Could there be some kind of hybrid approach where you use a limited set of tokens and set the expiry small enough that an old cached resource would expire before the token was reused?

Etags are also used for read-write resources and in this case the I suspect the token solution just does not work.

Darrel Miller