3 ms·

Can I start serving .html files as .awesome files? Sure, go ahead. Extensions in a URL have little to do with the actual type of content, and .html has long be

by personZ 12y ago

Can I start serving .html files as .awesome files? Sure, go ahead. Extensions in a URL have little to do with the actual type of content, and .html has long been abandoned by dynamic systems, who originally went to extensions being an implementation detail, and on many current systems being a lie (e.g. the .aspx extension that actually runs a PHP page that returns an HTML5 file). They're using a URL extension to signal to their system what to do with the file, which in the case of GIFV is to wrap an MP4 video in a simple HTML5 container. Eh.

Supermighty 12y ago
I can't upvote you enough. Too few people realize that the server returned mimetype actually tells the browser how to handle the content.
- Terretta 12y ago
  Oh how I wish that were true. It's what's intended, but it's not what's true. Usually this bites on video, but it even bites on, say, SVG: http://stackoverflow.com/questions/10261460/internet-explorer-ignoring-mime-type http://stackoverflow.com/questions/10261460/internet-explore... Ostensibly, this is to protect users. Quoting TechNet: When files are served to the client, Internet Explorer uses the following pieces of information to decide how to handle the file: 1. File name extension, the corresponding ProgID and CLSID for the registered handler of that file name extension. 2. Content-Type from the HTTP header (MIME type), the corresponding ProgID, and CLSID for the registered handler of that Content or MIME type. 3. Content-Disposition from the HTTP header. 4. Results of the MIME sniff. -- http://technet.microsoft.com/en-us/library/cc787872(v=ws.10).aspx http://technet.microsoft.com/en-us/library/cc787872(v=ws.10)...
  - simoncion 12y ago
    If IE chooses to use file extension over MIME type, then it is broken and should be ignored. Yes, I'm aware that this is probably a workaround for broken web servers, or brain-dead server admins. This workaround should never have been deployed, as it breaks interactions with non-broken web servers.
    - Arnavion 12y ago
      It's not just IE that plays loose like this. Chrome will ignore even the Content-Type header if it can see the content is an audio or video file. For example, upload a .wav to puush and open it in FF and Chrome. FF will show a dump of the bytes interpreted as text because the server sent it with Content-Type: text/plain. Chrome will show an <audio> element. You can't call either browser broken here. One is doing what the spec says is correct. The other is doing what the user says is correct.
halostatue 12y ago
I could see them recommend that “GIFV” be standardized as video/gifv+mp4 (and it wouldn’t need standardization if it provided it as video/vnd.imgur.gifv+mp4), which would provide the necessary signals in a fairly standards-compliant way, as well as a clear indication that mp4 is the fallback.
- wbond 12y ago
  I believe that vnd. mimetypes do need to be registered. If you don't want to register, I think it would be video/x-gifv+mp4. http://tools.ietf.org/html/rfc2045#page-13 http://tools.ietf.org/html/rfc2045#page-13

by personZ 12y ago

Supermighty 12y ago

I can't upvote you enough. Too few people realize that the server returned mimetype actually tells the browser how to handle the content.

Terretta 12y ago
Oh how I wish that were true. It's what's intended, but it's not what's true. Usually this bites on video, but it even bites on, say, SVG: http://stackoverflow.com/questions/10261460/internet-explorer-ignoring-mime-type http://stackoverflow.com/questions/10261460/internet-explore... Ostensibly, this is to protect users. Quoting TechNet: When files are served to the client, Internet Explorer uses the following pieces of information to decide how to handle the file: 1. File name extension, the corresponding ProgID and CLSID for the registered handler of that file name extension. 2. Content-Type from the HTTP header (MIME type), the corresponding ProgID, and CLSID for the registered handler of that Content or MIME type. 3. Content-Disposition from the HTTP header. 4. Results of the MIME sniff. -- http://technet.microsoft.com/en-us/library/cc787872(v=ws.10).aspx http://technet.microsoft.com/en-us/library/cc787872(v=ws.10)...
- simoncion 12y ago
  If IE chooses to use file extension over MIME type, then it is broken and should be ignored. Yes, I'm aware that this is probably a workaround for broken web servers, or brain-dead server admins. This workaround should never have been deployed, as it breaks interactions with non-broken web servers.
  - Arnavion 12y ago
    It's not just IE that plays loose like this. Chrome will ignore even the Content-Type header if it can see the content is an audio or video file. For example, upload a .wav to puush and open it in FF and Chrome. FF will show a dump of the bytes interpreted as text because the server sent it with Content-Type: text/plain. Chrome will show an <audio> element. You can't call either browser broken here. One is doing what the spec says is correct. The other is doing what the user says is correct.

halostatue 12y ago

I could see them recommend that “GIFV” be standardized as video/gifv+mp4 (and it wouldn’t need standardization if it provided it as video/vnd.imgur.gifv+mp4), which would provide the necessary signals in a fairly standards-compliant way, as well as a clear indication that mp4 is the fallback.

wbond 12y ago
I believe that vnd. mimetypes do need to be registered. If you don't want to register, I think it would be video/x-gifv+mp4. http://tools.ietf.org/html/rfc2045#page-13 http://tools.ietf.org/html/rfc2045#page-13