PHP-Yes, HTML-No --- Why?

Lennart Björk

Hi All,

I have a tiny program:

<!doctype HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<title>MyTitl e</title>
<meta http-equiv="Content-Type" content="text/html;
charset=iso-8859-1"/>
</head>
<body>

<?php
$host = $_SERVER['HTTP_HOST'];
$server = strtolower($hos t);

echo 'My variables<bg>';

echo("<br>Host: $host");
echo("<br>Serve r: $server");

?>
</body>
</html>

I upload it to my webserver as test.html and as test.php. Then I test
them in my webbrowser. The test.html does not work, but the test.php
does. Can someone tell me why?

Very confused
Lennart Björk

Jan 25 '06

Subscribe Reply

7038

« First
<
3
4
5
6
>

Andrew DeFaria

d wrote:

Here's a hint - they couldn't give a rat's ass what the extension is.

Not everyone, but some people. No most people! Take this thread as an example. You are arguing to have
..html at the end of every URL even if the file contains PHP or another
scripting language. At least 4 people in this thread alone disagree with
you. That would be 80% agree with me and 20% agree with you (with you,
the only person mind you, in your camp). By that very figure you are in
the minority and I'd venture to guess the the number of people who
really, really care about such trivial things such as yourself is
probably closer to .1% in the real population. And if you cater for those people, it suddenly gets very important. Yes to all of those neurotic people I supposed...
FTP requests are not HTTP. So what? Should all files that are ftp'ed have a .ftp extension?!?

We are talking about web servers, not FTP servers. I thought you
would understand that.

If your logic were to be taken consistently then would it not likewise
extend to to ftp? Come on Mr. Consistency!
When your browser gets files from ftp://, it's not a web browser
any more but an FTP client. No it's still a web browser, doing ftp protocol.

FTP is not part of the web. It's part of the internet, but not part
of the web. Again, I thought you would understand that.

I do understand that - but my browser also understands ftp protocols as
well as many other types (gopher (remember gopher), mailto (a pseudo
thing at best but still - it's in there), telnet, ftp and others. There
all part of the RFCs. Indeed the whole thing about the browser and the
World Wide Web was to tie these desperate, different and confusing to
the layperson protocols in a point and click interface. That's why URL's
were conceived and conceived to handle not just http, but other protocol
types. Just because http is the most popular does not mean it's the only
part of the web. Indeed that's one of the very reasons why the original
(well as of 3.0 and greater) Netscape included a mail reader, news
readers, etc.
I said pissing match, not pissing. A pissing match starts when somebody starts pissing junk.

Fantastic. Really great work.

Hey I can piss with the best of them - or, in this case, the worse of
them... :-)
I never said the server should parse MP3 files or whatever, as
I'm not generating them dynamically. What does it matter if you are doing it dynamically or not?

Apparently it does to you - as you want your dynamically-generated
content to be called .php, as that's how it should be "by design".

I see no reason to change the fact that this web page came from a file
that had a .php extension. Indeed I see it as useful in that it is a
sign that the content is dynamic and/or generated as opposed to static.
By renaming things to html you lose that distinction, which can be
helpful at times.

The point about MP3 files is that if you configure your web server to
treat every file as potentially having dynamic content and that it
should search through the entire file looking to determine exactly which
language might be in use in the file and hand it off to the appropriate
parser, interpreter or module then you are gonna have to contend with
the fact that occasionally (and on some sites much more than
occasionally) you're gonna be charging the web server with reading and
parsing potentially huge files - all in the name of a foolish consistency. It's not a fetish. It's called presentation. No it's called necrosis! As for presentation what's important is
*CONTENT* stupid! Just because you can't care less doesn't mean those visiting your site
don't. As I said, I've never, ever had anybody say "Great site but I won't use
it until they have URL's that end in .html".
My tests have shown, to me at least, that the performance hit is
a myth. For 150 files, perhaps.

Repeatedly, about 50 times.

Yes, right, only after 3 of use pointed out that 150 files are not
statistically significant. Nor is 50 times of 150 files. A lot depends
on the sizes of the files, the configuration of the server, how much
memory is currently being used, how busy it is, etc. Again, your "test"
is not statistically significant. Come back to use after you've figured
out how to do thousands of hits a minute and run it for a few hours.
It's not wasteful. How could it not be? You do understand how computers work don't
you? You do understand that extra processing is indeed happening.
You do understand that under large numbers of accesses such small
differences in processing time add up don't you?!?

I also know how the PHP module works. I can see that the extra
processing is negligable compared to other factors affecting the
server. My tests have shown that.

No, they haven't. If what you say is true, my html test server should have repeatedly
out-performed the html-parsing one. It didn't. When you run such puny tests it's extremely hard to say. You are also
not in a controlled environment in any way, shape or form. A discrepancy
such as you claim can easily be explained but a small demand on the
server from anything from cron to a swap.
You wouldn't want your design sloppy, I don't find it sloppy. Indeed I find it very logical.

Logical from the web server's perspective, not the user's.

As a user I find your answer odd. I also find it logical from a user's
perspective. I would find it illogical for it to say .html when I know
that .html represents static HTML yet I got a dynamic page! As websites are coded to make the user happy, not the webserver,
that's a pretty poor excuse. Yes you are using pretty poor excuses! Stop that!
so why your URLs? The site is a whole - asking someone to ignore
the mess in the address bar because "it's just the way the web
server works" is a bit silly. It's supposed to work for you, not
the other way round :) Again, nobody cares about what characters are in the URL. If they
did they'd start screaming about the silly http:'s and the
&parm=<long assed string of junk characters> and the like. The
.php or .html at the end is one of the least things to be
concerned about!

Just saying "but nobody cares" doesn't make them not care.

3 other people have repeated what I said - Nobody cares. You are the
sole person saying that people care. That's a 80 to 20% against (guess
who?) - YOU. And as for the query string - I agree with you. I don't use query
strings. Your sites then must not have very much functionality or utility - but
their URLs look nice! ;-) Just because it's least concerning doesn't make it not concerning at
all. It's like making a painting and putting it in a crappy frame.

No, again, it's like making a painting then scribbling on the back of
the painting that nobody sees nor cares about.
--
If you take an Oriental person and spin him around several times, does
he become disoriented?

Jan 27 '06 #41

Andrew DeFaria

d wrote:

"Andrew DeFaria" <An****@DeFaria .com <mailto:An****@ DeFaria.com>>
wrote in message news:43******** *************** @news.sonic.net ...

d wrote:
It may be by design, but that doesn't mean it's necessarily good. In this case it does.

I still don't see how you can qualify that.

Nor have I seen any qualification of why it's bad (aside from the fact
that you, the one person in this thread, don't like it). I mean, the file doesn't contain php when the client gets it, so why
should it be named .php? Simple, because that was the filename that was requested to be fetched
by the web server!
Surely a dynamic web server should appear exactly the same as a
static one - all files that contain HTML when viewed should be
called .html. Again, why? Who cares (besides you)?

Because the server is serving up HTML, not PHP.

So fucking what! (Man you are dense!)
If you want them called any number of things, then be my guest.
I just happen to think presentation matters. Let's us know when you're done writing your great web server! :-(

I don't have to. It's called apache, and it does the trick perfectly.

I guess you're not done yet...
As for performance, the numbers are easy to compute. If you know
how, say, the PHP apache module works, you'll see that the hit is
absolutely, positively minimal. A 1/2 cent rise in the sales tax is also minimal - when looked at
under a microscope! However such things raise millions of dollars!

We're talking 0.04, not 0.5 :)

What the hell are you talking about?
If it was otherwise, the inherent overhead of processing dynamic
PHP files would stop people from using PHP on any old webserver. This argument holds no water whatsoever. PHP files will be
processed with PHP. The issue I was talking about is making each
and every file go through parsing even when no PHP is present.

I said just put .html files through, not every single file.

You're proposing to rename .php files to .html files. I guess we're
gonna rename .asp and .jsp files to that too. Hmmm... Maybe .cfm files
(Cold Fusion?) and .do (I've seen those too). Gee that web server's
gonna have much more work to do sorting that out.

And you're forgetting - PHP files can also be just PHP script designed
to run without a web server. So now PHP developers are gonna have to
name some files .html and others .php - nice consistency there Mr.
Consistency!
My scheme doesn't prevent anyone from using more than one
technology. It's not as if extensions are the only way of
determining what's in a file. Then you must make the httpd process overly complicated be having
it have to figure out, each and every time, any of a possibly
myriad of possible web scripting technologies.

Incorrect. As I said, the httpd process doesn't have to be overly
complicated. There extension is not the only way to determine what's
in a file.

If a web server has to parse through a file and look for different
tokens to denote which type of file it might possibly be it will be more
complex than the current typing system.
Your points aren't exactly showstoppers. And your one point is one of pure aesthetics!

Exactly.

Which means we can ignore it as it's pretty much meaningless. Again,
nobody cares about the damn URL extension here but you. Every other
poster in this thread disagrees with you. You are the exception to the
rule, the odd man out. By now you should be used to the fact that people
just do not agree with your opinion here and do not value this foolish
aesthetic distinction that you draw that really hold very little
utility. By the very definition and example of this thread any
reasonable person would deduce that in general most people don't care.
But bang your head against the wall if you must and jump up and down
stomping your feet if you want - it's actually quite comical. You
configure your web servers for your URL consistency and pat yourself on
the back. Whatever floats your boat. I have more important things to
waste my time with!
If you're confused by having php in html files, Who ever said that! I'm not stupid!

You said it was complex to have a web server configured this way. It
really isn't.

I didn't say it couldn't be done I said it would add complexity and
processing time for very little gain (i.e. foolish consistency to
satisfy the .1% of the pinheads out there).
you probably shouldn't be anywhere near a computer in case you
look at it funny and choke yourself to death. And you're the one getting bent out of shape because a file says
.php instead of .html. Who's confused here? (Hint: You are!)

How is that being confused?? I just want files named to reflect
what's in them. You wouldn't want your html files called .jpg, would you?
And as I said earlier, it doesn't stop anyone from using multiple
technologies at once,

Yes but it adds unnecessary complications and processing time
based on a whim that only you have!

No complications what so ever.

What so ever? Are you sure? When's your web server gonna be complete
there bud? The extra processing time, as I have demonstrated is nothing. You're demonstration is non conclusive. Sample size was too small. My tests showed that sometimes it's even quicker to do it this way,
which means that there are other factors that play a much bigger part
in performance, much more than parsing .html files. Or perhaps your machine was busy servicing others.
and if a web server struggles because it has to check html files
for php when there necessarily isn't any, It's not a struggle - it's a waste of time! Do you understand the
definition of the word efficient?!?

If you think presentation is a waste of time,

Presentation is in the page itself - not its address! then fine - I can't convince you otherwise. Nor the other 3 people here. You're batting 1000% - -1000%! Efficiency doesn't necessarily mean you end up with the best product. Who's talking about products. We're talking about Apache. That ain't
even sold!
then it's not going to be very good at running any complex php,
as that requires a LOT more work then just checking for "<?php"
in a file. Again, it's unnecessary work. You can't seem to understand that
simple concept.

I've demonstrated the "unnecessar y work" is absolutely, positively
nothing.

No you haven't.
Just because it's the "done thing" doesn't automatically make it
the best thing. Again, in this case it does. If not then make your own web server
and see who else in the planet is interested in such "technology ".
But don't quite your day gig!

Can you qualify these assertions.

I don't need too. You are the one making the claim. And you are
attempting to make it with a very unscientific nor statistically
significant sample. Look at it this way. I would venture to get that the
guys over at Apache know a hell of a lot more about writing web server
software than you. When you are writing such software you make trade
offs and decisions. They *decided* to make this trade off for the sake
of efficiency. Now why do you think they did that? Because it's true. Or
would you have us believe your tiny test of 150 files, even done 50
times, overrides the experience of these experts? IOW why do you think
they set it up this way? I've done tests, and I've seen that the performance hit is nothing. Tell ya what, package up your "test" and ship them over to the folks at
Apache along with a note saying "Why did you guys separate .html files
and .php files. Surely not for efficiency or complexity's sake. Look at
these numbers I have here...". After they get off the floor from rolling
around in laughter I'm sure they'll getting back to you! ;-) I don't have to make my own web server. You probably couldn't if you tried, which was my point - you don't know
the half of the story as to why this technical trade off was
implemented. Sure Apache allows you to configure it in the way you want
it but they warn direly not to do that because things will be slow. You
think they say that on a whim? Hey, perhaps they have a 151 file test! LOL! Apache was built to do just these things. The reason PHP moved from
CGI to a native apache module was for exactly this kind of thing. If
you don't understand the technology, then perhaps you shouldn't quit
your day job :) I understand it far better than you as you continually see fit to show
the world. PHP was moved into CGI because PHP was designed to be part of
an otherwise HTML file with the PHP intermixed. As such the web server
had to handle the reading and rendering of that HTML. It was also moved
in there for efficiency reasons instead of having to start a separate
PHP process, much like mod_perl.
If you don't want to take pride in your work and have messy URLs
with weird extensions that don't match the content and query
strings unreadable to humans stretching from here to the moon,
then be my guest. I measure my work by the quality of the content of the page itself
- not it's URL. To me, and everybody else in the world except
apparently you, I don't find .php as a weird extension (perhaps
because I understand it) nor as any more messier than .html. It's
you that have a fetish with that - not I.

I measure my work by the user experience.

I measure my work by user satisfaction. I don't want any dirty laundry out in the open. What they hell is so dirty about having a URL with a .php in it?!? I want complete control over every aesthetic, from the quality of the
HTML to the quality of the addressing. i.e. control freak and neurotic personally. I find .php a weird extension because the files don't contain a single
shred of php when the user gets them. Again, you might not like it but 99.9% of the rest of use don't care. And, after all, websites are about the user, not the sysadmin or the
developer.

Exactly, and if 99.9% of the users don't care and 80% of them have no
real idea of what a URL even is, then worrying about whether a file has
a .php or a .html extension is a true sign of neurotic behavior. Seek
good counsel...

--
I had a dream that all the victims of The Pill came back...boy, were
they mad!!

Jan 27 '06 #42

"Geoff Berrow" <bl******@ckdog .co.uk> wrote in message
news:1m******** *************** *********@4ax.c om...

Message-ID: <LY************ ****@text.news. blueyonder.co.u k> from d
contained the following:
The same thing a shop front has to do with a shop's interior :) It's part
of your "client-facing presence", and as such represents your company. I
can understand if other people don't feel like it represents them, but as
something of a stickler for details, it's something I notice.
In that case I wouldn't have .php or .html on customer facing stuff.
I'd use directories.

Indeed - it's the logical progression, and what I currently do.
--
Geoff Berrow (put thecat out to email)
It's only Usenet, no one dies.
My opinions, not the committee's, mine.
Simple RFDs http://www.ckdog.co.uk/rfdmaker/

Jan 27 '06 #43

"Andrew DeFaria" <An****@DeFaria .com> wrote in message news:43******** *************** @news.sonic.net ...
d wrote:
"Andrew DeFaria" <An****@DeFaria .com> wrote in message news:43******** *************** @news.sonic.net ...
d wrote:
It may be by design, but that doesn't mean it's necessarily good.

In this case it does.
I still don't see how you can qualify that.
Nor have I seen any qualification of why it's bad (aside from the fact that you, the one person in this thread, don't like it).

Because the files, when downloaded, are called .php and have absolutely no php in them :)

I mean, the file doesn't contain php when the client gets it, so why should it be named .php?

Simple, because that was the filename that was requested to be fetched by the web server!
But the extension doesn't match the contents of the file. The fact it's the extension of the file is no reason for the file to have that extension :) Circular logic is rarely a good reason for anything :)

Surely a dynamic web server should appear exactly the same as a static one - all files that contain HTML when viewed should be called ..html.

Again, why? Who cares (besides you)?
Because the server is serving up HTML, not PHP.

So fucking what! (Man you are dense!)
Because the files contain html, not php. That's pretty obvious. You may not think that's anything big, but presentation-wise it is big. If you request a .jpg, you expect to get a jpeg. If you request a .mpeg, you expect a movie. If you request a .mpeg and get a csv, that's not really cool.

If you want them called any number of things, then be my guest. I just happen to think presentation matters.
Let's us know when you're done writing your great web server! :-(
I don't have to. It's called apache, and it does the trick perfectly.

I guess you're not done yet...

What? :)

As for performance, the numbers are easy to compute. If you know how, say, the PHP apache module works, you'll see that the hit is absolutely, positively minimal.

A 1/2 cent rise in the sales tax is also minimal - when looked at under a microscope! However such things raise millions of dollars!
We're talking 0.04, not 0.5 :)

What the hell are you talking about?

If it was otherwise, the inherent overhead of processing dynamic PHP files would stop people from using PHP on any old webserver.
This argument holds no water whatsoever. PHP files will be processed with PHP. The issue I was talking about is making each and every file go through parsing even when no PHP is present.
I said just put .html files through, not every single file.

You're proposing to rename .php files to .html files. I guess we're gonna rename .asp and .jsp files to that too. Hmmm... Maybe .cfm files (Cold Fusion?) and .do (I've seen those too). Gee that web server's gonna have much more work to do sorting that out.

And you're forgetting - PHP files can also be just PHP script designed to run without a web server. So now PHP developers are gonna have to name some files .html and others .php - nice consistency there Mr. Consistency!

If they're not on a webserver, then they can be called .php. In fact, when I put my php files not on a webserver, say as scripts to be run from the windows command prompt, I call them .xphp, as I have a handler set up to automatically pass those files to the php executable when they're run, much like a .bat file and cmd.exe. We're talking about consistency in the web server here, from the client's perspective. You seem to forget the website is there for the client ;)

My scheme doesn't prevent anyone from using more than one technology. It's not as if extensions are the only way of determining what's in a file.
Then you must make the httpd process overly complicated be having it have to figure out, each and every time, any of a possibly myriad of possible web scripting technologies.
Incorrect. As I said, the httpd process doesn't have to be overly complicated. There extension is not the only way to determine what's in a file.

If a web server has to parse through a file and look for different tokens to denote which type of file it might possibly be it will be more complex than the current typing system.

I didn't say that. There are many ways to determine what's in a file, not just the contents, and not just the extension. It's really not difficult, not complex, and not uncommon.

Your points aren't exactly showstoppers.
And your one point is one of pure aesthetics!
Exactly.

Which means we can ignore it as it's pretty much meaningless. Again, nobody cares about the damn URL extension here but you. Every other poster in this thread disagrees with you. You are the exception to the rule, the odd man out. By now you should be used to the fact that people just do not agree with your opinion here and do not value this foolish aesthetic distinction that you draw that really hold very little utility. By the very definition and example of this thread any reasonable person would deduce that in general most people don't care. But bang your head against the wall if you must and jump up and down stomping your feet if you want - it's actually quite comical. You configure your web servers for your URL consistency and pat yourself on the back. Whatever floats your boat. I have more important things to waste my time with!

If you think aesthetics are meaningless, then your websites must look like shit. Just because no-one else cares about the extensions here, doesn't mean that no-one does. I can't help it if you aren't as exacting as some people. If you can't be bothered to address every aspect of your website, then why bother creating one?

If you're confused by having php in html files,
Who ever said that! I'm not stupid!
You said it was complex to have a web server configured this way. It really isn't.

I didn't say it couldn't be done I said it would add complexity and processing time for very little gain (i.e. foolish consistency to satisfy the .1% of the pinheads out there).

So you don't put line breaks in your HTML or CSS, as that's extra complexity and processing for very little gain. And as I demonstrated, the extra processing of parsing .html as php is absolutely minimal, to the point where tests can't even determine which one is quicker, as there are many, many other variables that have a much larger impact on performance than that.

you probably shouldn't be anywhere near a computer in case you look at it funny and choke yourself to death.
And you're the one getting bent out of shape because a file says ..php instead of .html. Who's confused here? (Hint: You are!)
How is that being confused?? I just want files named to reflect what's in them. You wouldn't want your html files called .jpg, would you?

And as I said earlier, it doesn't stop anyone from using multiple technologies at once,
Yes but it adds unnecessary complications and processing time based on a whim that only you have!
No complications what so ever.
What so ever? Are you sure? When's your web server gonna be complete there bud?

You keep banging on about that. I don't need to write a webserver. As I keep saying, Apache was designed to do just this. The PHP module for apache was designed to do just this. Just because you can't see how technology can be used doesn't automatically dismiss those who can. There are no complications. If you think it's complicated to have php code in files called .html, then you really do need help.

The extra processing time, as I have demonstrated is nothing.
You're demonstration is non conclusive. Sample size was too small.

150 documents at a time, repeated nearly 50 times? Too small? Then please - tell me what you want tested, and I'll test it, and give you the figures.

My tests showed that sometimes it's even quicker to do it this way, which means that there are other factors that play a much bigger part in performance, much more than parsing .html files.

Or perhaps your machine was busy servicing others.

It wasn't. I conducted the test as accurately as humanly possible, which of course meant no other sites were busy handling requests.

and if a web server struggles because it has to check html files for php when there necessarily isn't any,
It's not a struggle - it's a waste of time! Do you understand the definition of the word efficient?!?
If you think presentation is a waste of time,
Presentation is in the page itself - not its address!

So a great house on a shitty street is just as good as a great house on a great street?

then fine - I can't convince you otherwise.
Nor the other 3 people here. You're batting 1000% - -1000%!

Now who's talking about small sample sizes :)

Efficiency doesn't necessarily mean you end up with the best product.

Who's talking about products. We're talking about Apache. That ain't even sold!

The website is a product. You sure don't sound like you know much about commercial web development.

then it's not going to be very good at running any complex php, as that requires a LOT more work then just checking for "<?php" in a file.
Again, it's unnecessary work. You can't seem to understand that simple concept.
I've demonstrated the "unnecessar y work" is absolutely, positively nothing.

No you haven't.

I have.

Just because it's the "done thing" doesn't automatically make it the best thing.
Again, in this case it does. If not then make your own web server and see who else in the planet is interested in such "technology ". But don't quite your day gig!
Can you qualify these assertions.
I don't need too. You are the one making the claim. And you are attempting to make it with a very unscientific nor statistically significant sample. Look at it this way. I would venture to get that the guys over at Apache know a hell of a lot more about writing web server software than you. When you are writing such software you make trade offs and decisions. They decided to make this trade off for the sake of efficiency. Now why do you think they did that? Because it's true. Or would you have us believe your tiny test of 150 files, even done 50 times, overrides the experience of these experts? IOW why do you think they set it up this way?

Of course you need to. You can't just make an assertion then expect others to believe you without proving anything. Who do you think you are? The church? :) Apache didn't decide to make the trade-off. It's not hard-wired in apache. You just put ".html" after ".php" on the addhandler line. You really don't understand this, do you?

I've done tests, and I've seen that the performance hit is nothing.
Tell ya what, package up your "test" and ship them over to the folks at Apache along with a note saying "Why did you guys separate .html files and .php files. Surely not for efficiency or complexity's sake. Look at these numbers I have here...". After they get off the floor from rolling around in laughter I'm sure they'll getting back to you! ;-)

APACHE DON'T SEPERATE THE FILES! Jesus, man. Apache provide the mechanism for electing which extensions are parsed by which handlers. They don't write PHP, or even bundle it with their servers, so why on earth is it their decision to seperate the two? The two aren't even seperated, for crying out loud. Just because it shows in the example in the php manual that they only put .php doesn't mean that's how they only intended it to be used. If you only stick to the examples on the php website, your site will be incredibly basic, poorly coded, and slow as all hell.
I don't have to make my own web server.
You probably couldn't if you tried, which was my point - you don't know the half of the story as to why this technical trade off was implemented. Sure Apache allows you to configure it in the way you want it but they warn direly not to do that because things will be slow. You think they say that on a whim? Hey, perhaps they have a 151 file test! LOL!

Can you show me where they warn to not do that?

Apache was built to do just these things. The reason PHP moved from CGI to a native apache module was for exactly this kind of thing. If you don't understand the technology, then perhaps you shouldn't quit your day job :)

I understand it far better than you as you continually see fit to show the world. PHP was moved into CGI because PHP was designed to be part of an otherwise HTML file with the PHP intermixed. As such the web server had to handle the reading and rendering of that HTML. It was also moved in there for efficiency reasons instead of having to start a separate PHP process, much like mod_perl.

I'm not talking about CGI. I've never been talking about CGI here. I'm talking about the php apache module.

If you don't want to take pride in your work and have messy URLs with weird extensions that don't match the content and query strings unreadable to humans stretching from here to the moon, then be my guest.
I measure my work by the quality of the content of the page itself - not it's URL. To me, and everybody else in the world except apparently you, I don't find .php as a weird extension (perhaps because I understand it) nor as any more messier than .html. It's you that have a fetish with that - not I.
I measure my work by the user experience.
I measure my work by user satisfaction.

Which is directly proportional to user experience.

I don't want any dirty laundry out in the open.
What they hell is so dirty about having a URL with a .php in it?!?

Because the returned file never has any php in it.

I want complete control over every aesthetic, from the quality of the HTML to the quality of the addressing.
i.e. control freak and neurotic personally.

No, more like a perfectionist, or at least someone with pride in their work who doesn't just accept "the done thing" but seeks to find better ways of doing things.

I find .php a weird extension because the files don't contain a single shred of php when the user gets them.
Again, you might not like it but 99.9% of the rest of use don't care.

Clearly you do, as you're still banging on about how supposedly ridiculous it is.

And, after all, websites are about the user, not the sysadmin or the developer.

Exactly, and if 99.9% of the users don't care and 80% of them have no real idea of what a URL even is, then worrying about whether a file has a .php or a .html extension is a true sign of neurotic behavior. Seek good counsel...

It all depends on who your audience is for your website. If you're just writing some blog site or some tiny shop selling CDs, then sure - but if you're writing tools and sites for big clients (read: international banks, financial institutions, car manufacturers, universities, etc.), putting in bids against competing companies, and the contract is worth £100,000, then these things do matter.

--
I had a dream that all the victims of The Pill came back...boy, were they mad!!

Jan 27 '06 #44

"Andrew DeFaria" <An****@DeFaria .com> wrote in message news:43******** *************** @news.sonic.net ...
d wrote:

So you come up with a better test, sunshine.
It's your assertion therefore you are burdened with the prove.

Tell me what would satisfy you, and I'll test it. You seem rather quiet on that, though.

You asked me to do research, I did.
Oh I can say I times 2 files and it took 100% as long. Meaningful? No.

I gave you figures, and suddenly they're not good enough for you.

That's because you gave meaningless figures.

How are they meaningless? The sample size was good enough, the tests were performed enough times, the setups were identical apart from the variablel we were testing (the files served were even the same files on both sites). Please tell me how you would test it, and I'll do it that way.

And, in case you didn't notice, I did 150 files to give a 150x demonstration of the difference in required processing, not to represent the average load of the server.
The average load of the server is what's important.

I would argue the peak load is what's important, as that's when your server will start to fail.

Even someone with a basic grasp of statistics could see that. I never claimed I was representing your average webserver's daily load.
Then your proof is meaningless.

So tell me what to test, and I'll test it.

So I see you haven't written code for anything approaching massive sites, if you claim that. Thanks.
Yeah, where exactly do you see that?

All your silly questions like "what's a product - apache isn't even sold" etc. It really shows you've not been around people who are actually selling products to people, which you are in charge of developing.

Jan 27 '06 #45

"Steve" <Th*****@Aint.V alid> wrote in message
news:pa******** *************** *****@Aint.Vali d...

On Fri, 27 Jan 2006 00:52:31 +0000, d wrote:
"Michael Winter" <m.******@bluey onder.co.uk> wrote in message
news:D2******** *****@text.news .blueyonder.co. uk...
On 26/01/2006 17:43, d wrote:

Where to begin.

It would be nice if you started by not top-posting, but I don't think
that's a requirement of this particular group.

I don't want .php files on the end of my files, because when the user
gets them, they don't have any PHP in them.

Given that the average user isn't really aware of what HTML is, I
wouldn't
say that that was much of a reason to reconfigure a server in the way
you'd like.
I don't code sites for just your average user. If you're selling your
company, or indeed a product, to people who know, then things like this
speak very highly of the attention you pay to your work. It's like
making a
great watch, then using bits of old band-aids for a strap.

Don't know who you code for, but quality begins with w3c, not
url extensions.
That .PHP is there for my benefit, not theirs, which is unwanted. No, the php extension is there for the web servers benefit. No matter what
you say, parsing every page for the potential existence of code, and then
working out what it is *is* expensive.

My tests show that it is very very cheap, actually. Though please tell me
what tests you would like performed, and I will do that.
The programmers who generated apache decided on this method. They *do*
know more than you about serving web pages. I guarantee it.
If you were really concerned about this, wouldn't the best solution be
to remove 'extensions' from URLs entirely? If you want to relieve the
user of this 'burden', then hiding the mechanics should be the ultimate
goal.
Now you have it :) I moved from the .html-only set-up to my own site
engine, which does indeed do away with extensions altogether.

Non-apache web servers are off-topic for this group.

A site engine is not a web server. A site engine is a website framework
that sits on a web server of your choice. And why is it off-topic? I don't
see apache anywhere in the newsgroup name.

[snip]

My tests have shown, to me at least, that the performance hit is a
myth.

Perhaps, but you haven't actually stated what these tests specifically
entailed so no-one else can perform them and reproduce your results, or
even judge how relevant the tests are to their own circumstances.

I did. I hit two identical servers, one set to parse html via php, and
one not, repeatedly with sets of 150 requests (not just once, but many
times in a row), and recorded the times. The times fluctuated between
the html-parsing server being quicker, and the non-html-parsing server
being quicker.

150, wow! Lets try actually loading the server, eh? Were the requests
sequential or parallel? How about a real-world test - a couple of thousand
page hits per second should do as a start.

Then that's what I'll do. Finally someone has come up with their own
criteria :) Thanks very much.

[...] It's a more than reasonable trade-off for having a decent site,
with tidy URLs. Where is this site???
A decent site is determined by many things, but URLs have a relatively
low priority (usability and content clearly come first). Length and the
extent to which they can be remembered and transcribed are the most
important factors and 'extensions' don't impact any of these
significantly at all.

But once you have code great HTML, great CSS, great PHP, and you server
is quick, smooth and working well, it doesn't make sense to just stop
making your site better. I won't stop until my site is as perfect as
possible. My site engine uses ONLY human-readable urls. No digits, no
ridiculous query strings (in fact no query strings at all), and all can
be interpreted and even re-written by the user if they want.

No cookies, no session variables? I don't get why you think that a markup
language designed to be read by a machine should be pretty - in fact for
it to be as efficient as possible it should be as small as possible. So
that's on a single line with no indentation.

Indeed. Did I say the code was human-readable? nope. Just the URLs.

[snip]

Mike

dave
--
Michael Winter
Prefix subject with [News] before replying by e-mail.

Your presumptions are all wrong. You code for w3c first, then search
engines second.

And you do all you can to protect your server.

That goes without saying.
Steve

Jan 27 '06 #46

"Geoff Berrow" <bl******@ckdog .co.uk> wrote in message
news:l0******** *************** *********@4ax.c om...

Message-ID: <j9************ ****@text.news. blueyonder.co.u k> from d
contained the following:
I don't code sites for just your average user. If you're selling your
company, or indeed a product, to people who know, then things like this
speak very highly of the attention you pay to your work. It's like making
a
great watch, then using bits of old band-aids for a strap.
I think you are being massively oversensitive.

British telecom is the major telecommunicati ons provider in the UK When
I go to pay my bill I get this:

https://www2.bt.com/youraccount?coex...cefkdffndfkn.0

Which is nasty-looking. They also have shitty phone support - should no-one
strive to be better?
When I go to pay my gas bill:

http://www.house.co.uk/cgi-bin/house...ergy_acq_nov05

Electricity is a bit more friendly

http://www.npower.com/At_home/Custom...ll_online.aspx

No.html anywhere.

Now tell me, exactly what is worrying you about .php ?
Just because they don't do it doesn't mean it shouldn't be done :)
--
Geoff Berrow (put thecat out to email)
It's only Usenet, no one dies.
My opinions, not the committee's, mine.
Simple RFDs http://www.ckdog.co.uk/rfdmaker/

Jan 27 '06 #47

"Andrew DeFaria" <An****@DeFaria .com> wrote in message news:43******** *************** @news.sonic.net ...
d wrote:

I don't code sites for just your average user.
So then, by definition, you are the exception to the rule. No big deal really. But you shouldn't expect people to agree with you.

I don't. I never said I do.

If you're selling your company, or indeed a product, to people who know,
People who know and people who care are two entirely different worlds.

When they pay your bills, they are exactly the same :)

then things like this speak very highly of the attention you pay to your work.
Yeah it's says your a pinhead, hellbent on spending many resources for foolish consistencies.

"many resources" is a bit far-fetched. Saving documents as .html instead of .php is not "many resources".

It's like making a great watch, then using bits of old band-aids for a strap.

Hardly. It's more like making a great watch and then adorning it on the inside where nobody can really see it.

No, as people do see URLs. That's the essence of a website. People use them for marketing, put them on advers, print them on t-shirts, use them for tracking, etc.

If you were really concerned about this, wouldn't the best solution be to remove 'extensions' from URLs entirely? If you want to relieve the user of this 'burden', then hiding the mechanics should be the ultimate goal.

Now you have it :) I moved from the .html-only set-up to my own site engine, which does indeed do away with extensions altogether.

Where might that be?

umm on the web server? Where do you think? Under the kitchen sink? :)

But once you have code great HTML, great CSS, great PHP, and you server is quick, smooth and working well, it doesn't make sense to just stop making your site better.
You've neglected to define what "better" is. All you've said is that the URLs should end in .html. I've never heard a single person say to me "Yeah great site! But their URLs don't end in .html so I'm never going back" and I don't think you have every heard that either!

Better = as you want it. Making concessions on presentation due to perceived limitations of your setup is not "better".

I won't stop until my site is as perfect as possible.
A sure sign of a neurotic person!
Or someone bidding for a contract. Arguably they are the same ;)
--
I have six locks on my door all in a row. When I go out, I lock every other one. I figure no matter how long somebody stands there picking the locks, they are always locking three.

Jan 27 '06 #48

"Andrew DeFaria" <An****@DeFaria .com> wrote in message news:43******** *************** @news.sonic.net ...
d wrote:
Here's a hint - they couldn't give a rat's ass what the extension is.
Not everyone, but some people.
No most people! Take this thread as an example. You are arguing to have .html at the end of every URL even if the file contains PHP or another scripting language. At least 4 people in this thread alone disagree with you. That would be 80% agree with me and 20% agree with you (with you, the only person mind you, in your camp). By that very figure you are in the minority and I'd venture to guess the the number of people who really, really care about such trivial things such as yourself is probably closer to .1% in the real population.

Now who's talking about ridiculously small sample sizes. This is not a popularity contest. I am not so insecure as to require pats on the back from my peers to be confident in what I'm doing. I can look through my CV to see that I'm doing well. And I would hardly assume a usenet group dedicated to coding PHP as representative of the public at large :)

And if you cater for those people, it suddenly gets very important.
Yes to all of those neurotic people I supposed...

No, as I said - if they pay your bills, you don't leave anything to chance.

FTP requests are not HTTP.
So what? Should all files that are ftp'ed have a .ftp extension?!?
We are talking about web servers, not FTP servers. I thought you would understand that.

If your logic were to be taken consistently then would it not likewise extend to to ftp? Come on Mr. Consistency!

When your browser gets files from ftp://, it's not a web browser any more but an FTP client.
No it's still a web browser, doing ftp protocol.
FTP is not part of the web. It's part of the internet, but not part of the web. Again, I thought you would understand that.

I do understand that - but my browser also understands ftp protocols as well as many other types (gopher (remember gopher), mailto (a pseudo thing at best but still - it's in there), telnet, ftp and others. There all part of the RFCs. Indeed the whole thing about the browser and the World Wide Web was to tie these desperate, different and confusing to the layperson protocols in a point and click interface. That's why URL's were conceived and conceived to handle not just http, but other protocol types. Just because http is the most popular does not mean it's the only part of the web. Indeed that's one of the very reasons why the original (well as of 3.0 and greater) Netscape included a mail reader, news readers, etc.

Yes, but your WEB browser ceases to be a WEB browser when it leaves the WEB - see?

I said pissing match, not pissing.
A pissing match starts when somebody starts pissing junk.
Fantastic. Really great work.
Hey I can piss with the best of them - or, in this case, the worse of them... :-)

I never said the server should parse MP3 files or whatever, as I'm not generating them dynamically.
What does it matter if you are doing it dynamically or not?
Apparently it does to you - as you want your dynamically-generated content to be called .php, as that's how it should be "by design".
I see no reason to change the fact that this web page came from a file that had a .php extension. Indeed I see it as useful in that it is a sign that the content is dynamic and/or generated as opposed to static. By renaming things to html you lose that distinction, which can be helpful at times.

No, site design, project management, and good designers make up for that.

The point about MP3 files is that if you configure your web server to treat every file as potentially having dynamic content and that it should search through the entire file looking to determine exactly which language might be in use in the file and hand it off to the appropriate parser, interpreter or module then you are gonna have to contend with the fact that occasionally (and on some sites much more than occasionally) you're gonna be charging the web server with reading and parsing potentially huge files - all in the name of a foolish consistency.

I didn't say EVERY file. I said .HTML files. Please tell me where I said it should parse every single file. Please do.
It's not a fetish. It's called presentation.

No it's called necrosis! As for presentation what's important is CONTENT stupid!

When you start writing sites for big clients with big requests and big ideas, that assertion will seem as foolish to you as it does to me.

Just because you can't care less doesn't mean those visiting your site don't.

As I said, I've never, ever had anybody say "Great site but I won't use it until they have URL's that end in .html".

My tests have shown, to me at least, that the performance hit is a myth.
For 150 files, perhaps.
Repeatedly, about 50 times.
Yes, right, only after 3 of use pointed out that 150 files are not statistically significant. Nor is 50 times of 150 files. A lot depends on the sizes of the files, the configuration of the server, how much memory is currently being used, how busy it is, etc. Again, your "test" is not statistically significant. Come back to use after you've figured out how to do thousands of hits a minute and run it for a few hours.
7500 requests to each server, which are housed on the same box and are configured identically apart from how PHP is used, even using the same document root, gives a good indication of performance. You won't learn anything in hours of testing you didn't know after minutes, it's just that the absolute difference in the numbers will be larger.

It's not wasteful.
How could it not be? You do understand how computers work don't you? You do understand that extra processing is indeed happening. You do understand that under large numbers of accesses such small differences in processing time add up don't you?!?
I also know how the PHP module works. I can see that the extra processing is negligable compared to other factors affecting the server. My tests have shown that.
No, they haven't.

They've strongly indicated that. I've yet to see anything that says otherwise.

If what you say is true, my html test server should have repeatedly out-performed the html-parsing one. It didn't.
When you run such puny tests it's extremely hard to say. You are also not in a controlled environment in any way, shape or form. A discrepancy such as you claim can easily be explained but a small demand on the server from anything from cron to a swap.

Please tell me about how you know about my setup :) I'm intrigued to know ;)

You wouldn't want your design sloppy,
I don't find it sloppy. Indeed I find it very logical.
Logical from the web server's perspective, not the user's.

As a user I find your answer odd. I also find it logical from a user's perspective. I would find it illogical for it to say .html when I know that .html represents static HTML yet I got a dynamic page!

HTML represents the content, not how the file was generated.

As websites are coded to make the user happy, not the webserver, that's a pretty poor excuse.

Yes you are using pretty poor excuses! Stop that!

Hardly.

so why your URLs? The site is a whole - asking someone to ignore the mess in the address bar because "it's just the way the web server works" is a bit silly. It's supposed to work for you, not the other way round :)
Again, nobody cares about what characters are in the URL. If they did they'd start screaming about the silly http:'s and the &parm=<long assed string of junk characters> and the like. The .php or .html at the end is one of the least things to be concerned about!
Just saying "but nobody cares" doesn't make them not care.
3 other people have repeated what I said - Nobody cares. You are the sole person saying that people care. That's a 80 to 20% against (guess who?) - YOU.

Oh shit! 3 people! From a newsgroup filled with some really abysmal coders. Wow. What real peer review that is. The Creme de la creme of development, surely.

And as for the query string - I agree with you. I don't use query strings.
Your sites then must not have very much functionality or utility - but their URLs look nice! ;-)
Tell that to the clients who pay lots of money for them. They seem rather happy with them.

Just because it's least concerning doesn't make it not concerning at all. It's like making a painting and putting it in a crappy frame.

No, again, it's like making a painting then scribbling on the back of the painting that nobody sees nor cares about.

But people do see the URLs. The URLs are used all the time.

--
If you take an Oriental person and spin him around several times, does he become disoriented?

Jan 27 '06 #49

Andrew DeFaria

d wrote:

"

Nor have I seen any qualification of why it's bad (aside from the
fact that you, the one person in this thread, don't like it).
Because the files, when downloaded, are called .php and have
absolutely no php in them :) Wonderful! And why is that bad?!? (All you do if evade this question)
I mean, the file doesn't contain php when the client gets it,
so why should it be named .php? Simple, because that was the filename that was requested to be
fetched by the web server!

But the extension doesn't match the contents of the file.

So fucking what!?! The fact it's the extension of the file is no reason for the file to
have that extension :) Circular logic is rarely a good reason for
anything :) Then why do you use it so much?
Surely a dynamic web server should appear exactly the same
as a static one - all files that contain HTML when viewed
should be called .html. Again, why? Who cares (besides you)?

Because the server is serving up HTML, not PHP.

So fucking what! (Man you are dense!)

Because the files contain html, not php.

Many you are dense. Again so fucking what! That's pretty obvious. Yes, but what's not obvious is why it's a problem. I feel like I'm
arguing with an 8 year old where I ask why and they say because - over
and over again. You may not think that's anything big, Correctly - I don't think it's any problem whatsoever! but presentation-wise it is big. Only in your little world. Most people pay attention to the web page not
the address. If you request a .jpg, you expect to get a jpeg. Hmmm... ah, let's analyze this a little bit. I request a web page with a
URL with .html, I see an image. Many that's screwed up. I expected HTML,
I got an image! That's fucked. If you request a .mpeg, you expect a movie. If you request a .mpeg
and get a csv, that's not really cool. If I requested a .cvs what exactly would I see?
Let's us know when you're done writing your great web server!
:-(

I don't have to. It's called apache, and it does the trick
perfectly. I guess you're not done yet...
What? :)

Never mind - if you don't understand that you'll never be done.
You're proposing to rename .php files to .html files. I guess
we're gonna rename .asp and .jsp files to that too. Hmmm... Maybe
.cfm files (Cold Fusion?) and .do (I've seen those too). Gee that
web server's gonna have much more work to do sorting that out.

And you're forgetting - PHP files can also be just PHP script
designed to run without a web server. So now PHP developers are
gonna have to name some files .html and others .php - nice
consistency there Mr. Consistency!

If they're not on a webserver, then they can be called .php. What kind of stupid assed statement is that. Web servers are first and
foremost machines too. As machines it's quite possible that development
of php scripts as well as running of php script would happen. You make
no sense, are all over the map and an idiot! In fact, when I put my php files not on a webserver, say as scripts to
be run from the windows command prompt, I call them .xphp, Just to confuse everybody else who uses .php. A very wise move there,
very wise. as I have a handler set up to automatically pass those files to the
php executable when they're run, much like a .bat file and cmd.exe. Figures that you'd be using Windows... We're talking about consistency in the web server here, from the
client's perspective. You seem to forget the website is there for the
client ;) Right, whatever. Anybody ever tell you you make very little sense?
If a web server has to parse through a file and look for different
tokens to denote which type of file it might possibly be it will
be more complex than the current typing system.

I didn't say that. No you didn't - I did! Don't you understand how quoting works? There are many ways to determine what's in a file, not just the
contents, and not just the extension. It's really not difficult, not
complex, and not uncommon. Such as?
Which means we can ignore it as it's pretty much meaningless.
Again, nobody cares about the damn URL extension here but you.
Every other poster in this thread disagrees with you. You are the
exception to the rule, the odd man out. By now you should be used
to the fact that people just do not agree with your opinion here
and do not value this foolish aesthetic distinction that you draw
that really hold very little utility. By the very definition and
example of this thread any reasonable person would deduce that in
general most people don't care. But bang your head against the
wall if you must and jump up and down stomping your feet if you
want - it's actually quite comical. You configure your web servers
for your URL consistency and pat yourself on the back. Whatever
floats your boat. I have more important things to waste my time with!

If you think aesthetics are meaningless, then your websites must look
like shit. No I think that your silly notion that anybody cares about the
aesthetics of the URL is meaningless. So far everybody else in this
thread agrees with me. Now where does that put *YOU*? Just because no-one else cares about the extensions here, doesn't mean
that no-one does. Fine, point me to some testimonials from people, aside from yourself,
that do care about that? I can't help it if you aren't as exacting as some people. I guess I can't help it if your a neurotic fool with obsessive
compulsive behavior WRT URLs... I guess. If you can't be bothered to address every aspect of your website,
then why bother creating one? For it's utility. Listen, here's a clue to the clueless neurotics out
there such as yourself. Nothing is ever 100% complete nor bug free nor
completed when it comes to computers and the web. Striving to get as
close to 100% as possible, while some think is an honorable goal or
intention, is surefire death for any business man and anybody else who
is reasonable. Indeed your statement essentially says if you can't
achieve perfection then don't even try! Ridiculous! This is a statement
of somebody who needs professional help - and I hope you find that soon. So you don't put line breaks in your HTML or CSS, as that's extra
complexity and processing for very little gain. Huh? That's no extra complexity or processing. line breaks do not
require processing - at least they don't require loading a whole
compiler/syntactic checker/interpreter into memory and increase resource
usage. And as I demonstrated, the extra processing of parsing .html as php is
absolutely minimal, to the point where tests can't even determine
which one is quicker, as there are many, many other variables that
have a much larger impact on performance than that. You're "demonstrat ion" says nothing of the sort.
you probably shouldn't be anywhere near a computer in case
you look at it funny and choke yourself to death. And you're the one getting bent out of shape because a file
says .php instead of .html. Who's confused here? (Hint: You are!)

How is that being confused?? I just want files named to reflect
what's in them. You wouldn't want your html files called .jpg,
would you?
And as I said earlier, it doesn't stop anyone from using
multiple technologies at once,

Yes but it adds unnecessary complications and processing time
based on a whim that only you have!

No complications what so ever.

What so ever? Are you sure? When's your web server gonna be
complete there bud?

You keep banging on about that. I don't need to write a webserver.

Correction - you couldn't if you tried. As I keep saying, Apache was designed to do just this. The PHP module
for apache was designed to do just this. Just because you can't see
how technology can be used doesn't automatically dismiss those who
can. There are no complications. If you think it's complicated to
have php code in files called .html, then you really do need help. It's not that it's complicated - it's not recommended. Now why is that?
The extra processing time, as I have demonstrated is nothing. You're demonstration is non conclusive. Sample size was too small.

150 documents at a time, repeated nearly 50 times? Too small?

Yes it is. Then please - tell me what you want tested, and I'll test it, and give
you the figures. I did already - go look it up.
My tests showed that sometimes it's even quicker to do it this
way, which means that there are other factors that play a much
bigger part in performance, much more than parsing .html files. Or perhaps your machine was busy servicing others.

It wasn't. I conducted the test as accurately as humanly possible,
which of course meant no other sites were busy handling requests.

Right, and no other processes were going on - you closed all the icons
on your desktop. Trouble is lots of other stuff was running.
and if a web server struggles because it has to check html
files for php when there necessarily isn't any, It's not a struggle - it's a waste of time! Do you understand
the definition of the word efficient?!?

If you think presentation is a waste of time,

Presentation is in the page itself - not its address!

So a great house on a shitty street is just as good as a great house
on a great street?

A street is at least as large as (physically) if not larger in area than
any house. A URL is but 1% of the area of the browser window and it's a
1% that people by and large do not look at or at least do not look at in
terms of prettiness nor value or meaning. To re-use your analogy more
properly it's like a great house with a busted garage door handle is
roughly the same as a great house with a great garage door handle. IOW
if I saw that great house with the busted garage door handle I know that
I would not walk away from the deal, nor would 99.9% of anybody else -
but you would apparently!
then fine - I can't convince you otherwise. Nor the other 3 people here. You're batting 1000% - -1000%!

Now who's talking about small sample sizes :)

Unlike web pages and web servers which are computers and documents that
typically are served hundreds if not thousands of times each minute,
news articles rarely have hundreds or thousands of articles posted to a
thread ever minute. So no, my sample size is by no means small.
Efficiency doesn't necessarily mean you end up with the best
product. Who's talking about products. We're talking about Apache. That
ain't even sold!

The website is a product. You sure don't sound like you know much
about commercial web development.

Nor do you.
then it's not going to be very good at running any complex
php, as that requires a LOT more work then just checking for
"<?php" in a file. Again, it's unnecessary work. You can't seem to understand
that simple concept.

I've demonstrated the "unnecessar y work" is absolutely,
positively nothing.

No you haven't.

I have.

Gosh, what an 8 year old mentality. "Yes I have! Yes I have! Yes I
have!". Get back to me after your tantrum is done and with some real data.
Just because it's the "done thing" doesn't automatically
make it the best thing. Again, in this case it does. If not then make your own web
server and see who else in the planet is interested in such
"technology ". But don't quite your day gig!

Can you qualify these assertions.

I don't need too. You are the one making the claim. And you are
attempting to make it with a very unscientific nor statistically
significant sample. Look at it this way. I would venture to get
that the guys over at Apache know a hell of a lot more about
writing web server software than you. When you are writing such
software you make trade offs and decisions. They *decided* to make
this trade off for the sake of efficiency. Now why do you think
they did that? Because it's true. Or would you have us believe
your tiny test of 150 files, even done 50 times, overrides the
experience of these experts? IOW why do you think they set it up
this way?

Of course you need to. You can't just make an assertion then expect
others to believe you without proving anything.

Exactly. You made the assertion. You have yet to provide proof. Who do you think you are? The church? :) Actually I'm atheist. Apache didn't decide to make the trade-off. Yes they did. It's not hard-wired in apache. Right, it's allowed, but not configured that way by default and
discouraged. That pretty much says it all. Hell, even server side
includes (a process much less taxing than PHP), another allowed
configuration and built in, is turned off by default and likewise
discouraged. Again, that says much. You just put ".html" after ".php" on the addhandler line. You really
don't understand this, do you? Yes, however you keep missing the point or dancing around it.
I've done tests, and I've seen that the performance hit is nothing. Tell ya what, package up your "test" and ship them over to the
folks at Apache along with a note saying "Why did you guys
separate .html files and .php files. Surely not for efficiency or
complexity's sake. Look at these numbers I have here...". After
they get off the floor from rolling around in laughter I'm sure
they'll getting back to you! ;-)
APACHE DON'T SEPERATE THE FILES! Jesus, man. Apache provide the
mechanism for electing which extensions are parsed by which handlers.
They don't write PHP, or even bundle it with their servers, so why on
earth is it their decision to seperate the two? The two aren't even
seperated, for crying out loud. Just because it shows in the example
in the php manual that they only put .php doesn't mean that's how they
only intended it to be used. If you only stick to the examples on the
php website, your site will be incredibly basic, poorly coded, and
slow as all hell.

What's a matter, scared what the answer would be?
I don't have to make my own web server. You probably couldn't if you tried, which was my point - you don't
know the half of the story as to why this technical trade off was
implemented. Sure Apache allows you to configure it in the way you
want it but they warn direly not to do that because things will be
slow. You think they say that on a whim? Hey, perhaps they have a
151 file test! LOL!

Can you show me where they warn to not do that?

Why? You wouldn't follow their advice anyway.
Apache was built to do just these things. The reason PHP moved
from CGI to a native apache module was for exactly this kind of
thing. If you don't understand the technology, then perhaps you
shouldn't quit your day job :) I understand it far better than you as you continually see fit to
show the world. PHP was moved into CGI because PHP was designed to
be part of an otherwise HTML file with the PHP intermixed. As such
the web server had to handle the reading and rendering of that
HTML. It was also moved in there for efficiency reasons instead of
having to start a separate PHP process, much like mod_perl.

I'm not talking about CGI. I've never been talking about CGI here.
I'm talking about the php apache module.

Huh?
If you don't want to take pride in your work and have messy
URLs with weird extensions that don't match the content and
query strings unreadable to humans stretching from here to
the moon, then be my guest. I measure my work by the quality of the content of the page
itself - not it's URL. To me, and everybody else in the world
except apparently you, I don't find .php as a weird extension
(perhaps because I understand it) nor as any more messier
than .html. It's you that have a fetish with that - not I.

I measure my work by the user experience.

I measure my work by user satisfaction.

Which is directly proportional to user experience.
I don't want any dirty laundry out in the open.

What they hell is so dirty about having a URL with a .php in it?!?
Because the returned file never has any php in it.
I want complete control over every aesthetic, from the quality of
the HTML to the quality of the addressing.

i.e. control freak and neurotic personally.
No, more like a perfectionist,

That's what all neurotic people think and say. (BTW Being a
perfectionist is not a good thing either. Newsflash - the world is not
perfect and you will never be either). or at least someone with pride in their work who doesn't just accept
"the done thing" but seeks to find better ways of doing things. Again, nobody else - except you - thinks of it as better.
I find .php a weird extension because the files don't contain a
single shred of php when the user gets them. Again, you might not like it but 99.9% of the rest of use don't care.

Clearly you do, as you're still banging on about how supposedly
ridiculous it is.

Huh?
And, after all, websites are about the user, not the sysadmin
or the developer.

Exactly, and if 99.9% of the users don't care and 80% of them have
no real idea of what a URL even is, then worrying about whether a
file has a .php or a .html extension is a true sign of neurotic
behavior. Seek good counsel...

It all depends on who your audience is for your website. If you're
just writing some blog site or some tiny shop selling CDs, then sure -
but if you're writing tools and sites for big clients (read:
international banks, financial institutions, car manufacturers,
universities, etc.), putting in bids against competing companies, and
the contract is worth £100,000, then these things do matter.

Figures you're English (Or Canadian or whatever). Some English people
seem to take a sadistic pleasure at just arguing and being obtuse!
--
The sex was so good that even the neighbors had a cigarette.

Jan 27 '06 #50

Similar topics