Re: mime types and file extensions (was Re: Puzzling...)

"Mark Hubbart" <[e-mail]> schrieb im Newsbeitrag
news:[e-mail]...
>
> On Feb 22, 2004, at 7:25 PM, Trey Campbell wrote:
>
> > Trying it with the following:
> >
> > #!C:/ruby/bin/ruby.exe
> > print "Content-type: text/plain\n\n"
> > print  "1st line "
> > print  "2nd line "
> > print  "3rd line "
> >
> > Mozilla renders the page (as if it encountered a <pre> tag). IE shows
> > a dialog offering to run the associated application (but warning that
> > it might not be a good idea to do so). I wouldn't characterize that as
> > misbehaving since that's what I'd expect it to do, or at least offer
> > to do; it's just doing a better job of recognizing potential helper
> > applications than Mozilla is.
>
> The mime type is there for a reason. When a file is downloaded, the
> browser is supposed to look at the mime type to figure out what to do.
> If the mime-type is "image/jpeg", that means it's jpeg image, despite
> the fact that it's filename might be "graph.rb" (if it happens to be a
> dynamically created image).

Correct so far.

> A mime type of "text/plain" indicates a
> simple plaintext file, which should be rendered on the screen.

I don't subscibe to your relative clause: the fact that data is tagged as
plaintext does not mean it has to be rendered on the screen, especially does
it not mean that the browser should do it.  What happens to a file is
totally client (i.e. browser) dependent, so it might or might not decide to
display it itself or delegate handling to some other entity.  How this
entity is found (via a browser internal mapping or via some OS mechanism) is
again browser and system dependent.

Pragmatically one would expect a text/plain file to appear on the screen,
probably in a browser window or in some text editor.  But it might as well
be saved to disk or whatever, depending on the user's configuration.

> The
> browser should NOT try to execute it. If it should be executed, it
> should have a mime type of, I don't know, "executable/ruby" or
> something.

Well, it need not be named "executable", because there is no inherent
semantics in mime type.  The configuration determines what to do with it.
You could as well configure emacs as handler for a Ruby script.

> If the browser can't recognize the mime type, *then* it
> should feel free to try to figure it out.

Agreed, the mime type should definitely take precedence.

> A windows pc determines filetypes based on the extension,

AFAIK this is not fully correct: I believe that current Windows version are
also capable to identify a file's type via other mechanisms; I believe you
can write handlers and register them with the system that look into files
and determines type etc.  Maybe someone with a bit more Windows insight than
me can comment / correct me.

> a mac
> primarily uses the creatorcode and typecode metadata, a unix box uses
> (mostly, i think) magic numbers. All Things Web are supposed to use
> mime types as a bridge. This is to ensure that things like, say, a
> plaintext file, don't get interpreted as, say, an executable ruby
> script.

Yep.

> um.... okay. I'll stop my "standards rant" now.
:-)

The crucial point with MIME is, that the standard defines a format for
naming file types and a mechanism to register well known types.  But it does
not fix what to do with these files.

Kind regards

    robert