Forum Moderators: phranque

Message Too Old, No Replies

Application types cause problem

         

grandpa

4:47 pm on May 3, 2004 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member Top Contributors Of The Month



Yawn... I just got rolled out of the rack because my site was inaccessable. Sure enough, when I tried to browse my site what I got was a standard download prompt. That ain't right! So, I commented this line in my .htaccess for the application type: # AddType application/x-httpd-php .htm .html .php

Now the site works fine with this line commented out. It seems to me that sometime in the past couple of hours something on the server would have been changed to cause this sudden odd behaviour. We were alerted to the problem by a customer who was on-line, and had been on the site for 30 minutes, when it suddenly started mis-behaving.

Help?
The folks at my hosting company are clueless at this point. Besides what I usually tell them, is there anything that I might suggest to them, maybe something was done and should be undone?

<add>
Now that the crisis has passed, a look under the cover reveals that the host may have made changes, either to httpd.conf, or recompiled a version of PHP (currently Ver. 4.3.5) I wish I knew what version was running yesterday...
I've assumed either of these based only on my limited research for 'application/x-httpd-php' and have no way to verify either scenario.
</add>

grandpa

2:40 am on May 5, 2004 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member Top Contributors Of The Month



Today my web host has told me the only solution to this problem is to rename my htaccess file (esentially, to remove the file). Gotta love the service!

Can anyone offer a suggestion as to why this line forces my site to display a download box instead of a web page?

Here is the offending line:
AddType application/x-httpd-php .htm .html .php

The rest of my htaccess looks like this (without the ErrorDocument, RewriteCond or RewriteRules).

AuthName example.com
IndexIgnore .htaccess */.?* *~ *# */HEADER* */README* */_vti*
# AddType application/x-httpd-php .htm .html .php

(this statement is a single line)
DirectoryIndex index.html index.htm index.php php_value auto_prepend_file /home/mydomain/public_html/dir1/dir2/refer.php

<Limit GET POST>
order allow,deny
deny from xx.****.****.
allow from all
</Limit>
<Limit PUT DELETE>
order deny,allow
deny from all
</Limit>
<Files ~ "^.*$">
order allow,deny
allow from all
deny from env=ban
</Files>

gracias

jdMorgan

3:26 am on May 5, 2004 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member



I don't run php and I've never understood why anyone would want to tag the output of their php pages with a MIME-type of application/x-httpd-php. Since the script is run server-side, and produces a (presumably) HTML-compliant page as output, the proper MIME-type header would be text/html. This tells the browser how to interpret the characters it receives in the response message-body. So, 99% of the time it's going to be text/html or text/plain, I would think. It's possible I may be missing something, though.

I will theorize that someone long ago got confused between AddType and AddHandler, and posted his/her code, and it's been copied ever since.

So, not an answer, but another question... Is your problem really a problem? Hopefully, someone who knows can help us out.

Jim

grandpa

6:03 am on May 5, 2004 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member Top Contributors Of The Month



OK, so for the moment let topic digresses to php itself. As I recently read (just got the book), php does produce html (text/html) output. I questioned the use of application/x-httpd-php for a moment, but fell back into thinking, "But I haven't changed anything, that can't be the problem..."
That line would have been added when I first started toying with php. It is one the few lines in my htaccess that I don't have a comment for; I can tell you when and why everything else was added, but not that one - sigh. Still, it's been there since around February, so why does it wait until now to act up?

It's possible I may be missing something

Nope, probably not. I would theorize that I read about that MIME-type somewhere and thought it was necessary. The more I look into it though, the more that I see where it seems to cause more trouble than good.

Is your problem really a problem?

Well, ya. If the browser won't display my pages, and the user gets a download dialog box instead, that would be a problem. The line has come out of the file, so that takes care of the problem. Along the way I get a reminder about php that I'm not likely to forget soon.

Somewhere down the road I hope to discover what triggered that to start downloading instead of displaying. I still think something changed on the server, and the mime type started doing what it was supposed to do?.?

Is your problem really a problem

Not anymore.
I guess I just like to kick dead horses.

someone who knows can help us out

It would be interesting to hear from someone who is using this MIME-type.

gergoe

8:35 am on May 5, 2004 (gmt 0)

10+ Year Member



don't be confused with the two mime type (application/x-httpd-php and text/*). the first one is used to order the php module (module, because if you use the php in the "cgi mode", then you have to use the AddHandler directive in the apache config and you don't need the AddType anymore) to which files to be processed by the engine, while the second one (usually set by the php engine, so actually you don't have to care about it) is an instruction to the browser.

so the correct mime type on the server for the php files is the application/x-httpd-php, which you have to set in the apache config with the AddType directive, while the correct mime type for the (compiled) php files on the client side is the text/html (or text/plain or whatever the php file produces, can be image/jpeg also).

so what you've done by commenting the AddType line was that you turned off the processing of the php files, if the php was configured as a sapi module

jdMorgan

3:41 pm on May 5, 2004 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member



Again to clarify, I am questioning the use of AddType [httpd.apache.org], which adds MIME-type headers for use by the browser, instead of using AddHandler [httpd.apache.org], which is used to tell the server how to handle certain types of files.

Something must have changed on the server to break grandpa's site, and so my question is secondary, but may be important in determining the solution to his problem.

Jim

DrDoc

4:05 pm on May 5, 2004 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member



Here is what I personally use in my .htaccess file:
AddType application/x-httpd-php html

There is no need to specify php in there if it is already set up to be parsed by PHP, which it should be. The only difference I can tell between your Apache directive and mine is that I don't use the dot (.) before the file extension.

Try this in your .htaccess file:

AddType application/x-httpd-php html htm

jdMorgan

4:09 pm on May 5, 2004 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member



The Addtype documentation (link above) specifies that the file extensions are case-insensitive, and can be specified with or without a leading dot.

Jim

py9jmas

4:16 pm on May 5, 2004 (gmt 0)

10+ Year Member



From [php.net...]

15. Tell Apache to parse certain extensions as PHP. For example, let's have Apache parse the .php extension as PHP. You could have any extension(s) parse as PHP by simply adding more, with each separated by a space. We'll add .phtml to demonstrate.

AddType application/x-httpd-php .php .phtml

mod_php doesn't seem to set itself up as a handler but does things like this. Which I admit doesn't seem to make much sense.

Jon.

DrDoc

4:18 pm on May 5, 2004 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member



Normally you can use AddType to set the MIME type as interpreted by the browser. However, whenever it's an Apache module, the "application/" gets passed through the module first. The module may then (or may not) change the MIME type in the headers. PHP by default spits out text/html to the browser, which is why you don't get prompted to download it.

Is PHP configured to run as a module, or in CGI mode?

coopster

5:31 pm on May 5, 2004 (gmt 0)

WebmasterWorld Administrator 10+ Year Member



I will theorize that someone long ago got confused between AddType and AddHandler, and posted his/her code, and it's been copied ever since.

Actually, this direction has been set in the PHP Apache Installation [php.net] directions...


# For PHP 5 do something like this: 
LoadModule php5_module "c:/php/php5apache2.dll"
AddType application/x-httpd-php .php

If you search the

mime.types
file, you'll notice that there is no MIME-type listed for php. I believe that is why we are instructed to use an AddType [httpd.apache.org] directive in the
httpd.conf
file (or per-directory override files such as
.htaccess
if necessary).

Also, gergoe has made a decent argument here. Handlers [httpd.apache.org] can either be built into the server or included in a module, or they can be added with the Action [httpd.apache.org] directive. Since PHP is not one of the built-in handlers in the standard Apache distribution, it seems the PHP developers have created a module.

On a side note...
I have a server with PHP installed as a module and I tried to create a new

Action
directive (a few different ways, best attempt shown below) but it failed. I would guess it failed because, as gergoe stated,
Action
seems to be expecting something else, a cgi-script perhaps. Either way, the php pages will not get processed by the parser using an
AddHandler
and/or
Action
combination when PHP is installed as a module rather than cgi.


# WARNING: THIS DOES NOT WORK! 
LoadModule php5_module "c:/php/php5apache2.dll"
AddHandler php5_module .php
Action application/x-httpd-php php5_module

Also, as gergoe alluded, the output of the php pages actually don't get tagged with the MIME-type of

application/x-httpd-php
-- a requested php page is delivered with the MIME-type specified in the php script. If none has been specified in the script, I believe the reason the pages get delivered as expected (with the correct headers) is the
default_mimetype
configuration directive in the
php.ini
file.


php.ini 
; PHP's built-in default is text/html
default_mimetype = "text/html"

grandpa

8:44 pm on May 5, 2004 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member Top Contributors Of The Month



Is PHP configured to run as a module, or in CGI mode?

This is from my server information:
PHP 4.3.5 (cgi) (built: Apr 8 2004 16:22:53)

so what you've done by commenting the AddType line was that you turned off the processing of the php files, if the php was configured as a sapi module

Then by default, since my php files are being processed correctly without the AddType directive, php is not configured as a server api module. I'm not stating this as fact, its simply a deduction.

My understanding of the things discussed is weak, leaving me feeling vunerable right now. After I get caught up with some of my office tasks today I'll start researching everyones comments in detail. So far all I seem to understand is that there are some contradictory truths, and the key seems to be in how php is configured.

default_mimetype configuration directive in the php.ini file

It would be interesting to discover what is my servers php.ini file. I'm pretty sure I can't access that file on my host, and I doubt they will be willing to tell me, but it can't hurt to ask.

coopster

8:51 pm on May 5, 2004 (gmt 0)

WebmasterWorld Administrator 10+ Year Member



It would be interesting to discover what is my servers php.ini file.

phpinfo() [php.net] will give you that information.

grandpa

4:11 pm on May 7, 2004 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member Top Contributors Of The Month



Just a note to say thanks. I've got plenty to look at and try to understand. (Maybe I should start begging for a server, then I might get a better understanding of what goes into building php.) There's still no clear understanding of when, or when not to use the AddType directive. Next time the site acts up, I'll go switch it back in and see if that fixes the problem...