Dumb question -- I know, but...
Yes, I searched books and googled but couldn't find the answer.

Does php always require that the page be .php and not .html ?
Or is this server-dependent?   Mine doesn't seem to recognize a php line in a .html page.

By the way, how do searchers, eg Google, treat .php?  same as .html?
Do I  lose search position by changing from .html to .php?

   MasonC

masoncXXX@XXXfrontal-lobe.info wrote:
> Dumb question -- I know, but...
> Yes, I searched books and googled but couldn't find the answer.
> 
> Does php always require that the page be .php and not .html ?
> Or is this server-dependent?   Mine doesn't seem to recognize a php line in a .html page.
> 
> By the way, how do searchers, eg Google, treat .php?  same as .html?
> Do I  lose search position by changing from .html to .php?
> 
>    MasonC

It's part of your web server configuration - not PHP.  Security 
conscious hosts will require .php extensions to parse php files.

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

At Sun, 06 Jun 2010 14:49:27 -0700 masoncXXX@XXXfrontal-lobe.info wrote:

> 
> Dumb question -- I know, but...
> Yes, I searched books and googled but couldn't find the answer.
> 
> Does php always require that the page be .php and not .html ?
> Or is this server-dependent?   Mine doesn't seem to recognize a php line in a .html page.

The typical default settings is to consided .html (and .htm) as static
HTML files -- the server just sends these files off with no processing,
unless there are 'magical' MOD_REWRITE lines in either the httpd.conf
or .htaccess files.  .php files are normally handled by the mod_php
module via a AddHandler directive.  In *theory* once *could* have a line
like:

AddHandler php5-script .html

But this probably is NOT recomended.  And not really necessary (see below).

> 
> By the way, how do searchers, eg Google, treat .php?  same as .html?
> Do I  lose search position by changing from .html to .php?

Google, et. al. do not treat file extensions in any special way.  It
looks at the Content-Type: headers (generated by the server or whatever
code is generating the page).  Generally what happens is the .php files
generate text/html, just like raw .html files, after passing the
contents of the file though the php handler.  The code is executed by
the php interpter and the code presumable either passes HTML though or
uses echo or printf(), etc. to output additional text (with or without
additional HTML tags).  That is, the output stream is just text/html,
which either the 'bots and web browsers deal with as if it was a static
.html file.

> 
>    MasonC
>                                           

-- 
Robert Heller             -- Get the Deepwoods Software FireFox Toolbar!
Deepwoods Software        -- Linux Installation and Administration
http://www.deepsoft.com/  -- Web Hosting, with CGI and Database
heller@deepsoft.com       -- Contract Programming: C/C++, Tcl/Tk

                                                                                              

masoncXXX@XXXfrontal-lobe.info wrote:

> Dumb question -- I know, but...
> Yes, I searched books and googled but couldn't find the answer.

Which search terms were you using?

> Does php always require that the page be .php and not .html ?
> Or is this server-dependent?

This is a server configuration issue.

> Mine doesn't seem to recognize a
> php line in a .html page. 

This is generally for the better.

> By the way, how do searchers, eg Google, treat .php?  same as
> .html?

Regardless of the server-side language used, it's a server 
configuration issue, as stated above.  You should go to the 
appropriate newsgroup for your server, but before asking anything, 
you should try reading your server's manual.

> Do I  lose search position by changing from .html to
> .php? 

No.

-- 
Curtis Dyer
<?$x='<?$x=%c%s%c;printf($x,39,$x,39);?>';printf($x,39,$x,39);?>

masoncXXX@XXXfrontal-lobe.info wrote:
> Dumb question -- I know, but...
> Yes, I searched books and googled but couldn't find the answer.
> 
> Does php always require that the page be .php and not .html ?

Mostly yes. This is a function of the web server. It will be configured 
(usually) to pass .php files to the php interpreter, and send the output 
of THAT instead of sending the page. If its .html, it will never get 
passed to PHP.




> Or is this server-dependent?   Mine doesn't seem to recognize a php line in a .html page.
> 

Quite right. It should not do that. Its PHP that recognises that, not 
the server. The server either pushes the page out neat, or passes it to 
a program. Tat choice may depend in te page extension, or where it resides.



> By the way, how do searchers, eg Google, treat .php?  same as .html?
> Do I  lose search position by changing from .html to .php?
> 

I would not have a clue. The bots know not what it is that resideth upon 
thy server: they merely request the page, and examine what they get sent.

>    MasonC

On 06/06/2010 05:49 PM, masoncXXX@XXXfrontal-lobe.info wrote:
> Dumb question -- I know, but...
> Yes, I searched books and googled but couldn't find the answer.
> 
> Does php always require that the page be .php and not .html ?
> Or is this server-dependent?   Mine doesn't seem to recognize a php line in a .html page.

It is the server config... by default for example, .php files are parsed
with the PHP parser. but you can change that with an Apache directive
which I do not recall right now.

> By the way, how do searchers, eg Google, treat .php?  same as .html?
> Do I  lose search position by changing from .html to .php?
> 
>    MasonC

The URI extension means nothing.

Recommendation.-
http://www.w3.org/Provider/Style/URI
It explains a lot.

Robert Heller wrote:
> At Sun, 06 Jun 2010 14:49:27 -0700 masoncXXX@XXXfrontal-lobe.info wrote:
> 
>> Dumb question -- I know, but...
>> Yes, I searched books and googled but couldn't find the answer.
>>
>> Does php always require that the page be .php and not .html ?
>> Or is this server-dependent?   Mine doesn't seem to recognize a php line in a .html page.
> 
> The typical default settings is to consided .html (and .htm) as static
> HTML files -- the server just sends these files off with no processing,
> unless there are 'magical' MOD_REWRITE lines in either the httpd.conf
> or .htaccess files.  .php files are normally handled by the mod_php
> module via a AddHandler directive.  In *theory* once *could* have a line
> like:
> 
> AddHandler php5-script .html
>

It's more than theory, you can have a line like:

AddHandler php5-script .html .php .mycustomextension

if you want. Right, wrong, you can do that and all the extensions listed 
will get parsed by PHP.


> But this probably is NOT recomended.  And not really necessary (see below).
> 
>> By the way, how do searchers, eg Google, treat .php?  same as .html?
>> Do I  lose search position by changing from .html to .php?
> 
> Google, et. al. do not treat file extensions in any special way.  It
> looks at the Content-Type: headers (generated by the server or whatever
> code is generating the page).  Generally what happens is the .php files
> generate text/html, just like raw .html files, after passing the
> contents of the file though the php handler.  The code is executed by
> the php interpter and the code presumable either passes HTML though or
> uses echo or printf(), etc. to output additional text (with or without
> additional HTML tags).  That is, the output stream is just text/html,
> which either the 'bots and web browsers deal with as if it was a static
> .html file.
> 
>>    MasonC
>>                                           
> 

-- 
Norman
Registered Linux user #461062
-Have you been to www.php.net yet?-

Norman Peelman wrote:
> Robert Heller wrote:
>>
>> The typical default settings is to consided .html (and .htm) as static
>> HTML files -- the server just sends these files off with no processing,
>> unless there are 'magical' MOD_REWRITE lines in either the httpd.conf
>> or .htaccess files.  .php files are normally handled by the mod_php
>> module via a AddHandler directive.  In *theory* once *could* have a line
>> like:
>>
>> AddHandler php5-script .html
>>
> 
> It's more than theory, you can have a line like:
> 
> AddHandler php5-script .html .php .mycustomextension
> 
> if you want. Right, wrong, you can do that and all the extensions listed 
> will get parsed by PHP.
> 
>

And is a very bad idea.

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

Jerry Stuckle wrote:

>> It's more than theory, you can have a line like:
>> 
>> AddHandler php5-script .html .php .mycustomextension
>> 
>> if you want. Right, wrong, you can do that and all the extensions listed 
>> will get parsed by PHP.
> 
> And is a very bad idea.

You keep saying that. Provide a cite.

-- 
   -bts
   -Four wheels carry the body; two wheels move the soul

Beauregard T. Shagnasty wrote:
> Jerry Stuckle wrote:
> 
>>> It's more than theory, you can have a line like:
>>>
>>> AddHandler php5-script .html .php .mycustomextension
>>>
>>> if you want. Right, wrong, you can do that and all the extensions listed 
>>> will get parsed by PHP.
>> And is a very bad idea.
> 
> You keep saying that. Provide a cite.
> 

I've tried to explain it to you before.  And anyone with a modicum of 
understanding about security would understand.

But I'm tired of trying to teach a pig to sing.

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

Jerry Stuckle wrote:

> Beauregard T. Shagnasty wrote:
>> Jerry Stuckle wrote:
>>> Norman Peelman wrote:
>>>> It's more than theory, you can have a line like:
>>>>
>>>> AddHandler php5-script .html .php .mycustomextension
>>>>
>>>> if you want. Right, wrong, you can do that and all the extensions
>>>> listed will get parsed by PHP.
>>> 
>>> And is a very bad idea.
>> 
>> You keep saying that. Provide a cite.
> 
> I've tried to explain it to you before.  And anyone with a modicum of
> understanding about security would understand.

No, you didn't explain it. You only said it's a security risk and a bad
idea. 

In Message-ID: <hu0g2r$l6t$1@news.eternal-september.org> you said,
"People are generally less careful about what's in .htm(l) files on a 
site because those don't have any server-side scripting in them (other 
than SSI, etc.). " ...  

That is not an authoritative reason, and it's the only reason you gave.

-- 
   -bts
   -Four wheels carry the body; two wheels move the soul

Beauregard T. Shagnasty wrote:
> Jerry Stuckle wrote:
> 
>> Beauregard T. Shagnasty wrote:
>>> Jerry Stuckle wrote:
>>>> Norman Peelman wrote:
>>>>> It's more than theory, you can have a line like:
>>>>>
>>>>> AddHandler php5-script .html .php .mycustomextension
>>>>>
>>>>> if you want. Right, wrong, you can do that and all the extensions
>>>>> listed will get parsed by PHP.
>>>> And is a very bad idea.
>>> You keep saying that. Provide a cite.
>> I've tried to explain it to you before.  And anyone with a modicum of
>> understanding about security would understand.
> 
> No, you didn't explain it. You only said it's a security risk and a bad
> idea. 
> 
> In Message-ID: <hu0g2r$l6t$1@news.eternal-september.org> you said,
> "People are generally less careful about what's in .htm(l) files on a 
> site because those don't have any server-side scripting in them (other 
> than SSI, etc.). " ...  
> 
> That is not an authoritative reason, and it's the only reason you gave.
> 

No, it is not.  You just didn't read the entire thread.

But I'm also not going to reply to you on this topic any more.  My 
mother always told me "Don't try to teach a pig to sing.  It wastes your 
time and annoys the pig."

So say whatever you want.  I won't reply.


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

Jerry Stuckle wrote:

> Beauregard T. Shagnasty wrote:
>> Jerry Stuckle wrote:
>>> Beauregard T. Shagnasty wrote:
>>>> Jerry Stuckle wrote:
>>>>> Norman Peelman wrote:
>>>>>> It's more than theory, you can have a line like: 
>>>>>> 
>>>>>> AddHandler php5-script .html .php .mycustomextension 
>>>>>> 
>>>>>> if you want. Right, wrong, you can do that and all the
>>>>>> extensions listed will get parsed by PHP.
>>>>> And is a very bad idea.
>>>> You keep saying that. Provide a cite.
>>> 
>>> I've tried to explain it to you before.  And anyone with a modicum
>>> of understanding about security would understand.
>> 
>> No, you didn't explain it. You only said it's a security risk and a
>> bad idea. 
>> 
>> In Message-ID: <hu0g2r$l6t$1@news.eternal-september.org> you said,
>> "People are generally less careful about what's in .htm(l) files on
>> a site because those don't have any server-side scripting in them
>> (other than SSI, etc.). " ... 
>> 
>> That is not an authoritative reason, and it's the only reason you
>> gave.
> 
> No, it is not.  You just didn't read the entire thread.

I certainly did. You never gave a reason, only your opinion.

> But I'm also not going to reply to you on this topic any more.  My
> mother always told me "Don't try to teach a pig to sing.  It wastes
> your time and annoys the pig." 
> 
> So say whatever you want.  I won't reply.

You won't, because you don't have an answer.

Is there anyone else reading here who thinks Jerry is correct? And why?

-- 
   -bts
   -Four wheels carry the body; two wheels move the soul

Beauregard T. Shagnasty wrote:
> Jerry Stuckle wrote:
> 
>> Beauregard T. Shagnasty wrote:
>>> Jerry Stuckle wrote:
>>>> Beauregard T. Shagnasty wrote:
>>>>> Jerry Stuckle wrote:
>>>>>> Norman Peelman wrote:
>>>>>>> It's more than theory, you can have a line like: 
>>>>>>>
>>>>>>> AddHandler php5-script .html .php .mycustomextension 
>>>>>>>
>>>>>>> if you want. Right, wrong, you can do that and all the
>>>>>>> extensions listed will get parsed by PHP.
>>>>>> And is a very bad idea.
>>>>> You keep saying that. Provide a cite.
>>>> I've tried to explain it to you before.  And anyone with a modicum
>>>> of understanding about security would understand.
>>> No, you didn't explain it. You only said it's a security risk and a
>>> bad idea. 
>>>
>>> In Message-ID: <hu0g2r$l6t$1@news.eternal-september.org> you said,
>>> "People are generally less careful about what's in .htm(l) files on
>>> a site because those don't have any server-side scripting in them
>>> (other than SSI, etc.). " ... 
>>>
>>> That is not an authoritative reason, and it's the only reason you
>>> gave.
>> No, it is not.  You just didn't read the entire thread.
> 
> I certainly did. You never gave a reason, only your opinion.
> 
>> But I'm also not going to reply to you on this topic any more.  My
>> mother always told me "Don't try to teach a pig to sing.  It wastes
>> your time and annoys the pig." 
>>
>> So say whatever you want.  I won't reply.
> 
> You won't, because you don't have an answer.
> 
> Is there anyone else reading here who thinks Jerry is correct? And why?
> 
Jerry is a single minded twit: he always relates any issue to his own 
very limited experience in a particular corporate environment. He 
doesn't understand context, or how other peoples contexts differ from 
his own.

He is opinionated , and a 'right man'. He is not here to solve peoples 
problems, but to dominate the NG with his ego.


He belongs in your kill file.

He is not worth arguing with.

There is a grain of truth in most of what he says, but its a grain that 
is far easier gleaned from other peoples posts, and they WILL give the 
context, and the reasoning behind the assertions.

Jerry will simple weasel the conversation and produce misleading 
information and sometimes downright lies, in order to win arguments: 
winning arguments means more to him than solving problems, which is why 
no one will employ him, and he has so much time to waste arguing on 
Usenet. As evinced by the public trading records of his 'training and 
consultancy ' company.

The Natural Philosopher wrote:

> Beauregard T. Shagnasty wrote:
>> Is there anyone else reading here who thinks Jerry is correct? And
>> why?
>
> Jerry is a single minded twit:  ...

Well, yes, I can agree with all that.   :-)

> He is not worth arguing with.

Mostly true -- unless (and when) he gives bad advice to a newbie who
needs to be made aware of said bad advice. 

-- 
   -bts
   -Four wheels carry the body; two wheels move the soul

Beauregard T. Shagnasty wrote:
> The Natural Philosopher wrote:
> 
>> Beauregard T. Shagnasty wrote:
>>> Is there anyone else reading here who thinks Jerry is correct? And
>>> why?
>> Jerry is a single minded twit:  ...
> 
> Well, yes, I can agree with all that.   :-)
> 
>> He is not worth arguing with.
> 
> Mostly true -- unless (and when) he gives bad advice to a newbie who
> needs to be made aware of said bad advice. 
> 
Exactly.

Its less that it is bad advice, more that it is narrow advice, with no 
supporting reasoning behind it: Jerry is simply passing on by rote what 
he learnt by rote, with as little understanding of the reasons behind it 
as one suspects his teachers had.

Scientific tests have shown that there is an inverse relationship 
between (self) confidence and actual competence: That's Jerry to a 'T'.

Going back to the original point as to whether or not its a Bad Thing to 
run arbitrary .html files through a PHP parser, yes, its a Bad Idea, 
because people like Jerry maintain these sites, and they are used to 
seeing it done The One True Way - i.e. the way that they have been 
taught to do it, the way they expect to see it, and the way it always 
has been everywhere else.

Lacking the underlying ability or intelligence to e.g. look in the web 
server configuration files (or being rightly prohibited from so doing by 
admins with more experience and skills) they can only flounder 
helplessly in a sea of ignorance when confronted with something they 
didn't expect to find.

Or worse still, decide its such a Bad Idea they will switch it off, 
thereby exposing the whole source code of the site to public scrutiny. 
And given the standards of code they write, that would be personally 
embarrassing as well as constituting a security risk if e.g. they have 
SQL passwords in the source in clear text.


If you have to employ third rate Stuckles, you have to impose standards, 
and because they are third rate, they cant understand the reasons, so 
you use religion instead.


So these things are Bad Things because that is how you teach it to code 
monkeys. Its too hard to tell Muslims that pork meat in a hot climate 
with indifferent standards of hygiene and no refrigeration and no 
insecticides constitutes a genuine risk of stomach worms and intestinal 
bacteria: No, you encapsulate in in an emotive phrase 'unclean, a sin 
against Allah' and thereby achieve the desired result at much less effort.

So it is when you have a large project with many stupid people employed: 
you create a religion, called 'standards' and enforce it with implied 
moral overtones. There is 'good practice' and there is 'bad practice; 
and there is no discussion..

Stuckle is, sadly, one of life's losers. Not because he is a 'bear of 
little brain'..plenty are like that, but become happy successful people: 
No: Stuckle is doomed to lose because he has a fatal character flaw. He 
wants to be smarter than he really is. And especially to *appear* 
smarter than he really is, since he cares deeply about his image to 
others. And to himself. This is why he dare not lose an argument: At 
some level his bluster and ad hominem attacks on those who see through 
him leads him to believe that he has fooled everyone else into thinking 
he actually has something of value to offer in the brain department.

One can imagine his CV, Junior coder in a large organisation, so 
irritating to his peers that he got promoted to team leader, because he 
couldn't code, and that at least got him off the project..but over 
puffed with ego, he screwed around and became so despised by his 
colleagues that at some level he was kicked upstairs and might have 
become a project manager. But there his true incompetence showed up, and 
there being no other place to go, he was probably made redundant with 
his entire team.

But he couldn't back down, and so he started up a training company, to 
teach the only things he ever learnt: The One True Way of writing crap 
code in large organisations. But there's only so many times you can pull 
that stunt, and so Jerry sits in front of a keyboard, desperate and 
alone, trying to be impressive in the hope that someone will be fool 
enough to hire him.

I mean who else is stupid enough to go on Usenet with there real name 
and contact details? He loves the junk mail. Who else is gonna contact 
him? What else can he fill his days with?

I've killfiled him, so I wont see his response..

watch and learn. :-)

The Natural Philosopher wrote:
> Beauregard T. Shagnasty wrote:
>> The Natural Philosopher wrote:
>>
>>> Beauregard T. Shagnasty wrote:
>>>> Is there anyone else reading here who thinks Jerry is correct? And
>>>> why?
>>> Jerry is a single minded twit:  ...
>>
>> Well, yes, I can agree with all that.   :-)
>>
>>> He is not worth arguing with.
>>
>> Mostly true -- unless (and when) he gives bad advice to a newbie who
>> needs to be made aware of said bad advice.
> Exactly.
> 
> Its less that it is bad advice, more that it is narrow advice, with no 
> supporting reasoning behind it: Jerry is simply passing on by rote what 
> he learnt by rote, with as little understanding of the reasons behind it 
> as one suspects his teachers had.
> 
> Scientific tests have shown that there is an inverse relationship 
> between (self) confidence and actual competence: That's Jerry to a 'T'.
> 
> Going back to the original point as to whether or not its a Bad Thing to 
> run arbitrary .html files through a PHP parser, yes, its a Bad Idea, 
> because people like Jerry maintain these sites, and they are used to 
> seeing it done The One True Way - i.e. the way that they have been 
> taught to do it, the way they expect to see it, and the way it always 
> has been everywhere else.
> 
> Lacking the underlying ability or intelligence to e.g. look in the web 
> server configuration files (or being rightly prohibited from so doing by 
> admins with more experience and skills) they can only flounder 
> helplessly in a sea of ignorance when confronted with something they 
> didn't expect to find.
> 
> Or worse still, decide its such a Bad Idea they will switch it off, 
> thereby exposing the whole source code of the site to public scrutiny. 
> And given the standards of code they write, that would be personally 
> embarrassing as well as constituting a security risk if e.g. they have 
> SQL passwords in the source in clear text.
> 
> 
> If you have to employ third rate Stuckles, you have to impose standards, 
> and because they are third rate, they cant understand the reasons, so 
> you use religion instead.
> 
> 
> So these things are Bad Things because that is how you teach it to code 
> monkeys. Its too hard to tell Muslims that pork meat in a hot climate 
> with indifferent standards of hygiene and no refrigeration and no 
> insecticides constitutes a genuine risk of stomach worms and intestinal 
> bacteria: No, you encapsulate in in an emotive phrase 'unclean, a sin 
> against Allah' and thereby achieve the desired result at much less effort.
> 
> So it is when you have a large project with many stupid people employed: 
> you create a religion, called 'standards' and enforce it with implied 
> moral overtones. There is 'good practice' and there is 'bad practice; 
> and there is no discussion..
> 
> Stuckle is, sadly, one of life's losers. Not because he is a 'bear of 
> little brain'..plenty are like that, but become happy successful people: 
> No: Stuckle is doomed to lose because he has a fatal character flaw. He 
> wants to be smarter than he really is. And especially to *appear* 
> smarter than he really is, since he cares deeply about his image to 
> others. And to himself. This is why he dare not lose an argument: At 
> some level his bluster and ad hominem attacks on those who see through 
> him leads him to believe that he has fooled everyone else into thinking 
> he actually has something of value to offer in the brain department.
> 
> One can imagine his CV, Junior coder in a large organisation, so 
> irritating to his peers that he got promoted to team leader, because he 
> couldn't code, and that at least got him off the project..but over 
> puffed with ego, he screwed around and became so despised by his 
> colleagues that at some level he was kicked upstairs and might have 
> become a project manager. But there his true incompetence showed up, and 
> there being no other place to go, he was probably made redundant with 
> his entire team.
> 
> But he couldn't back down, and so he started up a training company, to 
> teach the only things he ever learnt: The One True Way of writing crap 
> code in large organisations. But there's only so many times you can pull 
> that stunt, and so Jerry sits in front of a keyboard, desperate and 
> alone, trying to be impressive in the hope that someone will be fool 
> enough to hire him.
> 
> I mean who else is stupid enough to go on Usenet with there real name 
> and contact details? He loves the junk mail. Who else is gonna contact 
> him? What else can he fill his days with?
> 
> I've killfiled him, so I wont see his response..
> 
> watch and learn. :-)
> 
> 
> 

This is so funny coming from a complete idiot who won't use his real 
name.  That's because he isn't the programmer or engineer he claims to 
be - only an out of work ditch digger who can't figure out which end of 
the shovel to use.

Your credibility on usenet is exactly ZERO, TNP.  Yet you continue to 
espouse your ignorance on a daily basis.

Some people just never learn.

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

Beauregard T. Shagnasty wrote:
> Jerry Stuckle wrote:

>>> In Message-ID: <hu0g2r$l6t$1@news.eternal-september.org> you said,
>>> "People are generally less careful about what's in .htm(l) files on
>>> a site because those don't have any server-side scripting in them
>>> (other than SSI, etc.). " ...
>>>
>>> That is not an authoritative reason, and it's the only reason you
>>> gave.
>>
>> No, it is not.  You just didn't read the entire thread.
>
> I certainly did. You never gave a reason, only your opinion.
>
>> But I'm also not going to reply to you on this topic any more.  My
>> mother always told me "Don't try to teach a pig to sing.  It wastes
>> your time and annoys the pig."
>>
>> So say whatever you want.  I won't reply.
>
> You won't, because you don't have an answer.
>
> Is there anyone else reading here who thinks Jerry is correct? And
> why?

Wasn't going to jump into this, but why not...

I do not think Jerry is correct.

I have watched every post Jerry has ever made on the subject and have not 
yet (unless I have missed one or two) found anything to substantiate the 
claim other then a self-proclaimed assertion that it "is a security issue", 
along with some vague assertion that people who write .html files are less 
concerned with security than those who write .php files, as if a bloody file 
extension matters.

I have a couple of legacy sites I administer. Small ones (not like Jerrys 
"corporate" sites"). Half a dozen pages. These needed jazzing up and one of 
the results was that every single HTML file ended up containing PHP, along 
with the several new ones added.

What to do? Fiddle with mod-rewrite rules to map .html to .php and totally 
confuse myself - ah, am I really editing .php and looking at .html with my 
browser or the other way round.

No. Simply use the Addtype directive in a .htaccess file to cause html, and 
in these cases, .htm files to be parsed by PHP.

And no, Jerry, I could not simply rename the htm files to .php. One of these 
sites is a very large tennis club site with thousands of people with 
bookmarks to the various pages, and with a quite large google entry as well.

Please, Jerry, tell me exactly why what I have done is a "very bad idea".

On Jun 7, 1:40=A0pm, The Natural Philosopher <t...@invalid.invalid>
wrote:
> I mean who else is stupid enough to go on Usenet with there real name
> and contact details?
The irony of someone calling someone else stupid but not knowing which
spelling of their/there/they're to use!

Captain Paralytic wrote:
> On Jun 7, 1:40 pm, The Natural Philosopher <t...@invalid.invalid>
> wrote:
>> I mean who else is stupid enough to go on Usenet with there real name
>> and contact details?
> The irony of someone calling someone else stupid but not knowing which
> spelling of their/there/they're to use!

Sorry. the spell checker caught that one and perverted it.

*I* know which spelling. The spell checker doesn't...

rf wrote:
> Beauregard T. Shagnasty wrote:
>> Jerry Stuckle wrote:
> 
>>>> In Message-ID: <hu0g2r$l6t$1@news.eternal-september.org> you said,
>>>> "People are generally less careful about what's in .htm(l) files on
>>>> a site because those don't have any server-side scripting in them
>>>> (other than SSI, etc.). " ...
>>>>
>>>> That is not an authoritative reason, and it's the only reason you
>>>> gave.
>>> No, it is not.  You just didn't read the entire thread.
>> I certainly did. You never gave a reason, only your opinion.
>>
>>> But I'm also not going to reply to you on this topic any more.  My
>>> mother always told me "Don't try to teach a pig to sing.  It wastes
>>> your time and annoys the pig."
>>>
>>> So say whatever you want.  I won't reply.
>> You won't, because you don't have an answer.
>>
>> Is there anyone else reading here who thinks Jerry is correct? And
>> why?
> 
> Wasn't going to jump into this, but why not...
> 
> I do not think Jerry is correct.
> 
> I have watched every post Jerry has ever made on the subject and have not 
> yet (unless I have missed one or two) found anything to substantiate the 
> claim other then a self-proclaimed assertion that it "is a security issue", 
> along with some vague assertion that people who write .html files are less 
> concerned with security than those who write .php files, as if a bloody file 
> extension matters.
> 
> I have a couple of legacy sites I administer. Small ones (not like Jerrys 
> "corporate" sites"). Half a dozen pages. These needed jazzing up and one of 
> the results was that every single HTML file ended up containing PHP, along 
> with the several new ones added.
> 
> What to do? Fiddle with mod-rewrite rules to map .html to .php and totally 
> confuse myself - ah, am I really editing .php and looking at .html with my 
> browser or the other way round.
> 
> No. Simply use the Addtype directive in a .htaccess file to cause html, and 
> in these cases, .htm files to be parsed by PHP.
> 
> And no, Jerry, I could not simply rename the htm files to .php. One of these 
> sites is a very large tennis club site with thousands of people with 
> bookmarks to the various pages, and with a quite large google entry as well.
> 
> Please, Jerry, tell me exactly why what I have done is a "very bad idea".
> 
> 
> 

I'm going to try this one more time for the dumb shits who couldn't read 
the first time.

Good security is based on locking everything down tight and allowing 
only what is absolutely necessary.  It is multi-layered, and assumes at 
least one layer will fail.

Security should never be implemented in user space - like .htaccess, for 
this is the easiest to change.  Changing .htaccess to allow .htm(l) 
files to be parsed as php code is a huge exposure, because it allows a 
change to .htaccess to expose all the php code.

Placing it in the server configuration file is only slightly more 
secure; since it is not a standard configuration parameter, any update 
to the server or server configuration could again expose the php code.

Even if you have your own server, an admin could install a new 
configuration and unknowingly reinstate the default options - which 
means the html(l) is no longer being parsed.

And if you ever go to a new server, you need to ensure you change all 
the default options on that new server to match the old one.  Any little 
mistake, and poof - your code is open to the world.

You can even have pages which are completely innocuous on properly 
configured sites cause huge problems on a site configured as such.

There are many other possibilities here - all of which have bad 
consequences.  However, if you don't care about security and don't mind 
if someone hacks your (or your client's site), then fine - just tell the 
server to parse your htm(l) files as php code.

And you think it can't happen to you.  That's what every victim of a 
site hack thought.

For more information, look into basic security concepts.  This is 
getting way off topic in a PHP newsgroup, so I will not discuss this 
further.

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

Captain Paralytic wrote:
> On Jun 7, 1:40 pm, The Natural Philosopher <t...@invalid.invalid>
> wrote:
>> I mean who else is stupid enough to go on Usenet with there real name
>> and contact details?
> The irony of someone calling someone else stupid but not knowing which
> spelling of their/there/they're to use!

LOL, now he blames his spell checker for his mistakes :)

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

Jerry Stuckle wrote:
[snippage]
> I'm going to try this one more time for the dumb shits who couldn't
> read the first time.

Your debating tactics leave a lot to be desired, including calling
anyone who disagrees with you a "dumb shit."

> Good security is based on locking everything down tight and allowing
> only what is absolutely necessary.  It is multi-layered, and assumes
> at least one layer will fail.

Perhaps. The problem with your comments in this (and that other) thread
assume *more* than using an .htaccess directive, and/or implanting a
rogue PHP script as a parsable .html file. In order to do those things
you say are "insecure" already requires access to the host by some
hacking method above and beyond the mere fact of parsing .html files as
PHP.

If you, as a hacker, did not already have unfettered access to the raw
hosting server, how would you modify the .htaccess or load a rogue file?
How would you know a site used the AddHandler directive without being
able to read .htaccess?  And what scripting would you write in your
rogue file in the first place, without knowing the internal structure of
the site?

You assume too much.

-- 
   -bts
   -Four wheels carry the body; two wheels move the soul

Beauregard T. Shagnasty wrote:
> Jerry Stuckle wrote:
> [snippage]
>> I'm going to try this one more time for the dumb shits who couldn't
>> read the first time.
> 
> Your debating tactics leave a lot to be desired, including calling
> anyone who disagrees with you a "dumb shit."
> 
>> Good security is based on locking everything down tight and allowing
>> only what is absolutely necessary.  It is multi-layered, and assumes
>> at least one layer will fail.
> 
> Perhaps. The problem with your comments in this (and that other) thread
> assume *more* than using an .htaccess directive, and/or implanting a
> rogue PHP script as a parsable .html file. In order to do those things
> you say are "insecure" already requires access to the host by some
> hacking method above and beyond the mere fact of parsing .html files as
> PHP.
> 
> If you, as a hacker, did not already have unfettered access to the raw
> hosting server, how would you modify the .htaccess or load a rogue file?
> How would you know a site used the AddHandler directive without being
> able to read .htaccess?  And what scripting would you write in your
> rogue file in the first place, without knowing the internal structure of
> the site?
> 
> You assume too much.
> 
mostly that he is smarter than anyone else.
whereas the reverse is usually true.

On 06/06/2010 05:00 PM, Beauregard T. Shagnasty wrote:
> Jerry Stuckle wrote:
>
>>> It's more than theory, you can have a line like:
>>>
>>> AddHandler php5-script .html .php .mycustomextension
>>>
>>> if you want. Right, wrong, you can do that and all the extensions listed
>>> will get parsed by PHP.
>>
>> And is a very bad idea.
>
> You keep saying that. Provide a cite.
>

If you do that the server than has to parse each and every file for php 
code. This in turns makes the server work harder and servers out the 
information slower.  This is just a bad idea from the start. Also many 
web host will not allow you to do that.

On 06/07/2010 06:23 AM, The Natural Philosopher wrote:
> Captain Paralytic wrote:
>> On Jun 7, 1:40 pm, The Natural Philosopher <t...@invalid.invalid>
>> wrote:
>>> I mean who else is stupid enough to go on Usenet with there real name
>>> and contact details?
>> The irony of someone calling someone else stupid but not knowing which
>> spelling of their/there/they're to use!
>
> Sorry. the spell checker caught that one and perverted it.
>
> *I* know which spelling. The spell checker doesn't...


The spell checker did its job. Perhaps a grammar checker is needed also.

On 06/07/2010 06:02 AM, rf wrote:
> Beauregard T. Shagnasty wrote:
>> Jerry Stuckle wrote:
>
>>>> In Message-ID:<hu0g2r$l6t$1@news.eternal-september.org>  you said,
>>>> "People are generally less careful about what's in .htm(l) files on
>>>> a site because those don't have any server-side scripting in them
>>>> (other than SSI, etc.). " ...
>>>>
>>>> That is not an authoritative reason, and it's the only reason you
>>>> gave.
>>>
>>> No, it is not.  You just didn't read the entire thread.
>>
>> I certainly did. You never gave a reason, only your opinion.
>>
>>> But I'm also not going to reply to you on this topic any more.  My
>>> mother always told me "Don't try to teach a pig to sing.  It wastes
>>> your time and annoys the pig."
>>>
>>> So say whatever you want.  I won't reply.
>>
>> You won't, because you don't have an answer.
>>
>> Is there anyone else reading here who thinks Jerry is correct? And
>> why?
>
> Wasn't going to jump into this, but why not...
>
> I do not think Jerry is correct.
>
> I have watched every post Jerry has ever made on the subject and have not
> yet (unless I have missed one or two) found anything to substantiate the
> claim other then a self-proclaimed assertion that it "is a security issue",
> along with some vague assertion that people who write .html files are less
> concerned with security than those who write .php files, as if a bloody file
> extension matters.
>
> I have a couple of legacy sites I administer. Small ones (not like Jerrys
> "corporate" sites"). Half a dozen pages. These needed jazzing up and one of
> the results was that every single HTML file ended up containing PHP, along
> with the several new ones added.
>
> What to do? Fiddle with mod-rewrite rules to map .html to .php and totally
> confuse myself - ah, am I really editing .php and looking at .html with my
> browser or the other way round.
>
> No. Simply use the Addtype directive in a .htaccess file to cause html, and
> in these cases, .htm files to be parsed by PHP.
>
> And no, Jerry, I could not simply rename the htm files to .php. One of these
> sites is a very large tennis club site with thousands of people with
> bookmarks to the various pages, and with a quite large google entry as well.
>
> Please, Jerry, tell me exactly why what I have done is a "very bad idea".
>
>
>
Not to support anyone one way or the other. But when you make the server 
parse an .html file for .php it places a greater work load on the server 
more so than if the server know if the file was a .php  When you make 
these changes the server no has to parse each and every file for .php 
code. It slows the server by causing un-necessary work.  Many web host 
will not allow this or for that matter using .shtml in the same fashion. 
  It is just a bad idea from the git go.  Of course there are always 
time where one really doesn't have much of a choice in the matter.

David wrote:

> Beauregard T. Shagnasty wrote:
>> Jerry Stuckle wrote:
>> [Norman wrote:]
>>>> AddHandler php5-script .html .php .mycustomextension
>>>
>>> And is a very bad idea.
>>
>> You keep saying that. Provide a cite.
> 
> If you do that the server than has to parse each and every file for
> php code. This in turns makes the server work harder and servers out
> the information slower.

MasonC asked this question in c.i.w.a.s. first, where I answered "if you
only have a couple of PHP scripts you want as .html, then place them in
a separate directory and add the .htaccess AddHandler in that one
(sub)directory. Leave all your pure .html files where they are." So, the
amount of extra processing would be less than miniscule.

If, like most PHP-style sites, all files use standard includes for the
banner/nav/footer etc, there would again be miniscule additional
processing for using the .html file extension.

>  This is just a bad idea from the start.

Not if given a bit of thought. It's (.html extension) certainly not the
super-bad security issue Jerry is stuck on.

> Also many web host will not allow you to do that.

I would find a better web host!   :-)   (Mine all allow it.)

-- 
   -bts
   -Four wheels carry the body; two wheels move the soul

David wrote:
> On 06/07/2010 06:02 AM, rf wrote:
>> Beauregard T. Shagnasty wrote:
>>> Jerry Stuckle wrote:
>>
>>>>> In Message-ID:<hu0g2r$l6t$1@news.eternal-september.org>  you said,
>>>>> "People are generally less careful about what's in .htm(l) files on
>>>>> a site because those don't have any server-side scripting in them
>>>>> (other than SSI, etc.). " ...
>>>>>
>>>>> That is not an authoritative reason, and it's the only reason you
>>>>> gave.
>>>>
>>>> No, it is not.  You just didn't read the entire thread.
>>>
>>> I certainly did. You never gave a reason, only your opinion.
>>>
>>>> But I'm also not going to reply to you on this topic any more.  My
>>>> mother always told me "Don't try to teach a pig to sing.  It wastes
>>>> your time and annoys the pig."
>>>>
>>>> So say whatever you want.  I won't reply.
>>>
>>> You won't, because you don't have an answer.
>>>
>>> Is there anyone else reading here who thinks Jerry is correct? And
>>> why?
>>
>> Wasn't going to jump into this, but why not...
>>
>> I do not think Jerry is correct.
>>
>> I have watched every post Jerry has ever made on the subject and have not
>> yet (unless I have missed one or two) found anything to substantiate the
>> claim other then a self-proclaimed assertion that it "is a security 
>> issue",
>> along with some vague assertion that people who write .html files are 
>> less
>> concerned with security than those who write .php files, as if a 
>> bloody file
>> extension matters.
>>
>> I have a couple of legacy sites I administer. Small ones (not like Jerrys
>> "corporate" sites"). Half a dozen pages. These needed jazzing up and 
>> one of
>> the results was that every single HTML file ended up containing PHP, 
>> along
>> with the several new ones added.
>>
>> What to do? Fiddle with mod-rewrite rules to map .html to .php and 
>> totally
>> confuse myself - ah, am I really editing .php and looking at .html 
>> with my
>> browser or the other way round.
>>
>> No. Simply use the Addtype directive in a .htaccess file to cause 
>> html, and
>> in these cases, .htm files to be parsed by PHP.
>>
>> And no, Jerry, I could not simply rename the htm files to .php. One of 
>> these
>> sites is a very large tennis club site with thousands of people with
>> bookmarks to the various pages, and with a quite large google entry as 
>> well.
>>
>> Please, Jerry, tell me exactly why what I have done is a "very bad idea".
>>
>>
>>
> Not to support anyone one way or the other. But when you make the server 
> parse an .html file for .php it places a greater work load on the server 
> more so than if the server know if the file was a .php  When you make 
> these changes the server no has to parse each and every file for .php 
> code. It slows the server by causing un-necessary work.  Many web host 
> will not allow this or for that matter using .shtml in the same fashion. 
>  It is just a bad idea from the git go.  Of course there are always time 
> where one really doesn't have much of a choice in the matter.
> 
> 


its not such a big deal load wise. Yes, a php process springs up, but 
its no big deal.

Beauregard T. Shagnasty wrote:
> Jerry Stuckle wrote:
> [snippage]
>> I'm going to try this one more time for the dumb shits who couldn't
>> read the first time.
> 
> Your debating tactics leave a lot to be desired, including calling
> anyone who disagrees with you a "dumb shit."
> 
>> Good security is based on locking everything down tight and allowing
>> only what is absolutely necessary.  It is multi-layered, and assumes
>> at least one layer will fail.
> 
> Perhaps. The problem with your comments in this (and that other) thread
> assume *more* than using an .htaccess directive, and/or implanting a
> rogue PHP script as a parsable .html file. In order to do those things
> you say are "insecure" already requires access to the host by some
> hacking method above and beyond the mere fact of parsing .html files as
> PHP.
> 
> If you, as a hacker, did not already have unfettered access to the raw
> hosting server, how would you modify the .htaccess or load a rogue file?
> How would you know a site used the AddHandler directive without being
> able to read .htaccess?  And what scripting would you write in your
> rogue file in the first place, without knowing the internal structure of
> the site?
> 
> You assume too much.
> 

As I said - always assume at least one layer of access will fail.  It's 
the same reasoning as putting php files containing passwords, etc., 
outside of the web root.

Those who don't plan for security are the ones who get hacked.

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

The Natural Philosopher wrote:
> David wrote:
>> On 06/07/2010 06:02 AM, rf wrote:
>>> Beauregard T. Shagnasty wrote:
>>>> Jerry Stuckle wrote:
>>>
>>>>>> In Message-ID:<hu0g2r$l6t$1@news.eternal-september.org>  you said,
>>>>>> "People are generally less careful about what's in .htm(l) files on
>>>>>> a site because those don't have any server-side scripting in them
>>>>>> (other than SSI, etc.). " ...
>>>>>>
>>>>>> That is not an authoritative reason, and it's the only reason you
>>>>>> gave.
>>>>>
>>>>> No, it is not.  You just didn't read the entire thread.
>>>>
>>>> I certainly did. You never gave a reason, only your opinion.
>>>>
>>>>> But I'm also not going to reply to you on this topic any more.  My
>>>>> mother always told me "Don't try to teach a pig to sing.  It wastes
>>>>> your time and annoys the pig."
>>>>>
>>>>> So say whatever you want.  I won't reply.
>>>>
>>>> You won't, because you don't have an answer.
>>>>
>>>> Is there anyone else reading here who thinks Jerry is correct? And
>>>> why?
>>>
>>> Wasn't going to jump into this, but why not...
>>>
>>> I do not think Jerry is correct.
>>>
>>> I have watched every post Jerry has ever made on the subject and have 
>>> not
>>> yet (unless I have missed one or two) found anything to substantiate the
>>> claim other then a self-proclaimed assertion that it "is a security 
>>> issue",
>>> along with some vague assertion that people who write .html files are 
>>> less
>>> concerned with security than those who write .php files, as if a 
>>> bloody file
>>> extension matters.
>>>
>>> I have a couple of legacy sites I administer. Small ones (not like 
>>> Jerrys
>>> "corporate" sites"). Half a dozen pages. These needed jazzing up and 
>>> one of
>>> the results was that every single HTML file ended up containing PHP, 
>>> along
>>> with the several new ones added.
>>>
>>> What to do? Fiddle with mod-rewrite rules to map .html to .php and 
>>> totally
>>> confuse myself - ah, am I really editing .php and looking at .html 
>>> with my
>>> browser or the other way round.
>>>
>>> No. Simply use the Addtype directive in a .htaccess file to cause 
>>> html, and
>>> in these cases, .htm files to be parsed by PHP.
>>>
>>> And no, Jerry, I could not simply rename the htm files to .php. One 
>>> of these
>>> sites is a very large tennis club site with thousands of people with
>>> bookmarks to the various pages, and with a quite large google entry 
>>> as well.
>>>
>>> Please, Jerry, tell me exactly why what I have done is a "very bad 
>>> idea".
>>>
>>>
>>>
>> Not to support anyone one way or the other. But when you make the 
>> server parse an .html file for .php it places a greater work load on 
>> the server more so than if the server know if the file was a .php  
>> When you make these changes the server no has to parse each and every 
>> file for .php code. It slows the server by causing un-necessary work.  
>> Many web host will not allow this or for that matter using .shtml in 
>> the same fashion.  It is just a bad idea from the git go.  Of course 
>> there are always time where one really doesn't have much of a choice 
>> in the matter.
>>
>>
> 
> 
> its not such a big deal load wise. Yes, a php process springs up, but 
> its no big deal.
> 

But it really is a big deal - starting a new PHP thread/process amounts 
to considerable work in setting up the environment.

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

Beauregard T. Shagnasty wrote:
> David wrote:
> 
>> Beauregard T. Shagnasty wrote:
>>> Jerry Stuckle wrote:
>>> [Norman wrote:]
>>>>> AddHandler php5-script .html .php .mycustomextension
>>>> And is a very bad idea.
>>> You keep saying that. Provide a cite.
>> If you do that the server than has to parse each and every file for
>> php code. This in turns makes the server work harder and servers out
>> the information slower.
> 
> MasonC asked this question in c.i.w.a.s. first, where I answered "if you
> only have a couple of PHP scripts you want as .html, then place them in
> a separate directory and add the .htaccess AddHandler in that one
> (sub)directory. Leave all your pure .html files where they are." So, the
> amount of extra processing would be less than miniscule.
> 
> If, like most PHP-style sites, all files use standard includes for the
> banner/nav/footer etc, there would again be miniscule additional
> processing for using the .html file extension.
> 
>>  This is just a bad idea from the start.
> 
> Not if given a bit of thought. It's (.html extension) certainly not the
> super-bad security issue Jerry is stuck on.
> 
>> Also many web host will not allow you to do that.
> 
> I would find a better web host!   :-)   (Mine all allow it.)
> 

Please let us know which hosts you use so we can avoid them at all costs!

And your just proving how little you understand about security by your 
denial that it is a risk.

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

Jerry Stuckle wrote:

> As I said - always assume ...

Jerry -- you said, "So say whatever you want.  I won't reply."  Had you
forgotten?  

How about answering the questions next time?  Those in my paragraph
beginning with "If you, as a hacker, ..." ?

-- 
   -bts
   -Four wheels carry the body; two wheels move the soul

On 06/07/2010 08:50 AM, Jerry Stuckle wrote:
> This is so funny coming from a complete idiot who won't use his real
> name.

You have no idea how much times I have read that from trolls from groups 
of my country... when they have no arguments left.

> That's because he isn't the programmer or engineer he claims to be

OK. So I cannot be a programmer if I do not use my real name. Simply 
Brilliant.

> - only an out of work ditch digger who can't figure out which end of the
> shovel to use.

Nonsense.

> Your credibility on usenet is exactly ZERO, TNP. Yet you continue to
> espouse your ignorance on a daily basis.

Nonsense.

> Some people just never learn.

Absolutely Right.

Beauregard T. Shagnasty wrote:
> Jerry Stuckle wrote:
> 
>> As I said - always assume ...
> 
> Jerry -- you said, "So say whatever you want.  I won't reply."  Had you
> forgotten?  
> 
> How about answering the questions next time?  Those in my paragraph
> beginning with "If you, as a hacker, ..." ?
> 

Because your question is immaterial.  I am not a hacker.  But I know how 
to prevent most hacking.

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

On 06/07/2010 05:24 PM, Jerry Stuckle wrote:
> Beauregard T. Shagnasty wrote:
>> Jerry Stuckle wrote:
>>
>>> As I said - always assume ...
>>
>> Jerry -- you said, "So say whatever you want. I won't reply." Had you
>> forgotten?
>> How about answering the questions next time? Those in my paragraph
>> beginning with "If you, as a hacker, ..." ?
>>
>
> Because your question is immaterial. I am not a hacker. But I know how
> to prevent most hacking.
>

Knowing how to prevent hacking implies knowing hacking methods I guess?

Marious Barrier wrote:
> On 06/07/2010 08:50 AM, Jerry Stuckle wrote:
>> This is so funny coming from a complete idiot who won't use his real
>> name.
> 
> You have no idea how much times I have read that from trolls from groups 
> of my country... when they have no arguments left.
> 
>> That's because he isn't the programmer or engineer he claims to be
> 
> OK. So I cannot be a programmer if I do not use my real name. Simply 
> Brilliant.
> 
>> - only an out of work ditch digger who can't figure out which end of the
>> shovel to use.
> 
> Nonsense.

Well at least it would be an honourable profession I wouldn't be ashamed 
to admit to. I DID dig a small ditch once. Of course as any ditch digger 
knows, a shovel is not the correct tool to use. You don't DIG with a 
SHOVEL, you DIG with a Spade,  and SHOVEL with a SHOVEL.

That's all they let Jerry do, Shovel. And he was so crap at that cos he 
desperately wanted to be a ditch DIGGER not a shit shoveller, but them's 
the breaks, Jerry. You get to do what you are good at, and in your case 
that's just boasting.

> 
>> Your credibility on usenet is exactly ZERO, TNP. Yet you continue to
>> espouse your ignorance on a daily basis.
> 
> Nonsense.

Oh! Oh oh! Didn't I tell you exactly what Jerrykins would say!

Come on! Stalk me again!


> 
>> Some people just never learn.
> 
> Absolutely Right.


Oh bliss. Didn't Jerry perform exactly on cue and exactly as predicted?

He is a bless isn't he?

Clockwork clown, wind him up and watch him do his little routine.

I guess I must have been bored today. But its worth it if you haven't 
seen it before.

Watching the fat bits wobble, and the whole strutting bit.

Marious Barrier wrote:
> On 06/07/2010 05:24 PM, Jerry Stuckle wrote:
>> Beauregard T. Shagnasty wrote:
>>> Jerry Stuckle wrote:
>>>
>>>> As I said - always assume ...
>>>
>>> Jerry -- you said, "So say whatever you want. I won't reply." Had you
>>> forgotten?
>>> How about answering the questions next time? Those in my paragraph
>>> beginning with "If you, as a hacker, ..." ?
>>>
>>
>> Because your question is immaterial. I am not a hacker. But I know how
>> to prevent most hacking.
>>
> 
> Knowing how to prevent hacking implies knowing hacking methods I guess?

Not really. he's not that good. He just took the course and read up the 
course notes.

Marious Barrier wrote:
> On 06/07/2010 05:24 PM, Jerry Stuckle wrote:
>> Beauregard T. Shagnasty wrote:
>>> Jerry Stuckle wrote:
>>>
>>>> As I said - always assume ...
>>>
>>> Jerry -- you said, "So say whatever you want. I won't reply." Had you
>>> forgotten?
>>> How about answering the questions next time? Those in my paragraph
>>> beginning with "If you, as a hacker, ..." ?
>>>
>>
>> Because your question is immaterial. I am not a hacker. But I know how
>> to prevent most hacking.
>>
> 
> Knowing how to prevent hacking implies knowing hacking methods I guess?

Yes, it does.

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

Marious Barrier wrote:
> On 06/07/2010 08:50 AM, Jerry Stuckle wrote:
>> This is so funny coming from a complete idiot who won't use his real
>> name.
> 
> You have no idea how much times I have read that from trolls from groups 
> of my country... when they have no arguments left.
> 

Then I must assume you are eminently familiar with TNP.

>> That's because he isn't the programmer or engineer he claims to be
> 
> OK. So I cannot be a programmer if I do not use my real name. Simply 
> Brilliant.
>

Nope.  But TNP has proven too many times he's neither a programmer nor 
the engineer he claims to be.  His ignorance is astounding.

>> - only an out of work ditch digger who can't figure out which end of the
>> shovel to use.
> 
> Nonsense.
> 

And you know how?  Maybe you are TNP using another nym?

>> Your credibility on usenet is exactly ZERO, TNP. Yet you continue to
>> espouse your ignorance on a daily basis.
> 
> Nonsense.
> 

Now I would guess you really are TNP under another nym.

>> Some people just never learn.
> 
> Absolutely Right.

And then there are trolls who have to but in and spew their ignorance.

I would suggest you go back and look who started this TNP shit - here's 
a hint.  It wasn't me.  But I will continue to call him out when he 
spews his bullshit on unsuspecting newbies.



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

On 06/07/2010 07:13 PM, Jerry Stuckle wrote:
> Marious Barrier wrote:
>> On 06/07/2010 05:24 PM, Jerry Stuckle wrote:
>>> Beauregard T. Shagnasty wrote:
>>>> Jerry Stuckle wrote:
>>>>
>>>>> As I said - always assume ...
>>>>
>>>> Jerry -- you said, "So say whatever you want. I won't reply." Had you
>>>> forgotten?
>>>> How about answering the questions next time? Those in my paragraph
>>>> beginning with "If you, as a hacker, ..." ?
>>>>
>>>
>>> Because your question is immaterial. I am not a hacker. But I know how
>>> to prevent most hacking.
>>>
>>
>> Knowing how to prevent hacking implies knowing hacking methods I guess?
>
> Yes, it does.
>

So we are all waiting for your answer to Beauregard�s paragraph.

Marious Barrier wrote:
> On 06/07/2010 07:13 PM, Jerry Stuckle wrote:
>> Marious Barrier wrote:
>>> On 06/07/2010 05:24 PM, Jerry Stuckle wrote:
>>>> Beauregard T. Shagnasty wrote:
>>>>> Jerry Stuckle wrote:
>>>>>
>>>>>> As I said - always assume ...
>>>>>
>>>>> Jerry -- you said, "So say whatever you want. I won't reply." Had you
>>>>> forgotten?
>>>>> How about answering the questions next time? Those in my paragraph
>>>>> beginning with "If you, as a hacker, ..." ?
>>>>>
>>>>
>>>> Because your question is immaterial. I am not a hacker. But I know how
>>>> to prevent most hacking.
>>>>
>>>
>>> Knowing how to prevent hacking implies knowing hacking methods I guess?
>>
>> Yes, it does.
>>
> 
> So we are all waiting for your answer to Beauregard�s paragraph.

As I said.  I am not a hacker.  And I do not tell people how to hack 
systems.

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

David wrote:
> On 06/07/2010 06:02 AM, rf wrote:
>> Beauregard T. Shagnasty wrote:
>>> Jerry Stuckle wrote:
>>
>>>>> In Message-ID:<hu0g2r$l6t$1@news.eternal-september.org>  you said,
>>>>> "People are generally less careful about what's in .htm(l) files
>>>>> on a site because those don't have any server-side scripting in
>>>>> them (other than SSI, etc.). " ...
>>>>>
>>>>> That is not an authoritative reason, and it's the only reason you
>>>>> gave.
>>>>
>>>> No, it is not.  You just didn't read the entire thread.
>>>
>>> I certainly did. You never gave a reason, only your opinion.
>>>
>>>> But I'm also not going to reply to you on this topic any more.  My
>>>> mother always told me "Don't try to teach a pig to sing.  It wastes
>>>> your time and annoys the pig."
>>>>
>>>> So say whatever you want.  I won't reply.
>>>
>>> You won't, because you don't have an answer.
>>>
>>> Is there anyone else reading here who thinks Jerry is correct? And
>>> why?
>>
>> Wasn't going to jump into this, but why not...
>>
>> I do not think Jerry is correct.
>>
>> I have watched every post Jerry has ever made on the subject and
>> have not yet (unless I have missed one or two) found anything to
>> substantiate the claim other then a self-proclaimed assertion that
>> it "is a security issue", along with some vague assertion that
>> people who write .html files are less concerned with security than
>> those who write .php files, as if a bloody file extension matters.
>>
>> I have a couple of legacy sites I administer. Small ones (not like
>> Jerrys "corporate" sites"). Half a dozen pages. These needed jazzing
>> up and one of the results was that every single HTML file ended up
>> containing PHP, along with the several new ones added.
>>
>> What to do? Fiddle with mod-rewrite rules to map .html to .php and
>> totally confuse myself - ah, am I really editing .php and looking at
>> .html with my browser or the other way round.
>>
>> No. Simply use the Addtype directive in a .htaccess file to cause
>> html, and in these cases, .htm files to be parsed by PHP.
>>
>> And no, Jerry, I could not simply rename the htm files to .php. One
>> of these sites is a very large tennis club site with thousands of
>> people with bookmarks to the various pages, and with a quite large
>> google entry as well. Please, Jerry, tell me exactly why what I have done 
>> is a "very bad
>> idea".
> Not to support anyone one way or the other. But when you make the
> server parse an .html file for .php it places a greater work load on
> the server more so than if the server know if the file was a .php When you 
> make these changes the server no has to parse each and every
> file for .php code. It slows the server by causing un-necessary work.
> Many web host will not allow this or for that matter using .shtml in
>  the same fashion. It is just a bad idea from the git go.  Of course
> there are always time where one really doesn't have much of a choice in 
> the matter.

Oh here we go again.

You missed the part above where I said that for the legacy sites I 
administer *every one of the whole six html files contains PHP and must be 
parsed by PHP.

If every single html file must be parsed for PHP then where is the overhead 
in parsing every html file for PHP.

I set up a very specific scenario, well, I didn't set up, it was handed to 
me, and I asked Jerry why what I did was wrong. He didn't. Just blathered on 
about security.

Well, on this site there is no real need for security. It's a bloody six 
page tennis club site. The mose serious security breach would be somebody 
making off with last Thursday Mixed Doubles scores.

Jerry Stuckle wrote:

> Marious Barrier wrote:
>> So we are all waiting for your answer to Beauregard�s paragraph.
> 
> As I said.  I am not a hacker.  And I do not tell people how to hack
> systems.

It is obvious, Jerry, that you cannot answer the questions. This proves
that using the .htaccess AddHandler and .html files with PHP is not a
security risk.

You don't have to post here *how* to hack systems, only to answer the
questions as to how someone/anyone could load a rogue .html file if this
person had not already penetrated the site.

-- 
   -bts
   -Four wheels carry the body; two wheels move the soul

Beauregard T. Shagnasty wrote:
> Jerry Stuckle wrote:
> 
>> Marious Barrier wrote:
>>> So we are all waiting for your answer to Beauregard�s paragraph.
>> As I said.  I am not a hacker.  And I do not tell people how to hack
>> systems.
> 
> It is obvious, Jerry, that you cannot answer the questions. This proves
> that using the .htaccess AddHandler and .html files with PHP is not a
> security risk.
> 
> You don't have to post here *how* to hack systems, only to answer the
> questions as to how someone/anyone could load a rogue .html file if this
> person had not already penetrated the site.
> 

I can.  And telling you how someone could load a rogue file IS telling 
you how to hack a system.

But you're obviously too dense to understand such a simple concept.

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

Jerry Stuckle wrote:

> Beauregard T. Shagnasty wrote:
>> It is obvious, Jerry, that you cannot answer the questions. This
>> proves that using the .htaccess AddHandler and .html files with PHP
>> is not a security risk. 
>> 
>> You don't have to post here *how* to hack systems, only to answer
>> the questions as to how someone/anyone could load a rogue .html file
>> if this person had not already penetrated the site.
> 
> I can.  And telling you how someone could load a rogue file IS
> telling you how to hack a system. 

You're not getting it. If someone *could* upload a file to a site, that
someone has *already* penetrated the security. It has nothing to do with
what the file extension is, .html or .whatever.

> But you're obviously too dense to understand such a simple concept.

I need you to provide a cite for your opinion. Otherwise, it is nothing
more than your opinion - apparently only shared by you.

-- 
   -bts
   -Four wheels carry the body; two wheels move the soul

Beauregard T. Shagnasty wrote:
> Jerry Stuckle wrote:
> 
>> Beauregard T. Shagnasty wrote:
>>> It is obvious, Jerry, that you cannot answer the questions. This
>>> proves that using the .htaccess AddHandler and .html files with PHP
>>> is not a security risk. 
>>>
>>> You don't have to post here *how* to hack systems, only to answer
>>> the questions as to how someone/anyone could load a rogue .html file
>>> if this person had not already penetrated the site.
>> I can.  And telling you how someone could load a rogue file IS
>> telling you how to hack a system. 
> 
> You're not getting it. If someone *could* upload a file to a site, that
> someone has *already* penetrated the security. It has nothing to do with
> what the file extension is, .html or .whatever.
>

Which means that layered security is even more important.  As I have 
repeatedly said - good security ASSUMES AT LEAST ONE LAYER WILL FAIL!

>> But you're obviously too dense to understand such a simple concept.
> 
> I need you to provide a cite for your opinion. Otherwise, it is nothing
> more than your opinion - apparently only shared by you.
> 

Take a course on computer security.  I'm not going to try to teach a 
university level course in a newsgroup.  Learn about hacking.  Then 
learn how to prevent it.

And disregard my opinion all you want.  I really don't give a damn. 
It's not my sites - or my client's sites - which get hacked.

Remember - every site that has been hacked has had a 
webmaster/programmer/developer who thought "It couldn't happen to me".

Security means assuming it CAN and WILL happen.  And doing what you can 
to minimize the effects.

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

Beauregard T. Shagnasty wrote:
> Jerry Stuckle wrote:
>
>> Beauregard T. Shagnasty wrote:
>>> It is obvious, Jerry, that you cannot answer the questions. This
>>> proves that using the .htaccess AddHandler and .html files with PHP
>>> is not a security risk.
>>>
>>> You don't have to post here *how* to hack systems, only to answer
>>> the questions as to how someone/anyone could load a rogue .html file
>>> if this person had not already penetrated the site.
>>
>> I can.  And telling you how someone could load a rogue file IS
>> telling you how to hack a system.
>
> You're not getting it. If someone *could* upload a file to a site,
> that someone has *already* penetrated the security. It has nothing to
> do with what the file extension is, .html or .whatever.
>
>> But you're obviously too dense to understand such a simple concept.
>
> I need you to provide a cite for your opinion. Otherwise, it is
> nothing more than your opinion - apparently only shared by you.

Give it up Beauregard. From this point you will never, ever, get an answer 
to your question, just like I won't. Once it goes ad hominem all bets are 
off.

Move along now... There's nothing more to see here... 

rf wrote:
> Beauregard T. Shagnasty wrote:
>> Jerry Stuckle wrote:
>>
>>> Beauregard T. Shagnasty wrote:
>>>> It is obvious, Jerry, that you cannot answer the questions. This
>>>> proves that using the .htaccess AddHandler and .html files with PHP
>>>> is not a security risk.
>>>>
>>>> You don't have to post here *how* to hack systems, only to answer
>>>> the questions as to how someone/anyone could load a rogue .html file
>>>> if this person had not already penetrated the site.
>>> I can.  And telling you how someone could load a rogue file IS
>>> telling you how to hack a system.
>> You're not getting it. If someone *could* upload a file to a site,
>> that someone has *already* penetrated the security. It has nothing to
>> do with what the file extension is, .html or .whatever.
>>
>>> But you're obviously too dense to understand such a simple concept.
>> I need you to provide a cite for your opinion. Otherwise, it is
>> nothing more than your opinion - apparently only shared by you.
> 
> Give it up Beauregard. From this point you will never, ever, get an answer 
> to your question, just like I won't. Once it goes ad hominem all bets are 
> off.
> 
> Move along now... There's nothing more to see here... 
> 
> 

You've gotten your answers - learn about real security and you'll 
understand.  But I'm not about to try to teach anyone all about it in a 
newsgroup.

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

On 06/07/2010 08:41 PM, Jerry Stuckle wrote:
> rf wrote:
>> Beauregard T. Shagnasty wrote:
>>> Jerry Stuckle wrote:
>>>
>>>> Beauregard T. Shagnasty wrote:
>>>>> It is obvious, Jerry, that you cannot answer the questions. This
>>>>> proves that using the .htaccess AddHandler and .html files with PHP
>>>>> is not a security risk.
>>>>>
>>>>> You don't have to post here *how* to hack systems, only to answer
>>>>> the questions as to how someone/anyone could load a rogue .html file
>>>>> if this person had not already penetrated the site.
>>>> I can. And telling you how someone could load a rogue file IS
>>>> telling you how to hack a system.
>>> You're not getting it. If someone *could* upload a file to a site,
>>> that someone has *already* penetrated the security. It has nothing to
>>> do with what the file extension is, .html or .whatever.
>>>
>>>> But you're obviously too dense to understand such a simple concept.
>>> I need you to provide a cite for your opinion. Otherwise, it is
>>> nothing more than your opinion - apparently only shared by you.
>>
>> Give it up Beauregard. From this point you will never, ever, get an
>> answer to your question, just like I won't. Once it goes ad hominem
>> all bets are off.
>>
>> Move along now... There's nothing more to see here...
>>
>
> You've gotten your answers - learn about real security and you'll
> understand. But I'm not about to try to teach anyone all about it in a
> newsgroup.
>

Yes Jerry, yes...

rf wrote:

> Give it up Beauregard. From this point you will never, ever, get an
> answer to your question, just like I won't. Once it goes ad hominem
> all bets are off. 
> 
> Move along now... There's nothing more to see here...

I suppose you're right.  I thought it would have been a simple question
for him to answer.

-- 
   -bts
   -Four wheels carry the body; two wheels move the soul

On 06/07/2010 04:52 PM, rf wrote:
> David wrote:
>> On 06/07/2010 06:02 AM, rf wrote:
>>> Beauregard T. Shagnasty wrote:
>>>> Jerry Stuckle wrote:
>>>
>>>>>> In Message-ID:<hu0g2r$l6t$1@news.eternal-september.org>   you said,
>>>>>> "People are generally less careful about what's in .htm(l) files
>>>>>> on a site because those don't have any server-side scripting in
>>>>>> them (other than SSI, etc.). " ...
>>>>>>
>>>>>> That is not an authoritative reason, and it's the only reason you
>>>>>> gave.
>>>>>
>>>>> No, it is not.  You just didn't read the entire thread.
>>>>
>>>> I certainly did. You never gave a reason, only your opinion.
>>>>
>>>>> But I'm also not going to reply to you on this topic any more.  My
>>>>> mother always told me "Don't try to teach a pig to sing.  It wastes
>>>>> your time and annoys the pig."
>>>>>
>>>>> So say whatever you want.  I won't reply.
>>>>
>>>> You won't, because you don't have an answer.
>>>>
>>>> Is there anyone else reading here who thinks Jerry is correct? And
>>>> why?
>>>
>>> Wasn't going to jump into this, but why not...
>>>
>>> I do not think Jerry is correct.
>>>
>>> I have watched every post Jerry has ever made on the subject and
>>> have not yet (unless I have missed one or two) found anything to
>>> substantiate the claim other then a self-proclaimed assertion that
>>> it "is a security issue", along with some vague assertion that
>>> people who write .html files are less concerned with security than
>>> those who write .php files, as if a bloody file extension matters.
>>>
>>> I have a couple of legacy sites I administer. Small ones (not like
>>> Jerrys "corporate" sites"). Half a dozen pages. These needed jazzing
>>> up and one of the results was that every single HTML file ended up
>>> containing PHP, along with the several new ones added.
>>>
>>> What to do? Fiddle with mod-rewrite rules to map .html to .php and
>>> totally confuse myself - ah, am I really editing .php and looking at
>>> .html with my browser or the other way round.
>>>
>>> No. Simply use the Addtype directive in a .htaccess file to cause
>>> html, and in these cases, .htm files to be parsed by PHP.
>>>
>>> And no, Jerry, I could not simply rename the htm files to .php. One
>>> of these sites is a very large tennis club site with thousands of
>>> people with bookmarks to the various pages, and with a quite large
>>> google entry as well. Please, Jerry, tell me exactly why what I have done
>>> is a "very bad
>>> idea".
>> Not to support anyone one way or the other. But when you make the
>> server parse an .html file for .php it places a greater work load on
>> the server more so than if the server know if the file was a .php When you
>> make these changes the server no has to parse each and every
>> file for .php code. It slows the server by causing un-necessary work.
>> Many web host will not allow this or for that matter using .shtml in
>>   the same fashion. It is just a bad idea from the git go.  Of course
>> there are always time where one really doesn't have much of a choice in
>> the matter.
>
> Oh here we go again.
>
> You missed the part above where I said that for the legacy sites I
> administer *every one of the whole six html files contains PHP and must be
> parsed by PHP.
>
> If every single html file must be parsed for PHP then where is the overhead
> in parsing every html file for PHP.

  Normally php will only parse and process files ending in .php  When 
you change it and tell the program to act as if ever page has php inside 
there is where the server load increases. The same way as if you were 
treating .shtml files this way.  As I also said in another post you may 
have no choice but to do this if you have php in every .htm/html file. 
If it were me I would go to all lengths to make sure that future pages 
be written in .php to begin with. If you need you can always include 
html code within a .php with out increasing the server load.  Of course 
this depends on just what your needs are.



>
> I set up a very specific scenario, well, I didn't set up, it was handed to
> me, and I asked Jerry why what I did was wrong. He didn't. Just blathered on
> about security.
>
> Well, on this site there is no real need for security. It's a bloody six
> page tennis club site. The mose serious security breach would be somebody
> making off with last Thursday Mixed Doubles scores.
>
>
>

On 06/07/2010 10:27 AM, Beauregard T. Shagnasty wrote:
> David wrote:
>
>> Beauregard T. Shagnasty wrote:
>>> Jerry Stuckle wrote:
>>> [Norman wrote:]
>>>>> AddHandler php5-script .html .php .mycustomextension
>>>>
>>>> And is a very bad idea.
>>>
>>> You keep saying that. Provide a cite.
>>
>> If you do that the server than has to parse each and every file for
>> php code. This in turns makes the server work harder and servers out
>> the information slower.
>
> MasonC asked this question in c.i.w.a.s. first, where I answered "if you
> only have a couple of PHP scripts you want as .html, then place them in
> a separate directory and add the .htaccess AddHandler in that one
> (sub)directory. Leave all your pure .html files where they are." So, the
> amount of extra processing would be less than miniscule.

Very good point!

>
> If, like most PHP-style sites, all files use standard includes for the
> banner/nav/footer etc, there would again be miniscule additional
> processing for using the .html file extension.
>
>>   This is just a bad idea from the start.
>
> Not if given a bit of thought. It's (.html extension) certainly not the
> super-bad security issue Jerry is stuck on.
>
>> Also many web host will not allow you to do that.
>
> I would find a better web host!   :-)   (Mine all allow it.)
>

David wrote:
> On 06/07/2010 04:52 PM, rf wrote:
>> David wrote:
>>> On 06/07/2010 06:02 AM, rf wrote:
>>>> Beauregard T. Shagnasty wrote:
>>>>> Jerry Stuckle wrote:
>>>>
>>>>>>> In Message-ID:<hu0g2r$l6t$1@news.eternal-september.org>   you
>>>>>>> said, "People are generally less careful about what's in
>>>>>>> .htm(l) files on a site because those don't have any
>>>>>>> server-side scripting in them (other than SSI, etc.). " ...
>>>>>>>
>>>>>>> That is not an authoritative reason, and it's the only reason
>>>>>>> you gave.
>>>>>>
>>>>>> No, it is not.  You just didn't read the entire thread.
>>>>>
>>>>> I certainly did. You never gave a reason, only your opinion.
>>>>>
>>>>>> But I'm also not going to reply to you on this topic any more. My 
>>>>>> mother always told me "Don't try to teach a pig to sing.  It
>>>>>> wastes your time and annoys the pig."
>>>>>>
>>>>>> So say whatever you want.  I won't reply.
>>>>>
>>>>> You won't, because you don't have an answer.
>>>>>
>>>>> Is there anyone else reading here who thinks Jerry is correct? And
>>>>> why?
>>>>
>>>> Wasn't going to jump into this, but why not...
>>>>
>>>> I do not think Jerry is correct.
>>>>
>>>> I have watched every post Jerry has ever made on the subject and
>>>> have not yet (unless I have missed one or two) found anything to
>>>> substantiate the claim other then a self-proclaimed assertion that
>>>> it "is a security issue", along with some vague assertion that
>>>> people who write .html files are less concerned with security than
>>>> those who write .php files, as if a bloody file extension matters.
>>>>
>>>> I have a couple of legacy sites I administer. Small ones (not like
>>>> Jerrys "corporate" sites"). Half a dozen pages. These needed
>>>> jazzing up and one of the results was that every single HTML file ended 
>>>> up
>>>> containing PHP, along with the several new ones added.
>>>>
>>>> What to do? Fiddle with mod-rewrite rules to map .html to .php and
>>>> totally confuse myself - ah, am I really editing .php and looking
>>>> at .html with my browser or the other way round.
>>>>
>>>> No. Simply use the Addtype directive in a .htaccess file to cause
>>>> html, and in these cases, .htm files to be parsed by PHP.
>>>>
>>>> And no, Jerry, I could not simply rename the htm files to .php. One
>>>> of these sites is a very large tennis club site with thousands of
>>>> people with bookmarks to the various pages, and with a quite large
>>>> google entry as well. Please, Jerry, tell me exactly why what I
>>>> have done is a "very bad
>>>> idea".
>>> Not to support anyone one way or the other. But when you make the
>>> server parse an .html file for .php it places a greater work load on
>>> the server more so than if the server know if the file was a .php
>>> When you make these changes the server no has to parse each and
>>> every file for .php code. It slows the server by causing un-necessary
>>> work. Many web host will not allow this or for that matter using
>>>   .shtml in the same fashion. It is just a bad idea from the git
>>> go.  Of course there are always time where one really doesn't have much 
>>> of a
>>> choice in the matter.
>>
>> Oh here we go again.
>>
>> You missed the part above where I said that for the legacy sites I
>> administer *every one of the whole six html files contains PHP and
>> must be parsed by PHP.
>>
>> If every single html file must be parsed for PHP then where is the
>> overhead in parsing every html file for PHP.
>
>  Normally php will only parse and process files ending in .php  When
> you change it and tell the program to act as if ever page has php
> inside there is where the server load increases.

David. Read this very carefully.

You have a point regarding huge corporate sites, but I presented my scenario 
as an example of a real world smallish site making the transition to PHP and 
I posed a question, which still has not been answered satisfactorily.

Now:

There are six existing .html files on that site.

Every one of those six  .html files has php in it now and so must be parsed 
by PHP.

I can change the names of the files to .php and thus break thousands of 
peoples bookmarks.

Or I can process the html files as if they were php files. There is *no* 
increase in server load over renaming the six files to .php. None at all. 
Each and every file on that site, .php or .html (or .html renamed to .php) 
must be parsed by php anyway. I could call them .anybloddything and add a 
line to .htaccess to have that parsed by php as well there *still* would be 
no overhead.

> The same way as if
> you were treating .shtml files this way.

FFS it's a tennis club. There is no shtml. There is no need for security. 
Somebody could trash the entire thing and we'd just re-load it from last 
nights backup. And who is going to hack into the site to steal the quite 
visible tennis scores. And I don't give a damn if somebody looks at the PHP. 
It's stock standard stuff anyway. There is more complex stuff in the 
examples in the manual.

> As I also said in another
> post you may have no choice but to do this if you have php in every
> .htm/html file.

That's what I said several posts ago.

> If it were me I would go to all lengths to make sure
> that future pages be written in .php to begin with.

That's what I said several posts ago.

> If you need you
> can always include html code within a .php with out increasing the
> server load.  Of course this depends on just what your needs are.


Whatever.

Wow, over the top replies much.

Q. What are the issues with modifying the PHP handler extension:

A. All the considerations you had to take with .php files you now have
to carry over to the new extension. That means:

1. Make sure users can't upload files with that extension (of course,
you should disable all handlers for you upload dir anyway. How many
people get caught out by .phtml, .php3, .php4...)

2. You will get a *significant* performance hit for that extension
type. For that reason it isn't ideal to set .html. Page loading times
will effect your Google rank, so yes, it can impact your SEO. *But* if
you're comfortable with the impact or you don't static cache anything
that's A-OK. You could, of course, use .asp, or .shtml, or .pl, if you
want to hide the fact you're using PHP, for example.

3. You'll have code portability issues

4. You'll need to keep track of your server configuration changes

There are entirely valid cases for using different handler extensions,
one of them being security by hiding the fact you're using PHP.

Yes, Jerry gets far too focused on his particular setup (as implied by
his first reply), but he has a point that it adds complexity which is
always a potential for problems. Of course, rf is making the same
mistake by only relating posts to his own experience, which isn't
helpful either.

In the final analysis:

Should you set your php handler to .html or .htm? Probably not, mostly
for performance reasons.

Is it insecure? Inherently, no, although misconfiguration can (as
always) cause issues.

Is it worth doing? Depends entirely on your configuration, but usually
not.

"Hamish Campbell" <hn.campbell@gmail.com> wrote in message 
news:cb0e0e66-c98d-4f6c-9e8d-c506cc127228@k17g2000pro.googlegroups.com...
> Wow, over the top replies much.

> 2. You will get a *significant* performance hit for that extension
> type.

Why? 

Beauregard T. Shagnasty wrote:
> Jerry Stuckle wrote:
> 
>> Marious Barrier wrote:
>>> So we are all waiting for your answer to Beauregard’s paragraph.
>> As I said.  I am not a hacker.  And I do not tell people how to hack
>> systems.
> 
> It is obvious, Jerry, that you cannot answer the questions. This proves
> that using the .htaccess AddHandler and .html files with PHP is not a
> security risk.
> 
> You don't have to post here *how* to hack systems, only to answer the
> questions as to how someone/anyone could load a rogue .html file if this
> person had not already penetrated the site.
> 
Look its just that Jerryt remembers the time he as working for a Big 
Organization and he renamed a PHP file to .HTML and the CEO saw all that 
code exposed to view, and hauled Jerry over the coals for it.

He thought it was a security risk because all that code was expensive 
and secret.

Go easy on jerry. He doesn't know any better.

On 8 lip, 06:17, Hamish Campbell <hn.campb...@gmail.com> wrote:
> 1. Make sure users can't upload files with that extension (of course,
> you should disable all handlers for you upload dir anyway. How many
> people get caught out by .phtml, .php3, .php4...)

I think it's better practice to keep "white list" of file extension
allowed to upload.

> 2. You will get a *significant* performance hit for that extension
> type.

Have you tested that?

> Page loading times will effect your Google rank

It can, which doesn't mean it will (renaming html to php extension
could affect page rank much more than adding extension to php
handler). Page loading speed is just one of many factors and it takes
small percentage in overall rank calculation.


Ivan

On Jun 8, 9:29=A0pm, Ivan S <ivan.sku...@gmail.com> wrote:
> On 8 lip, 06:17, Hamish Campbell <hn.campb...@gmail.com> wrote:
>
> > 1. Make sure users can't upload files with that extension (of course,
> > you should disable all handlers for you upload dir anyway. How many
> > people get caught out by .phtml, .php3, .php4...)
>
> I think it's better practice to keep "white list" of file extension
> allowed to upload.
>
> > 2. You will get a *significant* performance hit for that extension
> > type.
>
> Have you tested that?

Heh, not sufficiently.

Running PHP as an Apache module I get about a 4-5% speed hit. That's
only about 1-2ms on most pages. This is probably what you expect give
that the Apache thread is already running and it just has to run it
through the parser. Saying it was significant might have been
overstating it on my part :)

OTOH, it is my understanding (correct me if you know better) that PHP
as CGI will be much worse as the request has to be handled by a new
process.

> > Page loading times will effect your Google rank
>
> Page loading speed is just one of many factors and it takes
> small percentage in overall rank calculation.

Agreed.

Hamish Campbell <hn.campbell@gmail.com> wrote:

> Wow, over the top replies much.
> 
> Q. What are the issues with modifying the PHP handler extension:

<snip>

> 2. You will get a *significant* performance hit for that
> extension type.

It depends how PHP is running.  When running as a module, the 
performance hit is fairly minimal (but it still depends on your 
traffic load).

<snip>

> 4. You'll need to keep track of your server configuration
> changes 

You generally need to do this, regardless.

> There are entirely valid cases for using different handler
> extensions, one of them being security by hiding the fact you're
> using PHP. 

That isn't security, it's obfuscation.  Although it doesn't 
(necessarily) hurt, it may give newcomers a false sense of security.  
If you want security, you have to learn to implement sound designs 
in your code.  A relatively determined cracker can probably poke 
through most obfuscations in no time.

> Yes, Jerry gets far too focused on his particular setup (as
> implied by his first reply), but he has a point that it adds
> complexity which is always a potential for problems.

If I understand correctly, Jerry's main contention is that adding 
the PHP handler for .html files unnecessarily widens the possible 
attack vector.

> Of course,
> rf is making the same mistake by only relating posts to his own
> experience, which isn't helpful either.

On the contrary, hearing others' experiences is often very helpful.  
rf is *not* attempting to suggest that his situation was applicable 
for everyone else's.  AIUI, his main contention is that there can be 
some cases where using the PHP handler for different extensions is 
valid (he used his experience as supporting evidence).

While I generally feel Jerry's reasoning is a good rule of thumb, in 
carefully managed cases like rf's, it can be an acceptable solution.

An alternative solution, in rf's case, might be something like:

  # Where applicable, `RedirectMatch' would make dealing with
  # multiple resources easier
  Redirect seeother /index.html http://example.com/index.php
  ...

> In the final analysis:
> 
> Should you set your php handler to .html or .htm? Probably not,
> mostly for performance reasons.

I think the portability concern is probably more often the issue.  
It may be that you'd have to move to an environment in which you're 
unable to change PHP's handler.

> Is it insecure? Inherently, no, although misconfiguration can
> (as always) cause issues.

The main issue with security is for developers not fully aware of 
the issues.  Like many tools, server configuration should be handled 
with care.

> Is it worth doing? Depends entirely on your configuration, but
> usually not.

Agreed.

-- 
Curtis Dyer
<?$x='<?$x=%c%s%c;printf($x,39,$x,39);?>';printf($x,39,$x,39);?>

On 8 lip, 23:24, Hamish Campbell <hn.campb...@gmail.com> wrote:
> Running PHP as an Apache module I get about a 4-5% speed hit. That's
> only about 1-2ms on most pages.

OK, but I'm not sure did you test correctly. I'm having a feeling that
you tested static HTML pages VS dynamic PHP pages (and what's faster
should be obvious here). But you should test identical files - one
with "html" extension and other with "php" extension (both included
for PHP parsing).

That way you'll have real world example because you won't add PHP
handler to the HTML files if you won't use any PHP code in it (there
is no point in doing that). The subject of testing in that case
shouldn't be previous static HTML file, but "new" HTML file VS same
file with PHP extension (or some other solution for given problem).

Unfortunately, I don't have Apache & PHP installed on the computer
where I am now, so I can't test that for myself. :(


Ivan

On Jun 9, 8:16=A0pm, Ivan S <ivan.sku...@gmail.com> wrote:
> On 8 lip, 23:24, Hamish Campbell <hn.campb...@gmail.com> wrote:
>
> > Running PHP as an Apache module I get about a 4-5% speed hit. That's
> > only about 1-2ms on most pages.
>
> OK, but I'm not sure did you test correctly. I'm having a feeling that
> you tested static HTML pages VS dynamic PHP pages (and what's faster
> should be obvious here). But you should test identical files - one
> with "html" extension and other with "php" extension (both included
> for PHP parsing).

I created a file with a thousand lines of <p>This is a test</p> and no
other content, then copied it to .html and .php files. There were no
php tags to parse.

On Mon, 7 Jun 2010 12:19:45 -0400, Beauregard T. Shagnasty wrote:
> Jerry Stuckle wrote:
> [snippage]
>> I'm going to try this one more time for the dumb shits who couldn't
>> read the first time.
>
> Your debating tactics leave a lot to be desired, including calling
> anyone who disagrees with you a "dumb shit."
>
>> Good security is based on locking everything down tight and allowing
>> only what is absolutely necessary.  It is multi-layered, and assumes
>> at least one layer will fail.
>
> Perhaps. The problem with your comments in this (and that other) thread
> assume *more* than using an .htaccess directive, and/or implanting a
> rogue PHP script as a parsable .html file. In order to do those things
> you say are "insecure" already requires access to the host by some
> hacking method above and beyond the mere fact of parsing .html files as
> PHP.
>
> If you, as a hacker, did not already have unfettered access to the raw
> hosting server, how would you modify the .htaccess or load a rogue file?
> How would you know a site used the AddHandler directive without being
> able to read .htaccess?  And what scripting would you write in your
> rogue file in the first place, without knowing the internal structure of
> the site?
>
> You assume too much.

It doesn't have to be a hacker that makes the change. An authorized user
could delete the file accidentally, and not all OSs are discriminating
enough to protect from deletion files that a given user ID has no
write authority to if that user otherwise can delete files from that
directory.

-- 
48. I will treat any beast which I control through magic or technology
    with respect and kindness. Thus if the control is ever broken, it 
    will not immediately come after me for revenge.
	--Peter Anspach's list of things to do as an Evil Overlord

On 06/10/2010 09:25 AM, Peter H. Coffin wrote:
>
> It doesn't have to be a hacker that makes the change. An authorized user
> could delete the file accidentally, and not all OSs are discriminating
> enough to protect from deletion files that a given user ID has no
> write authority to if that user otherwise can delete files from that
> directory.
>

Should we then stop using files since they are not fully secure? lol

Peter H. Coffin wrote:

> It doesn't have to be a hacker that makes the change. An authorized
> user could delete the file accidentally, and not all OSs

What does an OS have to do with any of this?   <g>
Besides, a web host is running web server software, and the OS is
transparent.

> are discriminating enough to protect from deletion files that a given
> user ID has no write authority to if that user otherwise can delete
> files from that directory.

If a user is given access to the web host, that user can either do the
normal things 'webmasters' do, or wreak havoc if he has the desire.
Using PHP scripts with .html extensions has no consequence in this
matter. If you give someone access and they muck it up, whose fault is
that?

Your paragraph is difficult to parse...

-- 
   -bts
   -This poast is valid through December 21, 2012

Peter H. Coffin wrote:
> On Mon, 7 Jun 2010 12:19:45 -0400, Beauregard T. Shagnasty wrote:
>> Jerry Stuckle wrote:
>> [snippage]
>>> I'm going to try this one more time for the dumb shits who couldn't
>>> read the first time.
>> Your debating tactics leave a lot to be desired, including calling
>> anyone who disagrees with you a "dumb shit."
>>
>>> Good security is based on locking everything down tight and allowing
>>> only what is absolutely necessary.  It is multi-layered, and assumes
>>> at least one layer will fail.
>> Perhaps. The problem with your comments in this (and that other) thread
>> assume *more* than using an .htaccess directive, and/or implanting a
>> rogue PHP script as a parsable .html file. In order to do those things
>> you say are "insecure" already requires access to the host by some
>> hacking method above and beyond the mere fact of parsing .html files as
>> PHP.
>>
>> If you, as a hacker, did not already have unfettered access to the raw
>> hosting server, how would you modify the .htaccess or load a rogue file?
>> How would you know a site used the AddHandler directive without being
>> able to read .htaccess?  And what scripting would you write in your
>> rogue file in the first place, without knowing the internal structure of
>> the site?
>>
>> You assume too much.
> 
> It doesn't have to be a hacker that makes the change. An authorized user
> could delete the file accidentally,

That's Jerry then!

It helps protect him from his own incompetence. All now becomes clear.

Marious Barrier wrote:
> On 06/10/2010 09:25 AM, Peter H. Coffin wrote:
>>
>> It doesn't have to be a hacker that makes the change. An authorized user
>> could delete the file accidentally, and not all OSs are discriminating
>> enough to protect from deletion files that a given user ID has no
>> write authority to if that user otherwise can delete files from that
>> directory.
>>
> 
> Should we then stop using files since they are not fully secure? lol
Definitely.

Jerry said so, so it must be true (bandar log)