Tels wrote: Please read Brion's original message again. Serving static content usually amounts to just pushing bits, and that's all it should be. If you want it to be more than that, you need to call into a language that will supply an additional layer of logic before you can start pushing bits, which is usually enormously slower than being able to say "here's a link to a static file". You can serve the latter with all sorts of optimizations -- one example being in-kernel httpd, or one of the very fast userland ones. -- Ivan Krstic <krstic(a)fas.harvard.edu> | 0x147C722D

Various people wrote: [I've picked this response just because it's the most recent, various people have been making similar points.] The question that occurs to me is, quite simply, why do humans ever *need* to know or manipulate such URIs? * anyone wanting to "bookmark" a particular image will want to link to its description page (to show copyright info, possible replacements, etc); if that's not the case, we need to redesign our image description pages (this may be the case w.r.t. Commons). * anyone *saving* the image ("downloading" it, as they would describe it) would only see the *filename* part (as the default name); as long as we tack on the "friendly name" at the end (even just to ignore) the rest of the URI can be anything at all * anyone wanting to include an image *inline* in an external site is abusing our bandwidth (either maliciously or just through naivety) * somebody mentionned bot authors; but what purpose do bot authors have with the absolute URI of an image? Creating a static dump by screen-scraping rather than parsing the wikitext dump? * a user-side renderer (e.g. WikiWyg, Pilaf's Live Preview) might need to know them to render fully, I suppose; like distinguishing "red" and "blue" internal links, this could ideally be done through some minimal "API", question and answer style In short, I don't see any need for making these URIs "pretty", or even providing a Special page that redirects, except as a [bad] substitute for a "bot API" that allows you to request the current full URI. I *do*, however, see some very good reasons for tacking a pretty *filename* on as the last part, even if it's actually ignored (e.g. for "save as", as mentionned above). Actually, we might want to do more than just ignore the pretty name, because (esp. knowing IE) it rmight be dangerous if http://..../abc123/Puppy.jpeg and http://..../abc123/Puppy.txt are valid URIs for the same file. To keep things static, we don't really want to check this explicitly, but perhaps the "pretty bits" could actually exist on the filesystem, as symlinks or such: http://.../abc123/abc123 [actual content] http://..../abc123/Puppy.jpeg [symlink to above] http://..../abc123/JSC0123.jpg [symlink to above; old or alternative name] http://..../abc123/Haxx0r.txt [no symlink here, so returns HTTP 404] -- Rowan Collins BSc [IMSoP]