[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

On Tue, 2012-08-28 at 15:41 +0100, Ian Jackson wrote:
> > > You misread what I've said. text/javascript and text/ecmascript
> > > (which were used for execution -- this is what this RFC is about)
> > > are obsolete, but not text/plain.
> I think this is probably a mistake by the IETF.
Well, I doubt, but anyway... I guess than one would need to discuss with
them to correct it.

> Do you think then that the source code language (eg for syntax
> highlighting or whatever) should never be represented in a mime type ?
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.
The clients can then decide what to do, depending on fit's best for
them, or ask the user, or do the action the user has previously

In the specific example of interpretable scripts, it's of course
reasonable to not set the default action to execute it (for security
But that's not something the server should tell (by the MIME-type),...
it cannot know what the client/user really wants... and it would be
insecure to trust any remote server to make the right choice.

> > Yeah,.. could... but... I think adding a x- type for widespread use
> > should always be the last solution, sooner or later these may cause
> > troubles.
> I don't agree with this.
Well... x- types were never intended to be used in production.

- They always bear the risk, that they're ambiguous, Microsoft defined
it to be xyz, Adobe defined it to be zxy.

- Once you've defined (and used) them widely, you cannot easily get rid
of them. The application/x-httpd-* case is an example, as well as
several types for which previously an x-type existed but now a real
definition was made.
Both continue to be used and for both code has to be maintained.

- People often "defined" x-types without really knowing what they do.
There are types for bzip2 or gzip floating around (luckily not in
Debian's mime-support) which are however not types, but encodings.

- And x-type gives you no guarantee at all, that anyone else agrees with
it or even supports it. Of course the same is true with official types,
but there one at least has kind of a "strong" argument, that 3rd parties
should support them, which you don't have IMHO with x-types.

> In the latter case we need to teach _all_ user agents to display
> application/javascript rather than do something else with it.
Yeah,... but what else? I mean user agents that unconditionally try to
execute/interpret application/* content are seriously flawed...

> 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.

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.

Of course you can argue that we can't to this for proprietary crap,...
but why should we mess up our systems to make their crap work out of the
I just suffered (few minutes ago) again from an issue in Outlook, that
it cannot display S/MIME signed (not encrypted) mails if it doesn't know
the key... it does not just warn, it really cannot display it.
Now should I change my working and correct setup just to please any big
company like Dell which uses Outlook?

And if a server admin really needs to do this,... he can always manually
add such types,... but IMHO there's no need to "poison" all users with
them ;)

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 :)


Attachment: smime.p7s
Description: S/MIME cryptographic signature

Reply to: