Join GitHub today
GitHub is home to over 20 million developers working together to host and review code, manage projects, and build software together.
unknown file extensions return binary mime-type. no file extension returns fallback mime-type #366
sorry, should have included that this pull request was in response to #316
my understanding was that "application/octet-stream" was being sent to the recipient as a catch-all for unknown file formats, although http://www.w3.org/Protocols/rfc2616/rfc2616-sec7.html#sec7.2.1 seems to imply that unknown should be sent without a content-type and allow the recipient to guess. when all else fails, the data should be treated as type "application/octet-stream" by the recipient.
reading the aforementioned conversation (#316), it seemed to me that the course of action was going to be removing mime-types set explicitly to "application/octet-stream", since they would be handled by the default. overriding the default is certainly possible, but i figured anyone doing so would have a good reason for it.
definitely a chance i misinterpreted that conversation. if so, could you clarify? i'm happy to fix and resubmit.
I really don't understand the specification:
That seems very wrong to me, the whole point of the fallback, is to fall back on. The idea of not setting a mime type when unknown is fair, and I'd be happy to consider that in some other places. It should be noted however, that the reason for defaulting to application/octet-stream is to get file download style behavior in browsers.
This comment has been minimized.
This comment has been minimized.
so i wrote this patch based on my understanding of the chneukirchen's comments here: #316 (comment)
my understanding was that fallback was intended to be used for a file w/o an extension, as opposed to an unknown extension. if the original intention in defaulting to 'application/octet-stream' was for file download, then not specifying a mime-type for unknown extensions does make more sense. the spec (http://www.w3.org/Protocols/rfc2616/rfc2616-sec7.html#sec7.2.1) also mentions that it's up to the recipient to determine how to treat an unknown type, saying only 'the recipient SHOULD treat it as type "application/octet-stream".'
in that case, i think the spec still makes sense--the fallback isn't used if the extension is unknown. it's only used if there is no extension. my thinking is that i'll update the code to return an empty string for unknown mime-types instead of the binary type.
thoughts? it seems to me that sending back a particular mime-type for unknown extensions is preventing the recipient from deciding how to handle it. my thinking is that if we don't know what something is, we tell the recipient the same.
anyway, i appreciate you taking the time to look
added a commit
this pull request
Mar 17, 2012
sounds reasonable to me. it looks like you've jumped on this issue with #367, although https://github.com/rack/rack/blob/c72121aa0fcaebc5e38365f50ea1f9be52cc3a06/test/spec_mime.rb#L10-13 looks like we are still returning 'application/octet-stream' for unknown. was your intention to return no content-type? or should i adjust this pull request to have Rack::Mime#mime_type return nil for unknown extensions?
i want to make sure i don't drop the ball on this if there's more i can do on my end.