PHP doesn't work without config in .htaccess

pure PHP coding needs parse HTML as PHP directive

[smallcompany]

I had some trouble with configuring HTML to be parsed as PHP as per this post:
[webmasterworld.com...]

As already stated, this happens on any server, any PHP configuration. I ended up with commenting this config out, so I can deal with bunch of 404s.

Today I checked on one of them, and found that my tracking stopped working. It works in the way that I have PHP.INI file from which I call a PHP script that writes some variables (like keywords and referrers)into a cookie.
The script is pure PHP coding. The way how I call the script from PHP.INI is this:
include_path = ".:/home/path/public_html"
auto_prepend_file = "/home/path/public_html/scripts/script.php"

Now, if the two lines below are presented in .htaccess, I get data written into a cookie, but if I comment them out, no data is written into a cookie:
AddHandler application/x-httpd-php5 .html .htm
AddType x-mapp-php5 .html .htm

Why would this affect how sole PHP works?

Thanks

[wildbest]

If PHP on your server is configured to run in CGI mode you might want to try something along those lines:

#
<IfModule mod_mime.c>
AddHandler x-httpd-php-cgi .php4
AddHandler x-httpd-php5-cgi .php .php5 .html .htm
</IfModule>
#

Please check mode_mime documentation for your specific Apache version.

[smallcompany]

This particular server is configured to run in CGI mode. But I have another one running in Apache mode, and it behaves in the same way.

My question at the first place is:
Why my PHP script does not put data into cookie if those lines are not presented in .htaccess?

Thanks

[coopster]

Still comes down to server configuration. AddType is not the appropriate way to handle the situation but AddHandler is ... depends on how the server has been configured. Sometimes AddType is *still* required, even in this day and age. It's an old carryover from waaaaaaaaaaaaayyyy back.

[smallcompany]

Thanks.

The way how it was explained to me was that since I have my script to be run from PHP.INI via auto_prepend_file command, the script would actually be called only when PHP.INI is called, which is when there's a request for PHP to run.

That's what puzzled me as why I found other PHP being run with no problem when calling PHP files directly while the actual script did not work (because it was only HTML being called).

Surely, with parsing HTML as PHP, the PHP.INI (read my script) would be called on every access to my website.

Going back to the core of my problem (which was nicely resolved by using AcceptPathInfo on servers where PHP was configured to run as Apache module), it turned that two different hosts that run PHP on their shared hosting as either CGI or CGI/FastCGI returned my support requests by saying that AcceptPathInfo was simply disabled on the servers for whatever purpose.
I still can't understand why they allow this to be, as it creates a real havoc if Google picks even a single link with trailing slash after ".html" extension. As all internal links from that single page become broken, it goes into perpetual mode which makes Google crawling "new" pages throughout the site which actually are all duplicated content.
So far only one of my sites has been hit by this problem and Google WMT is currently showing over 57K non-existing pages since I turned AcceptPathInfo OFF on that server.
This explained to me why all except home page of this site lost their PR some time in the past.
It was enough to get a link like page.html/ (even as a text) from some of those search scraper sites and Google took it wildly.

So far, since I need PHP.INI to run so that auto_prepend_file is read, it seems I can only do it with hosts that run PHP in Apache module.
Unfortunately, I'm not in a position to maintain my own server as either dedicated or VPS. Managed could be a solution, but for some of my sites I like to keep them on separate servers. I may reconsider this option so I can put the end to limitations of shared hosting which are not so bad as the limited support is.

[g1smd]

As all internal links from that single page become broken, it goes into perpetual mode which makes Google crawling "new" pages throughout the site which actually are all duplicated content.

You need to tighten up the patterns in your RewriteRules to avoid this happening.

The first thing the PHP script should do is evaluate whether this is a valid URL request. It should send a 404 header if not.

Additionally, link to other pages with a leading slash, including the full path.

[smallcompany]

Thanks.

It should send a 404 header if not.

It does now. The whole story here is that shared hosting configured as CGI or CGI/FastCGI (as far as I experienced with multiple hosts) opens this "slash" thing if parse HTML as PHP is used.
I learned that this is by design as many PHP sites configurations would use some kind of variables or session IDs in a form:
www.example.com/page/somethingadditional where somethingadditional is that trailing data, not the actual path.
Fine, but let me turn that off please.

Additionally, link to other pages with a leading slash, including the full path.

That has never been an issue. Just when trailing slash appears after file extension like .html because a search engine has picked it somewhere.

P.S.
So far, since I fixed this, Google has been adding thousands of 404s daily. This morning I'm at 64k.

[g1smd]

If this is

AcceptPathInfo

you're taking about, then yes it can cause a lot of issues. Prefer to completely avoid using it.

[smallcompany]

AcceptPathInfo

Actually with this turned OFF my trouble is solved and things are cleaner.
Are you talking about issues when having it ON or OFF?

But... in a meantime...

I continued playing with AddHandler and AddType directives in .htaccess. on the server where AcceptPathInfo had no effect. When searching throughout Webmaster World, a lot of times I came across Jim's (jdMorgan) claims that, i.e.

AddHandler application/x-httpd-php .html .htm
AddType x-mapp-php .html .htm

would not be the primary way of doing the parsing thing, but, i.e.

AddHandler server-parsed .html

depending on the specific problem discussed in those posts.

So I just tried this on the shared server that has PHP run as CGI/FastCGI:

AddType x-mapp-php5 .php .html .htm
AddHandler server-parsed .html

And the news for me was that now a request for page.html/ would return 404.
But, the IE9 would try to download the site if I request it as example.com (asks to save example_com).
All other pages with HTML extension work fine, and also all PHP stuff works fine.
Firefox and Chrome have no trouble at all.

Why is this?

Thanks