[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: About the media types text/x-php and text/x-php-source

Christoph Anton Mitterer writes ("Re: About the media types text/x-php and text/x-php-source"):
> I think it already is when you use e.g. application/javascript.
> And I think, that MIME types are intended to hint the client of what
> kind content is, but not what to do with it.

I think that's a meaningless distinction.  The purpose of the MIME
type is to ensure that the client behaves correctly.

> > In the
> > former case we only need to teach anything to those user agents for
> > which text/we think a prettier display than that available for
> > text/plain is desirable.
> Well at least for the cases I know (but these are surely not all),... it
> works already fine as it is... either they understand that e.g.
> application/javascript is to be displayed as text in editor (e.g. with
> syntax highlighting)... or in case of text/plain,.. they try anyway to
> automagically determine the correct highlighting.

I have frequently encountered problems viewing various kinds of code
when the web server quoted an application/x-blah-source-code content
type.  If the web server quotes text/x-blah-source-code then at least
there's a hope of success.

> Even if we'd need to fix any client... we're in the open source world,
> arent't we? In most cases it's just a one liner to tell an user agent
> that it should connect type application/foo with e.g. editor bar.

You seem to be living in a world where all the software you are using
is all from exactly the same time and there are never any transitional
arrangements are needed, and where there is unlimited effort for
updating client software for obscure new content types.

That's not the real world.

> Anyway... I guess the whole discussion went highly off topic, didn't it?
> The question is what should be done for text/x-php and text/x-php-source
> and from my side I've already said mostly everything what I'd do and
> that I think using mod_negotiation for "tidy" URLs is an abuse an
> shouldn't be supported :)

*.php files should be recognised as text/x-php or text/x-php-source by
our mime types file.

If Apache (or some other webserver) wants to automatically execute
*.php files (whether the url referring to foo.php is is
http://example.com/foo.php or http://example.com/foo) then that should
be achieved by webserver configuration, and should not involve any
changes to the filename-based mime type recognition system used for
the rest of the system (eg mutt).

I don't have an opinion about how the webserver config should be done,
except that it should be done in a way that won't result in files
being executed contrary to the intention of the administrator.


Reply to: