[php-maint] Bug#670945: About the media types text/x-php and text/x-php-source

Sun Aug 26 17:49:28 UTC 2012

Hey Charles, Ondřej, et all.

On Sat, 2012-08-25 at 10:41 +0900, Charles Plessy wrote:
Le Sat, Aug 25, 2012 at 12:46:33AM +0000, Christoph Anton Mitterer a
écrit :
> > 
> > Maybe the mime-support maintainer(s) can set these as goals for
> > jessie :)
> > Syncing with IANA and cleaning up unofficial definitions. :)
> 
> Sorry to be in bad mood, but I do not think that I need more reminders
> to keep
> the package up to date after the freeze.
Hey Charles.... that was just my way to express that I agree, that it's
better if we don't mess around with such larger goals now in wheezy.

:)

On Sat, 2012-08-25 at 08:42 +0200, Ondřej Surý wrote:
> * The fix for first bug #674089 (e.g. with impact on PHP CGI) is still
> in the place in the php5 package (5.4.4-5).
Ok, AFAIU that one is fixed by now, as we put info into PHP's NEWS file,
the release notes, and as we even have no the Apache config file for PHP
CGI.

> * The fix for second bug #670945 (e.g. http://localhost/file not
> caught by mod_negotiation) was fixed in mime-support 3.52-1.1.
I personally do possibly not quite understand the current state here:
AFAIU, the user used HTTP negotiation to get file.php when file was
requested, right?

1) As I wrote in some mail before, I personally would drop that this
works out of the box.
Why?
It seems to be a abuse of what negotiation is intended for, and this is
definitely not to get "tidy" addresses (i.e. without .php).
If people want the later, mod_rewrite is their friend.
HTTP negotiation is intended that the browsers can set preferences in
the HTTP headers, and content is chosen based on that.
But in the above case, the content is not "PHP",... the PHP generates
(e.g.) HTML,... and THAT is the content that the browser will see.
Also, no browser sends per default a preference on a x-php type.

The whole scenario would only make sense if there was e.g.
file.js
file.php
and the intention was to give browsers the choice what should happen,
when just "file" is accessed... server-side interpretation of PHP, or
client-site JavaScript.

I've never seen anyone using that.
So honestly, I'd simply drop support for that, and add perhaps a note to
NEWS.

Or is there some other non-abusive way of HTTP-negotiation in the whole
scenario reported by the bug, I haven't seen?

What now if my proposal ("drop that this works out of the box") is too
late for wheezy (i.e. maybe there are really packages in Debian who use
it that way - which would be really really bad):

2) EITHER: We add a new mime-type as Ondrej suggested.
Side-effects? Does this perhaps re-introduce the foo.php.jpeg issue? No
I don't think so; Ondrey uses <FileMatch> and then he uses handlers
(SetHandler .... so not even MimeTypes)... and even if he'd use MIME
types... he uses the special ones "application/x-httpd-*"...
So a new entry for php files in /etc/mime.types introduces likely no new
security issues.

Should we do it?
I agree here with Charles, when adding new x-* types we should try to be
as conservative as possible, because x-* types were always intended to
be used within "organisational boundaries" only (so e.g. just within the
authority of a company).

I agree with Ondrej, that we should however not decide, based on what
other distros to (of course we can look at it, whether it's reasonable).

OR: We add even the definitions to PHP's Apache config files.
Problem: This affects only Apache... OTOH; did the other webservers
use /etc/mime.types ?

Concluding I tend to the following (in decreasing order):
1) Drop (out-of-the-box) support for what's asked in #670945 comment 1.
It's abusive and an easy start for people to shoot themselves into their
feet (security wise).
Add notes to NEWS and perhaps release notes on how to work around.

If not possible:
2) Add the MIME-Types definitions to PHP, if only Apache used this ever.
Why? Eventually we should definitely do (1), and add these types (at
least for what's asked in #670945 comment 1) only as a workaround for
now.
So if we drop them anyway, there's no need to add them to mime-support,
where they're used at an unnecessarily broader ranger.

If other web-servers used that, too:
3) Put it for now (!) in mime-types.

I think it would be ok to do (1) even in wheezy.
Why? Eventually the clean solution would be anyway to drop what's asked
in #670945 comment 1.
Users will then have to read NEWS/release notes and clean up their
setups.
Whether this happens now, or in jessie.... is IMHO irrelevant.

Cheers,
Chris.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5450 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-php-maint/attachments/20120826/25715d1d/attachment.bin>