Make profile / upload images unique to allow mod expires

[Fast Lane!]

A thought to save many of us major bandwidth. Right now images are uploaded with a cookie cutter format. Example: photo-thumb-71961.jpg. This is the member id. If you could make it: photo-thumb-71961-random#.jpg then the random part could change every time it was updated. This would cause a browser to download. I use mod expires and set the expiration short because I want people to be able to upload their images for the profiles and see it change without a hard browser refresh. This would allow me to set the expiration date longer (like 30 days) and have people when they update not get lost in the cache period. It could simply require the database to store the name of their profile image which I think already happens.

thoughts? I see no downside to me except to save lots of us major bandwidth that use mod_expires (highly recommended).

[Wolfie]

Downside.. more data in the database for a simple filename. :P

However I like the idea. There have been a few times when I've uploaded an image and wondered why it didn't start showing, then turned out I needed to do a hard refresh.

[bfarber]

You could use E-Tags instead, which would allow for conditional downloading (download only if updated) without any software changes.

[Fast Lane!]

Mod Expires is better and both are really useful together. Mod Expires prevents a browser from even "asking" if the file changed. E-Tags require a "did it change" and a server reply, "no; checksum the same".

http://stackoverflow.com/questions/499966/etag-vs-header-expires

They are slightly different - the ETag does not have any information that the client can use to determine whether or not to make a request for that file again in the future. If ETag is all it has, it will always have to make a request. However, when the server reads the ETag from the client request, it can then determine whether to send the file (HTTP 200) or tell the client to just use their local copy (HTTP 304). An ETag is basically just a checksum for a file that semantically changes when the content of the file changes.

The Expires header is used by the client (and proxies/caches) to determine whether or not it even needs to make a request to the server at all. The closer you are to the Expires date, the more likely it is the client (or proxy) will make an HTTP request for that file from the server.

So really what you want to do is use BOTH headers - set the Expires header to a reasonable value based on how often the content changes. Then configure ETags to be sent so that when clients DO send a request to the server, it can more easily determine whether or not to send the file back.

One last note about ETag - if you are using a load-balanced server setup with multiple machines running Apache you will probably want to turn off ETag generation. This is because inodes are used as part of the ETag hash algorithm which will be different between the servers. You can configure Apache to not use inodes as part of the calculation but then you'd want to make sure the timestamps on the files are exactly the same, to ensure the same ETag gets generated for all servers.

[bfarber]

I wasn't saying E-Tags are better. I was simply saying it's a workable solution for now to limit bandwidth consumption while still allowing to ensure that the user has the latest copy of the file.

A browser saying "has this changed" and the server saying "no it hasn't" is still less bandwidth than always serving the image regardless of whether it has changed (provided you are adamant that the user never have an expired version of the image).

[Wolfie]

I got the impression that the idea was to have a unique filename each time that a new image was uploaded, so that the browser would automatically download the new image instead of using a cached image. But otherwise, it'd use the cache instead of downloading the image over and over again. Not change the name during each page load, but simply the name of the avatar/photo when a new one is uploaded by the user.

[bfarber]

Yes, that's what he was saying. That's how I read it too.

You'd almost never want to change a filename on each page load. That wasn't what I (or he) was suggesting.

[Wolfie]

Yes, that's what he was saying. That's how I read it too.

You'd almost never want to change a filename on each page load. That wasn't what I (or he) was suggesting.

Then wouldn't it be a good idea to implement, so that a new image would have a unique name, so that it would be guaranteed to be downloaded? That way, if they change their picture ten times in a week, it's only ten unique names but should never be an issue with caching since the names would always be different.

[bfarber]

I never said the suggestion wasn't a good idea either lol. Not feeling well today Wolfie? :P

Here's what I DID say

You could use E-Tags instead, which would allow for conditional downloading (download only if updated) without any software changes.

Simply a stop-gap suggestion that can be implemented NOW without requiring any software changes. I have nothing against the suggestion and it may or may not be implemented at some point in the future. E-Tags can be used now, however, if someone wanted to.

Hope that clears up what I said a little.

[Wolfie]

Simply a stop-gap suggestion that can be implemented NOW without requiring any software changes. I have nothing against the suggestion and it may or may not be implemented at some point in the future. E-Tags can be used now, however, if someone wanted to.

Hope that clears up what I said a little.

I got the impression that there was a drawback to the idea or that it was thought to be misunderstood. It's a very simple idea but definitely a good one. Some of the better ideas are simple, come to think of it. :)