I made an .htaccess file to allow my .html files to be parsed for
any php on them. It has:

AddType application/x-httpd-php .html

It did not work on one server (a university server that is Apache
and Unix and all that good old stuff, nothing Windows or funny
stuff). Before I contact server admin, any other ways to
accomplish getting a .html file to be so parsed? If I name my
files .php on this particular server, all work fine. I can put
the .htaccess file simply at the top level of my website or one
level above (where I see no *other* files, no permission
probably). I have no real idea about this stuff, but I love it
when it works. <g>

--
dorayme

dorayme wrote:
> I made an .htaccess file to allow my .html files to be parsed for
> any php on them. It has:
>
> AddType application/x-httpd-php .html
>
> It did not work on one server (a university server that is Apache
> and Unix and all that good old stuff, nothing Windows or funny
> stuff). Before I contact server admin, any other ways to
> accomplish getting a .html file to be so parsed? If I name my
> files .php on this particular server, all work fine. I can put
> the .htaccess file simply at the top level of my website or one
> level above (where I see no *other* files, no permission
> probably). I have no real idea about this stuff, but I love it
> when it works. <g>
>

Multiviews would work, also.

But it's a very bad idea to parse all files as PHP files. It puts an
unnecessary load on the server for those files which do not contain PHP
code.

If they contain PHP code, they should have a .php extension. Problem
solved.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

dorayme wrote:
> I made an .htaccess file to allow my .html files to be parsed for
> any php on them. It has:
>
> AddType application/x-httpd-php .html
>
> It did not work on one server (a university server that is Apache
> and Unix and all that good old stuff, nothing Windows or funny
> stuff). Before I contact server admin, any other ways to
> accomplish getting a .html file to be so parsed? If I name my
> files .php on this particular server, all work fine. I can put
> the .htaccess file simply at the top level of my website or one
> level above (where I see no *other* files, no permission
> probably). I have no real idea about this stuff, but I love it
> when it works. <g>
>

And BTW - you should be asking this in alt.apache.configuration. It's
not really a PHP question.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

In article <C7CdnWxAs7hhYEDbnZ2dnUVZ_hzinZ2d@comcast.com>,
Jerry Stuckle <jstucklex@attglobal.net> wrote:

> dorayme wrote:
> > I made an .htaccess file to allow my .html files to be parsed for
> > any php on them. It has:
> >
> > AddType application/x-httpd-php .html
> >
> > It did not work on one server (a university server that is Apache
> > and Unix and all that good old stuff, nothing Windows or funny
> > stuff). Before I contact server admin, any other ways to
> > accomplish getting a .html file to be so parsed? If I name my
> > files .php on this particular server, all work fine. I can put
> > the .htaccess file simply at the top level of my website or one
> > level above (where I see no *other* files, no permission
> > probably). I have no real idea about this stuff, but I love it
> > when it works. <g>
> >
>
> And BTW - you should be asking this in alt.apache.configuration. It's
> not really a PHP question.

Actually, thanks for this one. I will try there.

--
dorayme

In article <C7CdnW1As7hKYEDbnZ2dnUVZ_hzinZ2d@comcast.com>,
Jerry Stuckle <jstucklex@attglobal.net> wrote:

> dorayme wrote:
> > I made an .htaccess file to allow my .html files to be parsed for
> > any php on them. It has:
> >
> > AddType application/x-httpd-php .html
> >
> > It did not work on one server (a university server that is Apache
> > and Unix and all that good old stuff, nothing Windows or funny
> > stuff). Before I contact server admin, any other ways to
> > accomplish getting a .html file to be so parsed? If I name my
> > files .php on this particular server, all work fine. I can put
> > the .htaccess file simply at the top level of my website or one
> > level above (where I see no *other* files, no permission
> > probably). I have no real idea about this stuff, but I love it
> > when it works. <g>
> >
>
> Multiviews would work, also.

?

--
dorayme

dorayme wrote:
> In article <C7CdnW1As7hKYEDbnZ2dnUVZ_hzinZ2d@comcast.com>,
> Jerry Stuckle <jstucklex@attglobal.net> wrote:
>
>> dorayme wrote:
>>> I made an .htaccess file to allow my .html files to be parsed for
>>> any php on them. It has:
>>>
>>> AddType application/x-httpd-php .html
>>>
>>> It did not work on one server (a university server that is Apache
>>> and Unix and all that good old stuff, nothing Windows or funny
>>> stuff). Before I contact server admin, any other ways to
>>> accomplish getting a .html file to be so parsed? If I name my
>>> files .php on this particular server, all work fine. I can put
>>> the .htaccess file simply at the top level of my website or one
>>> level above (where I see no *other* files, no permission
>>> probably). I have no real idea about this stuff, but I love it
>>> when it works. <g>
>>>
>> Multiviews would work, also.
>
> ?
>

Check alt.apache.configuration (assuming, of course, you use Apache).

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

dorayme wrote:
> I made an .htaccess file to allow my .html files to be parsed for
> any php on them. It has:
>
> AddType application/x-httpd-php .html
>
> It did not work on one server (a university server that is Apache
> and Unix and all that good old stuff, nothing Windows or funny
> stuff). Before I contact server admin, any other ways to
> accomplish getting a .html file to be so parsed? If I name my
> files .php on this particular server, all work fine. I can put
> the .htaccess file simply at the top level of my website or one
> level above (where I see no *other* files, no permission
> probably). I have no real idea about this stuff, but I love it
> when it works. <g>
>

If the admin has configured the apache to not allow users to use .htaccess,
then there aren't anything you can do about it than ask the admins.

IMHO it's a really bad thing to let php parse all html files, as this increase
the load on the server.

--

//Aho

In article <5k83o4F2ig8bU2@mid.individual.net>,
"J.O. Aho" <user@example.net> wrote:

> dorayme wrote:
> > I made an .htaccess file to allow my .html files to be parsed for
> > any php on them. It has:
> >
> > AddType application/x-httpd-php .html
> >
> > It did not work on one server (a university server that is Apache
> > and Unix and all that good old stuff, nothing Windows or funny
> > stuff). Before I contact server admin, any other ways to
> > accomplish getting a .html file to be so parsed? If I name my
> > files .php on this particular server, all work fine. I can put
> > the .htaccess file simply at the top level of my website or one
> > level above (where I see no *other* files, no permission
> > probably). I have no real idea about this stuff, but I love it
> > when it works. <g>
> >
>
> If the admin has configured the apache to not allow users to use .htaccess,
> then there aren't anything you can do about it than ask the admins.
>
> IMHO it's a really bad thing to let php parse all html files, as this increase
> the load on the server.

Thanks, I better ask them. I have had a radical new thought: for
this particular job, I might just change the files to .php and be
done. All work fine then.

(As for server load, all this came up before once and it seems
not a straightforward matter. I have a site that works well and
quick that parses the html for php, nearly all files having some
php on it).

--
dorayme

> I made an .htaccess file to allow my .html files to be parsed for
> any php on them. It has:

> AddType application/x-httpd-php .html

For the reasons cited by others, I think that is a lousy idea. It is much
simpler to selectively use the .php extension to mark html files with php code
in them. If for some obscure reason you want all files to have the same
extension and be parsed for php code, you can give them all the .php extension,
even if they don't have any code. They will just be passed unchanged.
--
Crash
- Windows 2000 Pro - IIS 5 - Apache 2.2.4 - PHP 5.2.1 - Perl 5.8.8

In article <V0YDi.21$2A5.10@newsfe06.lga>,
"\"Crash\" Dummy" <dvader@deathstar.mil> wrote:

> > I made an .htaccess file to allow my .html files to be parsed for
> > any php on them. It has:
>
> > AddType application/x-httpd-php .html
>
> For the reasons cited by others, I think that is a lousy idea. It is much
> simpler to selectively use the .php extension to mark html files with php
> code
> in them. If for some obscure reason you want all files to have the same
> extension and be parsed for php code, you can give them all the .php
> extension,
> even if they don't have any code. They will just be passed unchanged.
> --

All the files have php in them.

On another bigger site of mine, there had been heavy bookmarking
of files in the past, parsing for php on the .html files did not
disturb this. And not having to rename all and all internal links
and load up was saved. I was very pleased to have .html scanned
for php. Noticed no slowdown at all.

But this is indeed an interesting side issue. <g>

--
dorayme

dorayme wrote:
> In article <V0YDi.21$2A5.10@newsfe06.lga>,
> "\"Crash\" Dummy" <dvader@deathstar.mil> wrote:
>
>>> I made an .htaccess file to allow my .html files to be parsed for
>>> any php on them. It has:
>>> AddType application/x-httpd-php .html
>> For the reasons cited by others, I think that is a lousy idea. It is much
>> simpler to selectively use the .php extension to mark html files with php
>> code
>> in them. If for some obscure reason you want all files to have the same
>> extension and be parsed for php code, you can give them all the .php
>> extension,
>> even if they don't have any code. They will just be passed unchanged.
>> --
>
> All the files have php in them.
>
> On another bigger site of mine, there had been heavy bookmarking
> of files in the past, parsing for php on the .html files did not
> disturb this. And not having to rename all and all internal links
> and load up was saved. I was very pleased to have .html scanned
> for php. Noticed no slowdown at all.
>
> But this is indeed an interesting side issue. <g>
>

*YOU* may not notice a slowdown, especially when it's a new site and
you're the only one on it. But it takes a fair amount of system
resources to set up the PHP environment. And on a shared host, you're
taking resources from other, well-behaved sites.

Why do you think your hosting company doesn't allow it?

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

In article <BZidnSo5Z7OlBX3bnZ2dnUVZ_rbinZ2d@comcast.com>,
Jerry Stuckle <jstucklex@attglobal.net> wrote:

> dorayme wrote:
> > In article <V0YDi.21$2A5.10@newsfe06.lga>,
> > "\"Crash\" Dummy" <dvader@deathstar.mil> wrote:
> >
> >>> I made an .htaccess file to allow my .html files to be parsed for
> >>> any php on them. It has:
> >>> AddType application/x-httpd-php .html
> >> For the reasons cited by others, I think that is a lousy idea. It is much
> >> simpler to selectively use the .php extension to mark html files with php
> >> code
> >> in them. If for some obscure reason you want all files to have the same
> >> extension and be parsed for php code, you can give them all the .php
> >> extension,
> >> even if they don't have any code. They will just be passed unchanged.
> >> --
> >
> > All the files have php in them.
> >
> > On another bigger site of mine, there had been heavy bookmarking
> > of files in the past, parsing for php on the .html files did not
> > disturb this. And not having to rename all and all internal links
> > and load up was saved. I was very pleased to have .html scanned
> > for php. Noticed no slowdown at all.
> >
> > But this is indeed an interesting side issue. <g>
> >
>
> *YOU* may not notice a slowdown, especially when it's a new site and
> you're the only one on it. But it takes a fair amount of system
> resources to set up the PHP environment. And on a shared host, you're
> taking resources from other, well-behaved sites.
>
> Why do you think your hosting company doesn't allow it?

Jerry, the server that prompted my question is the *only* one
that I have experienced that does not allow it. But I take your
point. In fact, the site this particular server is - on
reflection - not so hard to configure with .php endings. I am
awaiting a reply from server admin but am preparing to simply
change all links and files to .php if necessary.

--
dorayme

dorayme wrote:
> In article <V0YDi.21$2A5.10@newsfe06.lga>,
> "\"Crash\" Dummy" <dvader@deathstar.mil> wrote:
>
>>> I made an .htaccess file to allow my .html files to be parsed for
>>> any php on them. It has:
>>> AddType application/x-httpd-php .html
>> For the reasons cited by others, I think that is a lousy idea. It is much
>> simpler to selectively use the .php extension to mark html files with php
>> code
>> in them. If for some obscure reason you want all files to have the same
>> extension and be parsed for php code, you can give them all the .php
>> extension,
>> even if they don't have any code. They will just be passed unchanged.
>> --
>
> All the files have php in them.

Then use .php


> On another bigger site of mine, there had been heavy bookmarking
> of files in the past, parsing for php on the .html files did not
> disturb this.

You will pain yourself into a corner if you try to be backward compatible with
the links. Just look at microsoft, they still struggle with the same old
security flaws as they kept on trying to be backward compatible instead of
securing the mess.

> And not having to rename all and all internal links
> and load up was saved.

Internal links is easy to fix with sed, will just take a few seconds to fix
them all, in all files.


> I was very pleased to have .html scanned
> for php. Noticed no slowdown at all.

You would notice the difference if you measure the CPU usage while the server
serves pages, the loading of php will be on each page instead of just sending
out the page. The more idle the CPU can be, the more environment friendly your
server will be.


--

//Aho

..oO(J.O. Aho)

>dorayme wrote:
>
>> All the files have php in them.
>
>Then use .php

No. Either .html or no extension at all in the URL (preferred).

>> On another bigger site of mine, there had been heavy bookmarking
>> of files in the past, parsing for php on the .html files did not
>> disturb this.
>
>You will pain yourself into a corner if you try to be backward compatible with
> the links.

Breaking incoming links is the worst you can do ("Cool URIs don't
change"). It leads to link rot, which annoys users and search engines.

>> And not having to rename all and all internal links
>> and load up was saved.
>
>Internal links is easy to fix with sed, will just take a few seconds to fix
>them all, in all files.

You wouldn't have to change anything if it's done correctly right from
the beginning and if you would think about your URL design before
publishing anything.

>> I was very pleased to have .html scanned
>> for php. Noticed no slowdown at all.
>
>You would notice the difference if you measure the CPU usage while the server
>serves pages

Are you on an i486 machine?

>the loading of php will be on each page instead of just sending
>out the page.

That's what a server is for, especially since she said that all pages
contain PHP. Of course there are also other ways to run PHP without any
..php extension in URLs.

Micha

Michael Fesser wrote:
> .oO(J.O. Aho)
>
>> dorayme wrote:
>>
>>> All the files have php in them.
>> Then use .php
>
> No. Either .html or no extension at all in the URL (preferred).
>
>>> On another bigger site of mine, there had been heavy bookmarking
>>> of files in the past, parsing for php on the .html files did not
>>> disturb this.
>> You will pain yourself into a corner if you try to be backward compatible with
>> the links.
>
> Breaking incoming links is the worst you can do ("Cool URIs don't
> change"). It leads to link rot, which annoys users and search engines.
>
>>> And not having to rename all and all internal links
>>> and load up was saved.
>> Internal links is easy to fix with sed, will just take a few seconds to fix
>> them all, in all files.
>
> You wouldn't have to change anything if it's done correctly right from
> the beginning and if you would think about your URL design before
> publishing anything.
>
>>> I was very pleased to have .html scanned
>>> for php. Noticed no slowdown at all.
>> You would notice the difference if you measure the CPU usage while the server
>> serves pages
>
> Are you on an i486 machine?
>
>> the loading of php will be on each page instead of just sending
>> out the page.
>
> That's what a server is for, especially since she said that all pages
> contain PHP. Of course there are also other ways to run PHP without any
> .php extension in URLs.
>
> Micha

Micha,

Don't start this argument again. It is NOT what the W3 Consortium is
saying!

It doesn't matter what machine you're on. There is significant
additional processing required to parse files unnecessarily. That's
probably why his host disabled it - they know and understand the impact.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

..oO(Jerry Stuckle)

>Michael Fesser wrote:
>
>Don't start this argument again.

Believe me - I don't want to. But some of the things he (J.O.) posted
were simply wrong or at least questionable.

>It doesn't matter what machine you're on. There is significant
>additional processing required to parse files unnecessarily.

On my servers it's not "significant", but I don't want to discuss that
anymore. I pay for the server and I just use what I pay for, that's it.

>That's
>probably why his host disabled it - they know and understand the impact.

I doubt that. Except for prohibiting .htaccess entirely there's not much
a host can do. There are nearly half a dozen ways to embed PHP into the
webserver, so it just depends on which method was used by the host.

Micha

Michael Fesser wrote:
> .oO(Jerry Stuckle)
>
>> Michael Fesser wrote:
>>
>> Don't start this argument again.
>
> Believe me - I don't want to. But some of the things he (J.O.) posted
> were simply wrong or at least questionable.
>

Nothing J.O. said was either wrong or questionable.

>> It doesn't matter what machine you're on. There is significant
>> additional processing required to parse files unnecessarily.
>
> On my servers it's not "significant", but I don't want to discuss that
> anymore. I pay for the server and I just use what I pay for, that's it.
>

Then you haven't checked it closely, or you don't have any load on the
server.

>> That's
>> probably why his host disabled it - they know and understand the impact.
>
> I doubt that. Except for prohibiting .htaccess entirely there's not much
> a host can do. There are nearly half a dozen ways to embed PHP into the
> webserver, so it just depends on which method was used by the host.
>
> Micha

And why is that? After all, that is their job - managing servers to
make efficient use of the resources.

And there is more than one way to achieve the url independence you so
often refer to. But you only know one of them, so that's all that must
exist.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

..oO(Jerry Stuckle)

>And there is more than one way to achieve the url independence you so
>often refer to.

Correct, as I said in the other post.

>But you only know one of them, so that's all that must
>exist.

Nope, I know at least three different ways (MultiViews and mod_rewrite
are the other two). All have their benefits and drawbacks. I just don't
accept "parsing all .html for PHP wastes resources" as a general rule
without knowing more details. Especially if all pages contain PHP as in
this case - then the "waste" would be exactly the same with .php URLs.

EOT
Micha

Michael Fesser wrote:

> Nope, I know at least three different ways (MultiViews and mod_rewrite
> are the other two). All have their benefits and drawbacks. I just don't
> accept "parsing all .html for PHP wastes resources" as a general rule
> without knowing more details. Especially if all pages contain PHP as in
> this case - then the "waste" would be exactly the same with .php URLs.

If you can ensure that there never will be plain HTML pages, then the load
will be the same, but as you can't and the OP wrote, not all of the pages
contains PHP, so there will be waist of CPU capacity parsing all HTML as PHP.

--

//Aho

J.O. Aho wrote:
> Michael Fesser wrote:
>
>> Nope, I know at least three different ways (MultiViews and mod_rewrite
>> are the other two). All have their benefits and drawbacks. I just don't
>> accept "parsing all .html for PHP wastes resources" as a general rule
>> without knowing more details. Especially if all pages contain PHP as in
>> this case - then the "waste" would be exactly the same with .php URLs.
>
> If you can ensure that there never will be plain HTML pages, then the load
> will be the same, but as you can't and the OP wrote, not all of the pages
> contains PHP, so there will be waist of CPU capacity parsing all HTML as PHP.
>

He just doesn't understand everything PHP must do to initialize the
page. He thinks it's the same amount of overhead as parsing for SSI's.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

..oO(J.O. Aho)

>Michael Fesser wrote:
>
>> Nope, I know at least three different ways (MultiViews and mod_rewrite
>> are the other two). All have their benefits and drawbacks. I just don't
>> accept "parsing all .html for PHP wastes resources" as a general rule
>> without knowing more details. Especially if all pages contain PHP as in
>> this case - then the "waste" would be exactly the same with .php URLs.
>
>If you can ensure that there never will be plain HTML pages

We are talking about a single site or even a single directory, not about
the entire server.

>then the load
>will be the same, but as you can't and the OP wrote, not all of the pages
>contains PHP

dorayme wrote:

| All the files have php in them.

<news:doraymeRidThis-5DAAB1.09123607092007@news-vip.optusnet.com.au>

>so there will be waist of CPU capacity parsing all HTML as PHP.

There would be much more waste if you have to rename a file from .html
to .php and redirect all old links to the new one.

Micha

Michael Fesser wrote:
> .oO(J.O. Aho)
>
>> Michael Fesser wrote:
>>
>>> Nope, I know at least three different ways (MultiViews and mod_rewrite
>>> are the other two). All have their benefits and drawbacks. I just don't
>>> accept "parsing all .html for PHP wastes resources" as a general rule
>>> without knowing more details. Especially if all pages contain PHP as in
>>> this case - then the "waste" would be exactly the same with .php URLs.
>> If you can ensure that there never will be plain HTML pages
>
> We are talking about a single site or even a single directory, not about
> the entire server.
>
>> then the load
>> will be the same, but as you can't and the OP wrote, not all of the pages
>> contains PHP
>
> dorayme wrote:
>
> | All the files have php in them.
>
> <news:doraymeRidThis-5DAAB1.09123607092007@news-vip.optusnet.com.au>
>
>> so there will be waist of CPU capacity parsing all HTML as PHP.
>
> There would be much more waste if you have to rename a file from .html
> to .php and redirect all old links to the new one.
>
> Micha

Not at all. A redirect is quite fast and efficient. And the redirect
doesn't need to be done forever.

It wouldn't have been necessary if the files had been named correctly in
the first place. And the sooner a bad decision like this is corrected,
the better it will be.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

..oO(Jerry Stuckle)

>Michael Fesser wrote:
>>
>> There would be much more waste if you have to rename a file from .html
>> to .php and redirect all old links to the new one.
>
>Not at all. A redirect is quite fast and efficient.

While parsing all .html for PHP might waste resources on a single
machine, a redirect wastes bandwidth (on a high-traffic site this
counts!) and resources on a thousand machines around the world. Browsers
have to send another request, search engines and proxys have to update
their caches.

Thirteen Simple Rules for Speeding Up Your Web Site:
11: Avoid Redirects
http://developer.yahoo.com/performan...html#redirects

>And the redirect
>doesn't need to be done forever.

At least some months if you don't want to break old links. In theory it
should be kept forvever.

>It wouldn't have been necessary if the files had been named correctly in
>the first place. And the sooner a bad decision like this is corrected,
>the better it will be.

Correct. No .php in URLs.

Micha

Michael Fesser wrote:
> .oO(Jerry Stuckle)
>
>> Michael Fesser wrote:
>>> There would be much more waste if you have to rename a file from .html
>>> to .php and redirect all old links to the new one.
>> Not at all. A redirect is quite fast and efficient.
>
> While parsing all .html for PHP might waste resources on a single
> machine, a redirect wastes bandwidth (on a high-traffic site this
> counts!) and resources on a thousand machines around the world. Browsers
> have to send another request, search engines and proxys have to update
> their caches.
>
> Thirteen Simple Rules for Speeding Up Your Web Site:
> 11: Avoid Redirects
> http://developer.yahoo.com/performan...html#redirects
>
>> And the redirect
>> doesn't need to be done forever.
>
> At least some months if you don't want to break old links. In theory it
> should be kept forvever.
>

Some redirects are unavoidable. And redirecting some pages for a few
months is much better than wasting CPU cycles forever.

Oh, and yes. Yahoo is SUCH an expert on these things. ROFLMAO!


>> It wouldn't have been necessary if the files had been named correctly in
>> the first place. And the sooner a bad decision like this is corrected,
>> the better it will be.
>
> Correct. No .php in URLs.
>

No one else shares your views.

> Micha
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

Michael Fesser wrote:
> .oO(Jerry Stuckle)
>
>> Michael Fesser wrote:
>>> There would be much more waste if you have to rename a file from .html
>>> to .php and redirect all old links to the new one.
>> Not at all. A redirect is quite fast and efficient.
>
> While parsing all .html for PHP might waste resources on a single
> machine, a redirect wastes bandwidth (on a high-traffic site this
> counts!) and resources on a thousand machines around the world. Browsers
> have to send another request, search engines and proxys have to update
> their caches.

If you use a proper web server daemon, then you have other options than
force the browser to make a new request.



--

//Aho