6 ms·

Neat. Though for my own sanity, I'd probably use a file extension like .image for URLs that return different content type based on the Accept header. (And leave

• jdorfman 14y ago
  @bajsejohannes that is actually a great idea.
• celoyd 14y ago
  In URLs, and especially user-visible URLs, file suffixes at all should be considered an only occasionally necessary evil. They’re ugly, redundant, brittle, and generally a headache. TBL wrote about this in 1998: http://www.w3.org/Provider/Style/URI.html#remove http://www.w3.org/Provider/Style/URI.html#remove
  • derefr 14y ago
    Though probably do transmit a "Content-Disposition: inline; filename=foo.jpg" header. Otherwise, the OSes that infer media type from extension will get confused when the user goes to save the file and it appears extensionless. (That might be called a browser bug, actually; it'd sure be nice if browsers on these OSes could take the observed media type and tack on an extension to extensionless files on Save As to ensure they'll be viewed by the OS to have that same media type. Or it might be called an OS bug: why the heck don't filesystems have a required media-type metadata field for files yet!? ;)
    • artificialidiot 14y ago
      it is neither the OS' nor browsers responsibility to launch correct application for a file. There are launchers that examine file headers (no need to dup it on filesystem) and keep track of your application preferences for a given mime type. They may be called file manager, shell or something similar and responsibility lies there. 8.3 file naming is a historical baggage and nothing more.