Last modified: 2014-10-27 22:00:53 UTC
Content hash based URLs for media files and thumbnails have some advantages over the current pretty names: * automatic cache busting * consistency of HTML revisions and media referenced in it, in particular in old revisions (important for HTML storage and Parsoid) * natural content-based deduplication * content-based image blocking (bad image lists etc) * media renames don't trigger HTML updates * simplifies a potential migration of all media content to commons There are also some disadvantages: * need to use Content-disposition header to suggest pretty name for image saving * need to think about quick image purging for copyvio cases, as cache busting is not enough there The details of what we'd need to do for this should probably be fleshed out on-wiki. For now I'm dropping this note here as a reminder and short summary.
By content-based thumbnail URL do you mean the URL is based on the content of the thumbnail, or on the content of the original file? None of the advantages seem to apply to the former, it makes quick purging even harder, and makes it impossible to guess the URL needed for resizing the image (which can be used for some fairly significant speed improvements).
We already have support for content disposition headers on files (for swift backend anyways). I imagine we could still use htcp for quick purging. There are very definite advantages here related to caching. Among other things, It would also let us set more aggresive cache headers for the client. File moving would also become much "better". I believe there is already a bug for this, but cant find it.
(In reply to Bawolff (Brian Wolff) from comment #2) > I believe there is already a bug for this, but cant find it. Bug 44428 comment 0?
(In reply to Tisza Gergő from comment #1) > By content-based thumbnail URL do you mean the URL is based on the content > of the thumbnail, or on the content of the original file? Definitely the latter. Example: <sha1 of orig>-300.jpg
