You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Basically, the request is it would be nice to specify a version number for the client (browser) js file, and in so doing, have the file automatically served with far-future caching headers.
The text was updated successfully, but these errors were encountered:
Adding a Expires is good idea, but I don't think we should do that by default for the /socket.io/socket.io.js path. We could detect if the user has a version number in the path /socket.io/socket.io.v0.8.4.js and then add a agressive Expires header to the request.
This ways old behavior will be unchanged and more advanced caching will be made possible for those who want it.
(We might want to do the same for the WebSocketMain.swf file, but that is probably a bit harder to detect :-))
you shouldn't do both ETag and Expires... only do one or the other. It seems fine to do ETag as the default. This specific request was, if you put a version number in the URL of the .js file, that instead of it doing an ETag, it did a far-future expires.
See: https://twitter.com/#!/rauchg/status/121402676234817536
Basically, the request is it would be nice to specify a version number for the client (browser) js file, and in so doing, have the file automatically served with far-future caching headers.
The text was updated successfully, but these errors were encountered: