On Tue, Jul 28, 2015 at 3:57 PM, Brian Gerstle <bgerstle@wikimedia.org> wrote:

I guess the "thumb/6/6e" part isn't standard either.

It's always there as far as I know, but it's not standard in the sense that there is no promise of stability. Someone might at some point decide we should use a faster hash function or we have too many images and need three levels of depth or something else altogether... File names might go away soon as well as there are some experiments with using content hash based URLs so that cache invalidation becomes simpler.

So if you want to freeze elements of the current URL structure that should be a wider discussion involving ops and other folks working on media features. You can of course just use it at your own risk, for a JS component that would be no big deal as URL schemas don't change often; not sure how quickly app updates can be pushed out though.

 

If we could just get the thumbnail server to return the original image when we go too large we'd be set. 

Fragmenting the cache would be problematic (if it comes to that, it's still better to fragment the HTML cache by appending an image size parameter since HTML content is smaller). I think something like T75935 could work but AIUI the whole media cache infrastructure is held together with duct tape and no one is particularly enthusiastic to poke at it.

We could always request it anyway and fall back manually in case of 400 response (probably won't happen _too_ often).

MediaViewer does that (it also embeds the original size in the article HTML and uses that to guess the right URL); it mostly works but still comes with minor issues such as T70320 or strange errors on the beta cluster which has minor differences in thumbnail behavior.