tags:

views:

126

answers:

2

Hello Experts,

I have a big question: Please see the example link below. My application currently appends to all "resources/links" a Session ID. I more or less stumbled upon this by accident looking in the Firefox Cache:

http://localhost:8080/jquery-ui-1.7.2.custom.css;jsessionid=A8483FBF3BB6DDA499E06210BE0D612C

My big question is, will a URL like the URL above lead to the fact, that any caching Header (I use Cache-Control with several Years) will become more or less useless, as the session ID will make every request unique?

(==>What I mean is, that a new sessionID is assigend after 30 Minutes. And caching will most likely then only be effective within this period. After this period a new Session ID will be generated, indirectly invalidating all the cached content on the client side, that has the SessionID in its url = the url changes as it now has a new sessionID.)

=> Are the browsers as intelligent to find out that the resource to cache is:

http://localhost:8080/jquery-ui-1.7.2.custom.css

and not:

http://localhost:8080/jquery-ui-1.7.2.custom.css;jsessionid=A8483FBF3BB6DDA499E06210BE0D612C

Or will a sessionId in url lead to the fact that caching is more or less disabled in the browser?

Thank you very much! jan

+2  A: 

This isn't a question of if browsers are smart enough. The W3 standard for HTTP states that different URLs should be cached separately. So browsers are correct in observing the full URL, including GET arguments such as a session ID in their caching.

You should not be appending the session ID to anything that is static (such as your style-sheet).

Ben S
hello ben, thanks for your answer and the link. I googled, but the W3 document didnt show up. Its a great document explaining everthing, exactly what I was looking for. So thanks for your answer.
jan
I recently answered this question: http://stackoverflow.com/questions/1674493/back-button-browser-behavior/1674525#1674525 so I had the link handy :D
Ben S
+1  A: 

You are correct - the browser is not smart enough, and a changing URL will pretty efficiently negate caching.

Why do you have the session ID there in the first place? If the resource is not session-dependant, then remove the session ID from the URL and that will fix your problem. If the resource is session-dependant, then you already have all you need, because one session should not use the resource from another session.

Vilx-
hello Vilx, thank you very much for your answer.
jan