https://bugzilla.wikimedia.org/show_bug.cgi?id=42133
--- Comment #1 from Faidon Liambotis <[email protected]> 2012-11-15 03:03:28 UTC --- Interesting corner case. So what happens is: The request comes from the caching layer to Swift; from there, our rewrite handler in the pipeline tries to fetch it from Swift itself, and if that 404s, then it forwards it to imagescalers/MediaWiki. However, since in this case the container doesn't exist, Swift defaults to 401, presumably for security reasons: attackers should not get 404 for missing containers, as this would allow them to brute force container names until they get a 401 (information disclosure). So the request never gets passed on to imagescalers, and imagescalers never create the containers, so we're essentially deadlocked. I'm reluctant to also forward 401s to imagescalers. The only solution I can see -other than creating them by hand in the rare cases we add wikis- would be for MediaWiki to be even more smart and create thumb containers when originals are made. I know very little of MediaWiki's Swift architecture though, so I can't speak for the feasibility of this. I created the en.wv container by hand and it seems to work now; I didn't do the same for the other languages though, in case Aaron or someone else wants to test things. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email ------- 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
