"there's indeed a related bug" Do you know if there any documentation for this bug?
The server side way of looking at it is interesting, I never thought of it from that perspective. I could change my php resize function to add in the string '800x600' onto the end of the filename when it remakes the image. That would be a more elegant solution, although it seems a lot of trouble for a browser that simply won't read the size of an image in it's cache when I call up the getSize() function, even after a dozen refreshes. If I can't find anything else I will alter the php, thanks for the advice. On Feb 1, 6:10 pm, Sanford Whiteman <[email protected]> wrote: > > I know it sounds like I am missing something dumb... > > You're not missing something dumb in that there's indeed a related > bug. However, your fix is poorly designed. > > If you have a back end in which pointers to these images are stored, > your app must know each time the images are revised and can change the > way the images are served up at each checkpoint. You should not need > to do any client-side name changing if you have an active back end. > > As a rule of thumb, even apps that allow for some server-side image > editing are still read-mostly when it comes to the image binaries on > the server. That is, the files are still largely static. As such, they > should be served up in as cacheable a form as possible (with caching > headers far in the future and no forced revalidation), until the back > end notes that the binary has been changed and changes the image name > with a revision number: image.jpg?version=2. (Some people like to > instead give the image a unique name every time it is revised, such as > 023482132359.jpg, but that can be confusing for users if they ever > want to save the image out of the browser, and they know they uploaded > the image with a "friendlier" name.) > > --Sandy
