No matter were I click or what I refresh, I see a brown+black cat under some LED lights, just that the picture is wrongly rotated with +90.
Open the large image into a new tab, then press Shift while clicking the Refresh button. This causes a force-reload. Just clicking Refresh reloads the image from your local cache.
Might be something else, now it's the wrong picture to my FF, too, with or without refresh, with or without shift click.
Nope, the exact same thing.
When you load anything over http or https protocol, the server can specify an
expiry time, telling the browser how long the resource should stay unchanged. For the above file, the forum serves such an Expires header a year in the future, and also a Last-Modified header describing when the resource was last modified.
When you click Reload/Refresh, the browser only checks its own local cache; at most, it can send a HEAD request, which provides only the headers and none of the file data.
Thing is, the headers did not change. They still reflect the original image file, claiming MIME type
image/jpeg and file name
IMG_20230316_110455672_HDR.jpg. The actual data, however, is of
image/png type, and not a JPEG file at all.
So, the browser just saw its cached data still valid, and re-showed the cached image. When you do a
force-reload, Shift+Reload, you tell the browser to skip the cache and header check, and do a GET request from the source (or proxy), which provided the new content.
Depending on your browser cache settings, when you closed that Firefox session (last open Firefox window), it discarded that cached image. So, when you next opened Firefox and tried to look at the image, Firefox dutifully did a GET request because it didn't have it cached anymore, and bang, you see the replaced image.
You can trust me on this, because I can tell you exactly what is happening and how, even though I have never had access to an SMF implementation (source code). It runs on Nginx, and the image/attachment provider part is written in PHP – the headers I receive with the above URL tell me that. The image/attachment metadata in the database is not corrupted –– it still exists for both the old image and the new image, only the old image binary data was replaced with the new image binary data; you can verify that by looking at the headers of both the old (now switched) image, and the image that replaced it. I am not sure whether the binary data is stored in the database or in binary files, so I cannot tell for sure whether it is the data itself or just the reference to the data that got changed for the old image, but I'd bet it is the reference; and the root bug is in the database query updating the binary data reference to the attachment after the upload completes. Instead of updating just the one entry, it ends up sometimes updating the reference also for an older image. Again, image metadata (format, file name) are
not similarly confused, so this must be a separate update.
(I do have a decade of commercial development experience in this stuff; I did it for years before switching back to academia, but still have kept up with the (rather small) changes since then.)
Home
Help
Search
Login
Register
