https://bugzilla.wikimedia.org/show_bug.cgi?id=64554
--- Comment #18 from Tisza Gergő <[email protected]> --- (In reply to Laurence 'GreenReaper' Parry from comment #16) > I can confirm, the default $wgMediaViewerUseThumbnailGuessing = true doesn't > always work right if you don't have a 404 handler set up. Here's why: large > sites probably *do* have caching set up (e.g. CloudFlare or Varnish), and > the 404 will be cached, so the request after generation gets the cached 404. > Whoops. This hurts everyone else who tries to access the cached file while > the 404 is cached. Indeed, we ran into the same issue on Labs Beta recently (bug 67056). > You could try adding no-cache headers to your second request; or if that is > not possible, add a query parameter to the URL based on, say, the timestamp > to break the cache for your backup request. Adding no-cache would defeat the point of thumbnail guessing, which is to shave off a few hundred milliseconds from the image loading time. (Plus, it would split frontend caches and increase their disk space usage significantly.) It's better to disable it by default then. (In reply to Laurence 'GreenReaper' Parry from comment #17) > Also, Firefox is showing your two requests for the same image coming > immediately in succession, with the call to imageinfo coming *after* both > requests. In this situation, it will never work on the first view, even if > caching is not an issue or you use cache-busting techniques. It needs to > render the thumb first. That's... complicated. We send an AJAX request for the image first, to get progress events and cache hit stats, fall back to a normal resource request if that doesn't work (due to crossorigin limitations, typically), fall back to imageinfo if even that doesn't work and send another request after the API call has finished. There should probably be a flag to disable AJAX loading; it can be a problem with some setups, as in bug 62469 -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
