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

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

On Wed, 2012-08-29 at 09:28 +0200, Ondřej Surý wrote:
> With much cooler head and weekend after me and after carefull
> consideration of Chris's
> comments I have decided to go with:
Good =)

Some comments to your text :)

> php5 (5.4.4-7) unstable; urgency=low
>   * As a side effect of MIME-Type changes in the mime-support package, the
>     default Apache 2 configuration doesn't support MultiViews negotiation,
That reads like as if mod_negotiation itself was disabled per default in
Apache (Stefan, if you kept on reading: I'd absolutely support this ;-)
)... is this the case, OR do we just have the effect that is does (as it
should) no longer work for the files whose php files were removed?

> PHP 5 and Apache 2 Multiviews
> ----------------------------------------------------------------------
>  Apache 2 mod_negotiation's MultiViews needs php scripts to have a
>  MIME-Type to make the negotiation work.  We are using Apache 2 handlers
>  (SetHandler directive) to enable PHP processing, so by default the
>  MultiViews support is disabled in Debian packages.
Again, that reads a bit, as if negotiation was generally not
Perhaps if we write: "so by default the MultiViews support for PHP files
is disabled in Debian packages."

>   You can explicitly
>  add extra MIME-Types (different from magic application/x-httpd-* types)
>  which will not cause any special PHP processing,

[Optionally (but I don't insist), one could add something like the
following here:]
(unless another way than Debian's default way of enabling PHP is used)

[just as a warning...]
>  but just enable
>  MultiViews negotiation support.

>  Add these two lines to you Apache 2 config to enable MultiViews:
>    AddType application/x-php         php phtml php3
>    AddType application/x-php-source  phps
Correct :)
And actually... if it's really HTTP Negotiation that is desired (and not
tiding URLs from /foo.php to /foo) we MUST NOT use prevent the
file.php.foo issue, because we need to allow things like:
foo.php.en (e.g. returning English content)
foo.php.de (e.g. returning German content)

>  Also most likely what you really want would be better accomplished by
>  mod_rewrite rules where you can explicitly specify what gets
>  rewritten to what (e.g. http://localhost/file gets rewritten to
>  file.php, but not to file.html or file.js).
I, personally, would rather turn up that like this:
"If what you actually want, is to enable tidy URLs (e.g.
http://example.org/foo can be used instead of
http://example.org/foo.php) HTTP Content Negotiation is not what should
be used anyway.
That would be better accomplished by URL rewriting (via mod_rewrite)
rules where one can explicitly specify what gets rewritten as what.

> (e.g. http://localhost/file gets rewritten to
> file.php, but not to file.html or file.js).
That example contradicts IMHO a bit the intention that we suppose the
user to have:
We expect that he wants to get a file "/foo.php" be accessible via
"/foo", right?
So the user most likely doesn't have files "/foo.html" or "/foo.js" in
addition (which would then of course be negotiated, too - likely with
ambiguous results). Because auf this, a URL "/foo" should not get
"rewritten", because negotiation only happens (IIRC) when the "target"
file exists.

> <I would like to add text here with instructions how to enable
> mod_rewrite handling.>
I'll try to write you some mod_rewrite rules later; I'm just on the
train right now and I'll have to give lectures tomorrow, so not sure
when I find time.

Hope that helps,

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

Reply to: