mod_negotiation and PHP

[Stephen van Egmond <sv...@tinyplanet.ca>]

I've been looking through mod_negotiation.c to resolve a problem
I have with PHP and Google.

The issue is that Google sends 
	Accept: text/html,text/plain

And Apache, configured with PHP as a module, is unable to negotiate a
satisfactory mime type since PHP is registered under
application/x-httpd-php rather than the text/html it typically serves,
then serves a 406 to google.

Now here's where I start guessing.

Currently mod_negotiation.c uses a pseudo_html flag to treat two mime
types (text/x-server-parsed-html[3] as if they were text/html.
Theoretically, if I bash PHP's signature into there, it should work,
right?

(I say theoretically, because I've done it, and it didn't work. Or at
 least I'm pretty sure I've done it - the .deb source is tricky.)

-Steve

Re: mod_negotiation and PHP

[Stephen van Egmond <sv...@tinyplanet.ca>]

Glenn (gs-apache-dev@gluelogic.com) wrote:
> # (unset mime-types will use the DefaultType, which defaults
> #  to text/plain on a standard Apache installation)
> RemoveType .php
> 
> # or you can specify a mime-type as
> #AddType text/html .php
> 
> # Tell Apache that mod_php is the handler for .php
> AddHandler php-script .php

This unfortunately still results in the same behaviour,
I believe (from the source) because the php-script handler
is still committed to producing application/x-httpd-php 
content.

Odd thing: I re-did my modifications to the Apache source, and this
time it works.  The PHP handler's mime type is now promoted to text/html
for the purposes of content negotiation.   I discovered that modifying
includes/httpd.h this way:

#define INCLUDES_MAGIC_TYPE3 "text/x-server-parsed-html"
#define INCLUDES_MAGIC_TYPE "application/x-httpd-php"

works, whereas swapping them:

#define INCLUDES_MAGIC_TYPE "text/x-server-parsed-html"
#define INCLUDES_MAGIC_TYPE3 "application/x-httpd-php"

does not.  From what I can see, mod_negotiation tries to treat
them identically thoughout.  So perhaps there is something being
dropped there.

I realize that PHP isn't a standard apache module, and adding
standard infrastructure to do this kind of quackery would probably
be difficult (as the patches would have to go into both Apache and
PHP).  I'm  content to just let the mailing list archives of the world
record this hack/solution, and move on.

Thank you for all your help.

Re: mod_negotiation and PHP

[Glenn <gs...@gluelogic.com>]

On Sat, Feb 01, 2003 at 09:49:01AM -0500, Stephen van Egmond wrote:
> Ack.  I didn't make it clear that I was working 1.3.26. 

# (unset mime-types will use the DefaultType, which defaults
#  to text/plain on a standard Apache installation)
RemoveType .php

# or you can specify a mime-type as
#AddType text/html .php

# Tell Apache that mod_php is the handler for .php
AddHandler php-script .php

-Glenn

At 11:49 PM 1/31/2003, Stephen van Egmond wrote:
>I've been looking through mod_negotiation.c to resolve a problem
>I have with PHP and Google.
>
>The issue is that Google sends
>        Accept: text/html,text/plain
>
>And Apache, configured with PHP as a module, is unable to negotiate a
>satisfactory mime type since PHP is registered under
>application/x-httpd-php rather than the text/html it typically serves,
>then serves a 406 to google.
>
>Now here's where I start guessing.
>
>Currently mod_negotiation.c uses a pseudo_html flag to treat two mime
>types (text/x-server-parsed-html[3] as if they were text/html.
>Theoretically, if I bash PHP's signature into there, it should work,
>right?
>
>(I say theoretically, because I've done it, and it didn't work. Or at
> least I'm pretty sure I've done it - the .deb source is tricky.)
>
>-Steve

Re: mod_negotiation and PHP

[Stephen van Egmond <sv...@tinyplanet.ca>]

Ack.  I didn't make it clear that I was working 1.3.26. 

William A. Rowe, Jr. (wrowe@rowe-clan.net) wrote:
> You might try using the AddOutputFilter instead of the antique methods

I tried to find AddOutputFilter, and couldn't, because it's only available
in Apache 2.  There's a number of dire warnings splattered around the 
PHP site about not using Apache 2 and PHP, and I've been heeding them.

"Do not use Apache 2.0 and PHP in a production environment neither on Unix nor
on Windows."
- http://www.php.net/manual/en/install.apache2.php

And this is most certainly a production system.

> Just some random observations...

Thank you for the help.

Re: mod_negotiation and PHP

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

This is because, conceptually, foo.php doesn't have any information to
distinguish that the results of running foo.php are html.

You might try using the AddOutputFilter instead of the antique methods
of associating application/x-httpd-php - because that 'content-type' is
meaningless to the outside world.  This is why Apache allows you to
associate filters by extension without creating ByType associations for
content filters.  One alternative, if that doesn't work well for you, is to
use a wildcard <Files "*.php"> section with a SetOutputFilter directive.

So - adding the PHP output filter by .php would solve that problem - your
next problem is associating php with html.  Two options;

One, name your file foo.html.php.  Or you can do the SSI thing, with a
filetype .phtml (like .shtml).  Or you can simply declare that .php is
text/html, which I'm guessing 99% of your PHP scripts create.

Just some random observations...

Bill



At 11:49 PM 1/31/2003, Stephen van Egmond wrote:
>I've been looking through mod_negotiation.c to resolve a problem
>I have with PHP and Google.
>
>The issue is that Google sends 
>        Accept: text/html,text/plain
>
>And Apache, configured with PHP as a module, is unable to negotiate a
>satisfactory mime type since PHP is registered under
>application/x-httpd-php rather than the text/html it typically serves,
>then serves a 406 to google.
>
>Now here's where I start guessing.
>
>Currently mod_negotiation.c uses a pseudo_html flag to treat two mime
>types (text/x-server-parsed-html[3] as if they were text/html.
>Theoretically, if I bash PHP's signature into there, it should work,
>right?
>
>(I say theoretically, because I've done it, and it didn't work. Or at
> least I'm pretty sure I've done it - the .deb source is tricky.)
>
>-Steve