I've written a pretty small patch to make fossil serve files with extension
"mp4" as "video/mp4". This in accordance with RFC 4337[1].

The RFC says:

1. if neither audio nor video, use application/mp4
2. for every other file, use video/mp4.
3. if only audio, you *may* use audio/mp4, but video/mp4 is still fine

Of course, it's impossible to guess intent from just the extension,
although I'm guessing the vast, vast majority of mp4 files are being used
to serve video and/or audio, in which case video/mp4 is the appropriate
type to serve it with. Either way, that's an upgrade over the current
behavior, which, according to curl -I at least, is sending:

Content-Type: application/x-fossil-artifact; charset=utf-8

There was some extra whitespace at the end of some lines. My editor
helpfully (?) removed it. If you'd like it back, I'll happily provide the
same patch without the end-of-line whitespace removal.

The reason I wanted this is because I am using fossil to source-control a
talk I hope to give at PyCon 2014. In this talk, I have some screencasts to
replace live demos. Those screencasts are MP4 (h264 + AAC, or h264 without
an audio track) because of browser support. Currently, all browsers want to
download this file with a "Save as" dialog because they don't recognize the
file type. After the patch, the video just plays, in all browsers that know
how to do so.

This is my first patch to fossil, so apologies if I messed something up...
I don't know if there's a preferred way to send patches in, but this is
just the output of "fossil diff". patch -p0 < mp4.patch seems to work fine
for applying it :)

Patch is against latest trunk at time of writing. It's pretty simple, so I
expect it to apply cleanly to a whole lot of revisions...

checkout:     a6dad6508c0e95bd0aceb28fec1a269114917ac5 2013-06-14 07:19:58

thanks in advance :)

[1]: https://tools.ietf.org/html/rfc4337#section-2
fossil-users mailing list

Reply via email to