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>MyTitle</title>
<meta http-equiv="Content-Type" content="text/html;
charset=iso-8859-1"/>
</head>
<body>
<?php
$host = $_SERVER['HTTP_HOST'];
$server = strtolower($host);
echo 'My variables<bg>';
echo("<br>Host: $host");
echo("<br>Server: $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
59  6931 
Lennart Björk wrote: 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>MyTitle</title>
<meta http-equiv="Content-Type" content="text/html;
charset=iso-8859-1"/>
</head>
<body>
<?php
$host = $_SERVER['HTTP_HOST'];
$server = strtolower($host);
echo 'My variables<bg>';
echo("<br>Host: $host");
echo("<br>Server: $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?
Because only .php files get interpreted.
(Well assuming you've got a standard web server configuration)
test.html just gets printed out right?
Regards,
Barry
Very confused
Lennart Björk
Barry, test.html just gets printed out right?
To a certain extent, yes. It looks like
'; echo("
Host: $host"); echo("
Server: $server"); ?>
<<<
I am still confused.
Lennart Björk
Lennart Björk wrote: Barry,
> test.html just gets printed out right?
To a certain extent, yes. It looks like
>>>
'; echo("
Host: $host"); echo("
Server: $server"); ?>
<<<
I am still confused.
ok
the way php works is that if the web server
has to serve a file with a .php extension, it
recognises it as a PHP file and it sends it through the
PHP parser and then it serves you the resulting html.
the .html file just gets served as is.
because .php went though the parser, you get the parsed php results
because .html just got served, you got the php code as is
it is possible to set up the server to send .html files through
the parser aswell, but as a norm this is not done.
Regards,
Barry
Lennart Björk
Barry,
I do thank you for your help. But
it is possible to set up the server to send .html files through
the parser aswell, but as a norm this is not done.
<
sounds a bit strange. Shouldn't I be able to put pieces of PHP-code in
HTML-code of HTML-files. I think I have done it many times and it has
worked without any special arrangements with the webserver.
Lennart Björk
"Lennart Björk" <le***********@bibserv.com> wrote in message
news:C9*********************@newsc.telia.net... Barry,
I do thank you for your help. But it is possible to set up the server to send .html files through
the parser aswell, but as a norm this is not done.
<
sounds a bit strange. Shouldn't I be able to put pieces of PHP-code in
HTML-code of HTML-files. I think I have done it many times and it has
worked without any special arrangements with the webserver.
This is by no means the norm, but it's definitely how I prefer to work (as
it looks a lot neater than having your dirty laundry aired for all to see).
That is unless I'm using a site engine, in which case it doesn't matter :)
Lennart Björk
dave
Lennart Björk wrote: Barry,
I do thank you for your help. But > it is possible to set up the server to send .html files through
the parser aswell, but as a norm this is not done.
<
sounds a bit strange. Shouldn't I be able to put pieces of PHP-code in
HTML-code of HTML-files. I think I have done it many times and it has
worked without any special arrangements with the webserver.
yes, you could put php code into html code of html files but it should
have a .php extension.
else, maybe your web server was setup differently without you knowing
about it.
cheers
Barry
Lennart Björk
Dave, dirty laundry aired for all to see
Do you mean that PHP-code in files with php as filename extension cannot
be seen as 'view source'?
Lennart Björk
Barry,
maybe your web server was setup differently without you knowing about it
<
May well be. Somehow I have to adapt my code and my file names to the
common norm for webservers. So my conclusion is that PHP-code should
preferably be in files with php as file name extention?
Lennart Björk
Lennart Björk wrote: Barry,
> maybe your web server was setup differently without you knowing about it
<
May well be. Somehow I have to adapt my code and my file names to the
common norm for webservers. So my conclusion is that PHP-code should
preferably be in files with php as file name extention?
yes, I guess that would be better.
and yes, once parsed, you cannot see the PHP code in view source.
cheers
Barry Lennart Björk
"Lennart Björk" <le***********@bibserv.com> wrote in message
news:ON*******************@newsb.telia.net... Dave,
dirty laundry aired for all to see
Do you mean that PHP-code in files with php as filename extension cannot
be seen as 'view source'?
Lennart Björk
I mean as in you are showing the world what technology you're using :) The
pages are spitting out HTML, and so logically should have a .html extension
when the browser sees them (as the extension signifies the contents of the
file, even though web browsers shouldn't use that to determine the contents
of the file, people still do).
View source (.phps) should never be enabled, as it's so ridiculously
dangerous it's not even funny :)
"Lennart Björk" <le***********@bibserv.com> wrote in message
news:ET*******************@newsb.telia.net... Barry,
maybe your web server was setup differently without you knowing about it
<
May well be. Somehow I have to adapt my code and my file names to the
common norm for webservers. So my conclusion is that PHP-code should
preferably be in files with php as file name extention?
That's how most web servers work, but it can be changed with a very slight
modification to your httpd.conf (if you're using apache), or IIS setup
graphical wizard thingy. Personally, I prefer html being parsed through
PHP. The performance hit is absolutely minimal on a system using PHP as a
module (on CGI setups, it requires a PHP process be spawned to handle it,
which can be a problem on highly-trafficked sites).
Lennart Björk
Message-ID: <w%****************@text.news.blueyonder.co.uk> from d
contained the following: I mean as in you are showing the world what technology you're using :)
Smiley noted but it doesn't seem to bother people using other
technologies, why does it seem to bother people who use PHP?
Open source stigma? Yeah, that's it. PHP is free so it can't be any
good, people who use it are just amateurs, yadda, yadda...
I think the only way to overcome that is for more people to use the .php
extension, not less.
--
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/
"Geoff Berrow" <bl******@ckdog.co.uk> wrote in message
news:86********************************@4ax.com... Message-ID: <w%****************@text.news.blueyonder.co.uk> from d
contained the following:
I mean as in you are showing the world what technology you're using :)
Smiley noted but it doesn't seem to bother people using other
technologies, why does it seem to bother people who use PHP?
If I were to develop in ASP, I would have .html as well. The reason we
don't use .html is simply because that's how web servers determine which
pages need parsing. I don't like that, as the files, when downloaded, are
straight HTML. Having to change the clean nature of HTML files because of
perceived limitations in technology is not nice, in my eyes. That's why I
want my files that contain HTML to be called .html when the user gets them
:)
Open source stigma? Yeah, that's it. PHP is free so it can't be any
good, people who use it are just amateurs, yadda, yadda...
That's not it at all - I see no stigma at all about open source :) As a
professional open-source developer, that would be a rather career-limiting
move ;)
I think the only way to overcome that is for more people to use the .php
extension, not less.
I don't think there is a stigma, at least not amongst people people who know
what they're doing :)
--
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/
d wrote: I mean as in you are showing the world what technology you're using :)
Who the hell cares? I mean aside from you! The pages are spitting out HTML, and so logically should have a .html
extension when the browser sees them
Hmmmm... That logic doesn't even make sense. You can have a Perl script
or a .exe file that "spits out" just text. Should such files have a .txt
extension?!? The .html signifies that the file contains HTML - and
pretty much only HTML. A php script contains both HTML and PHP code so
technically speaking it's not just HTML. (as the extension signifies the contents of the file, even though web
browsers shouldn't use that to determine the contents of the file,
people still do).
Why do you think that browsers shouldn't determine the contents of the
file from it's extension? Truth is it does, multiple times over in many,
many different occasions. Ever hear of mime.types? Ever actually
configure an Apache server?
And what's so wrong about doing that anyway? Until and unless we have a
robust and reliable object oriented and typed file system extensions
will be the way to go.
--
For my birthday I got a humidifier and a de-humidifier...I put them in
the same room and let them fight it out...
d wrote: If I were to develop in ASP, I would have .html as well. The reason we
don't use .html is simply because that's how web servers determine
which pages need parsing.
That's also exactly why php files should have php as their extensions -
because that's the way that web servers determine which pages not only
need parsing, but which parsing (actually interpretation not just
parsing - hell strict HTML files need parsing!) it needs. To tax a web
server with the task of parsing everything that has a .html extension,
when many, perhaps most of them have no PHP in them whatsoever is just
plain stupid. And besides, some web sites have PHP, Perl, jsp, asp and
just regular old cgi stuff. How you gonna mash all of that into just
..html files? I don't like that, as the files, when downloaded, are straight HTML.
Well then don't like it all you want however there are good technical
reasons for the way it works and to buck such reasons and configure your
web server in such a way just because you don't like the way it's done
is foolishness.
--
What hair color do they put on the driver's licenses of bald men?
"Andrew DeFaria" <An****@DeFaria.com> asked: What hair color do they put on the driver's licenses of bald men?
Not all bald men are really bald and they do have a hair color.
Those that are of the higher life model though, typically described
as experiencing alopecia, might consider their hair invisible, or
thereby lacking color (or perhaps contains ALL color, whereby
the rest of the world lacks such color).
Jim Carlock
Post replies to the newsgroup.
I am no citizen of any particular country. The country I walk in is a
citizen of _MY_ Universe. Welcome to _MY_ Universe.
"Andrew DeFaria" <An****@DeFaria.com> wrote in message
news:43***********************@news.sonic.net... d wrote: If I were to develop in ASP, I would have .html as well. The reason we
don't use .html is simply because that's how web servers determine which
pages need parsing. That's also exactly why php files should have php as their extensions -
because that's the way that web servers determine which pages not only
need parsing, but which parsing (actually interpretation not just
parsing - hell strict HTML files need parsing!) it needs.
Which was my point. It's a side-effect of the limitations of the web
server.
To tax a web server with the task of parsing everything that has a .html
extension, when many, perhaps most of them have no PHP in them whatsoever
is just plain stupid.
See how much extra work it gives apache - very little indeed. So little, in
fact, that you don't even notice it. Thanks for calling it stupid, though
:)
And besides, some web sites have PHP, Perl, jsp, asp and just regular old
cgi stuff. How you gonna mash all of that into just .html files?
Not everyone does that. Of course some websites do that, but not all. In
fact, not even most. Very few will mix all those technologies, or even
subsets of them, on the same server.
I don't like that, as the files, when downloaded, are straight HTML.
Well then don't like it all you want however there are good technical
reasons for the way it works and to buck such reasons and configure your
web server in such a way just because you don't like the way it's done is
foolishness.
There are no good technical reasons for it. It's done as a short-cut to
allow the server to figure out what is what. I'm saying that figuring out
what is what is not always necessary, and I certainly don't want the
presentation of my site to be deteriorated due to a perceived problem that
isn't even a problem :)
--
What hair color do they put on the driver's licenses of bald men?
"Andrew DeFaria" <An****@DeFaria.com> wrote in message
news:43***********************@news.sonic.net... d wrote: I mean as in you are showing the world what technology you're using :) Who the hell cares? I mean aside from you! The pages are spitting out HTML, and so logically should have a .html
extension when the browser sees them
Hmmmm... That logic doesn't even make sense. You can have a Perl script or
a .exe file that "spits out" just text. Should such files have a .txt
extension?!? The .html signifies that the file contains HTML - and pretty
much only HTML. A php script contains both HTML and PHP code so
technically speaking it's not just HTML.
It only contains HTML when the user gets it. That's my point. The user is
getting a file from your web server, an HTML file, and it has an extension
of something other than HTML. Having your files named due to your servers
requirements is a bit selfish, in my opinion. Not to mention it makes
websites look terrible.
(as the extension signifies the contents of the file, even though web
browsers shouldn't use that to determine the contents of the file, people
still do).
Why do you think that browsers shouldn't determine the contents of the
file from it's extension? Truth is it does, multiple times over in many,
many different occasions. Ever hear of mime.types? Ever actually configure
an Apache server?
Because the RFC says browsers should rely on the content-type header sent.
Of course I have configured apache servers. I don't want to get into a
pissing match here, but please rest assured I've configured some massive
apache setups on some very expensive hardware for some very big clients
paying very good money :) That's all I'll say about that, as it's a vulgar
subject at best.
And what's so wrong about doing that anyway? Until and unless we have a
robust and reliable object oriented and typed file system extensions will
be the way to go.
Or, if we have properly-coded modules for our web servers. We're not
hosting things on 386s any more. We have gigahertz of power to play with,
and checking a file for "<?" or "<?php" funnily enough doesn't take a
cluster of supercomputers. It's not rocket science :)
--
For my birthday I got a humidifier and a de-humidifier...I put them in the
same room and let them fight it out...
Jim Carlock wrote: "Andrew DeFaria" <An****@DeFaria.com> asked: What hair color do they put on the driver's licenses of bald men?
Not all bald men are really bald and they do have a hair color. Those
that are of the higher life model though, typically described as
experiencing alopecia, might consider their hair invisible, or thereby
lacking color (or perhaps contains ALL color, whereby the rest of the
world lacks such color).
I always love it when people address my randomly picked out signature
line and comment or attempt to explain it. It's like watching insane
people at an asylum talking to himself or to somebody that just isn't there.
But don't let me interrupt you - go on - what were you saying?
--
You can't trust dogs to watch your food.
--
If a man says something in the woods and there are no women there, is he
still wrong?
d wrote: That's also exactly why php files should have php as their extensions
- because that's the way that web servers determine which pages not
only need parsing, but which parsing (actually interpretation not
just parsing - hell strict HTML files need parsing!) it needs. Which was my point. It's a side-effect of the limitations of the web
server.
It's not a limitation, it's the design itself. And it's a good design.
Your wanting it to be different (just because you don't like it) shows a
lack of knowledge and perception and thought. To tax a web server with the task of parsing everything that has a
.html extension, when many, perhaps most of them have no PHP in them
whatsoever is just plain stupid.
See how much extra work it gives apache - very little indeed.
I don't agree with that statement at all. Any server serving a lot of
pages is going to be slowed down considerably by parsing pages that need
no parsing. So little, in fact, that you don't even notice it.
I beg to differ. I'm sure there are measurements somewhere. Tell ya
what, since *you* are making the claim then it is incumbent on *you* to
provide the data to prove your assumption. I'll be waiting here but
definitely not holding my breath. Thanks for calling it stupid, though :)
You're welcome! And besides, some web sites have PHP, Perl, jsp, asp and just regular
old cgi stuff. How you gonna mash all of that into just .html files?
Not everyone does that. Of course some websites do that, but not all.
In fact, not even most. Very few will mix all those technologies, or
even subsets of them, on the same server.
Nobody said that one must mix *all* the technologies. In your scheme one
is prevented from even using any two technologies!
BTW: If your ideas here is so intelligent and smart then surely
everybody will want one. Let's us know when you're done coding it! ;-) I don't like that, as the files, when downloaded, are straight HTML.
Well then don't like it all you want however there are good technical
reasons for the way it works and to buck such reasons and configure
your web server in such a way just because you don't like the way
it's done is foolishness.
There are no good technical reasons for it.
Sure there are. Here are two: Speed and Complexity. Also, support of
multiple scripting technologies. There are others. Your sole reason for
wanting it your way: Think having .html makes it look better! Geeze! It's done as a short-cut to allow the server to figure out what is what.
Using certain things to identify file types or even say variable types
in a language itself is exactly how you do things! Next thing you'll be
complaining that having to type <?php ?> is ugly, a short cut and a
limitation! Geeze! I'm saying that figuring out what is what is not always necessary, and
I certainly don't want the presentation of my site to be deteriorated
due to a perceived problem that isn't even a problem :)
Who the hell do you think goes to a web site and sees say .php in the
URL (or .asp, .jsp, .ccf or whatever file extension) and says "Geeze how
unprofessional! The presentation of this site is too deteriorated for me
to look anymore!" (except for deranged people such as yourself)?
--
Ultimate office automation: networked coffee.
d wrote: Hmmmm... That logic doesn't even make sense. You can have a Perl
script or a .exe file that "spits out" just text. Should such files
have a .txt extension?!? The .html signifies that the file contains
HTML - and pretty
much only HTML. A php script contains both HTML and PHP code so
technically speaking it's not just HTML. It only contains HTML when the user gets it. That's my point. The user
is getting a file from your web server, an HTML file, and it has an
extension of something other than HTML.
Hmmm...
jupiter:wget http://defaria.com
--07:50:13-- http://defaria.com/
=> `index.html'
Resolving defaria.com... 192.168.1.103
Connecting to defaria.com|192.168.1.103|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]
[ <=> ] 9,689
--.--K/s
07:50:13 (7.06 MB/s) - `index.html' saved [9689]
Yet the index file on my site is index.php.
So surely you must mean they "get" it with a browser and thus the URL
has a .php at the end of it. Oh horrors! What if the kids see it! You're
sick man! Having your files named due to your servers requirements is a bit
selfish, in my opinion.
Hmmm.... "Doesn't look good" and "selfish". Persuasive arguments indeed!
Would you rather that the server change the URL typed in from .php ->
..html and then be pointing at a file that doesn't exist or is it you
want the server to have to parse each and every file for every thing
known and thus slow down everybody - just so you can see .html instead
of .php? A foolish argument at best. Not to mention it makes websites look terrible.
Oh yes looks horrible - how have we stood for this for so long! It's a
crying shame! Why do you think that browsers shouldn't determine the contents of
the file from it's extension? Truth is it does, multiple times over
in many, many different occasions. Ever hear of mime.types? Ever
actually configure
an Apache server?
Because the RFC says browsers should rely on the content-type header
sent.
Content headers are not always sent. For example, an ftp:// style URL
doesn't send them I believe. There are many other reasons for a
mime.types file. The point (which you missed) was that many things,
processes, applications etc make use of file extensions for the purposes
of determining what type a file is - and rightly so. Of course I have configured apache servers. I don't want to get into a
pissing match here,
Well you started first by pissing and moaning about URLs not having
..html extensions... but please rest assured I've configured some massive apache setups on
some very expensive hardware for some very big clients paying very
good money :) That's all I'll say about that, as it's a vulgar subject
at best.
I hope you weren't configuring them as per your personal likes and
dislikes but instead were configuring them as per the customer
requirements and for speed, etc. Or, if we have properly-coded modules for our web servers.
Define proper! I think they are proper right now. They work as they are
stated to work and they take into account very real world limitations
and constraints and don't waste time on essentially cosmetic crap! We're not hosting things on 386s any more.
Who said we were? Not I! We have gigahertz of power to play with,
Yes so that means we must waste time? You're logic is strange indeed sir. and checking a file for "<?" or "<?php" funnily enough doesn't take a
cluster of supercomputers. It's not rocket science :)
No, implementing an algorithm to do that is not difficult - it's
wasteful. Should the server likewise scan through a 30 Meg mp3 file? A 7
meg bmp file? What if the server find such strings in a <pre> section or
in a .txt file? Lots of considerations that you don't even seem to
acknowledge as you are probably have never designed and written software
before. Again there are very good reasons not to do this and you offer
up only emotional "Well it doesn't look right" reasons which quite
frankly carry very little to 0 weight.
--
Music is the art which is most nigh to tears and memory. - Oscar Wilde
It may be by design, but that doesn't mean it's necessarily good. 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. If you want them called any number of things, then be my guest. I just happen to think presentation matters.
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. If it was otherwise, the inherent overhead of processing dynamic PHP files would stop people from using PHP on any old webserver.
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.
Your points aren't exactly showstoppers. If you're confused by having php in html files, you probably shouldn't be anywhere near a computer in case you look at it funny and choke yourself to death. And as I said earlier, it doesn't stop anyone from using multiple technologies at once, and if a web server struggles because it has to check html files for php when there necessarily isn't any, 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.
Just because it's the "done thing" doesn't automatically make it the best thing.
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'll get back to you with some statistics.
"Andrew DeFaria" <An****@DeFaria.com> wrote in message news:43***********************@news.sonic.net...
d wrote:
That's also exactly why php files should have php as their extensions - because that's the way that web servers determine which pages not only need parsing, but which parsing (actually interpretation not just parsing - hell strict HTML files need parsing!) it needs.
Which was my point. It's a side-effect of the limitations of the web server.
It's not a limitation, it's the design itself. And it's a good design. Your wanting it to be different (just because you don't like it) shows a lack of knowledge and perception and thought.
To tax a web server with the task of parsing everything that has a ..html extension, when many, perhaps most of them have no PHP in them whatsoever is just plain stupid.
See how much extra work it gives apache - very little indeed.
I don't agree with that statement at all. Any server serving a lot of pages is going to be slowed down considerably by parsing pages that need no parsing.
So little, in fact, that you don't even notice it.
I beg to differ. I'm sure there are measurements somewhere. Tell ya what, since you are making the claim then it is incumbent on you to provide the data to prove your assumption. I'll be waiting here but definitely not holding my breath.
Thanks for calling it stupid, though :)
You're welcome!
And besides, some web sites have PHP, Perl, jsp, asp and just regular old cgi stuff. How you gonna mash all of that into just .html files?
Not everyone does that. Of course some websites do that, but not all. In fact, not even most. Very few will mix all those technologies, or even subsets of them, on the same server.
Nobody said that one must mix all the technologies. In your scheme one is prevented from even using any two technologies!
BTW: If your ideas here is so intelligent and smart then surely everybody will want one. Let's us know when you're done coding it! ;-)
I don't like that, as the files, when downloaded, are straight HTML.
Well then don't like it all you want however there are good technical reasons for the way it works and to buck such reasons and configure your web server in such a way just because you don't like the way it's done is foolishness.
There are no good technical reasons for it.
Sure there are. Here are two: Speed and Complexity. Also, support of multiple scripting technologies. There are others. Your sole reason for wanting it your way: Think having .html makes it look better! Geeze!
It's done as a short-cut to allow the server to figure out what is what.
Using certain things to identify file types or even say variable types in a language itself is exactly how you do things! Next thing you'll be complaining that having to type <?php ?> is ugly, a short cut and a limitation! Geeze!
I'm saying that figuring out what is what is not always necessary, and I certainly don't want the presentation of my site to be deteriorated due to a perceived problem that isn't even a problem :)
Who the hell do you think goes to a web site and sees say .php in the URL (or .asp, .jsp, .ccf or whatever file extension) and says "Geeze how unprofessional! The presentation of this site is too deteriorated for me to look anymore!" (except for deranged people such as yourself)?
--
Ultimate office automation: networked coffee.
Here are some tests I did:
I created two virtualhosts in apache. One parses .php files, one parses both .php and .html. I filled it with 150 html documents (from the apache manual), and wrote a script to download each file from each server.
The results:
They're identical. Sometimes the HTML site is faster by 0.002s, sometimes it's slower by the same. So, it's pretty fair to say, that Apache and PHP don't give a damn if they're parsing HTML files for PHP, as as I said, the performance hit is minimal. In fact, there seems to be NO performance hit. In fact, variations of the computer's stress played a far, far greater role in determining the speed of parsing than the apache setup. So, to summarise, whether your PHP module is parsing HTML files with no PHP in them is the least of your worries.
dave.
"Andrew DeFaria" <An****@DeFaria.com> wrote in message news:43***********************@news.sonic.net...
d wrote:
That's also exactly why php files should have php as their extensions - because that's the way that web servers determine which pages not only need parsing, but which parsing (actually interpretation not just parsing - hell strict HTML files need parsing!) it needs.
Which was my point. It's a side-effect of the limitations of the web server.
It's not a limitation, it's the design itself. And it's a good design. Your wanting it to be different (just because you don't like it) shows a lack of knowledge and perception and thought.
To tax a web server with the task of parsing everything that has a ..html extension, when many, perhaps most of them have no PHP in them whatsoever is just plain stupid.
See how much extra work it gives apache - very little indeed.
I don't agree with that statement at all. Any server serving a lot of pages is going to be slowed down considerably by parsing pages that need no parsing.
So little, in fact, that you don't even notice it.
I beg to differ. I'm sure there are measurements somewhere. Tell ya what, since you are making the claim then it is incumbent on you to provide the data to prove your assumption. I'll be waiting here but definitely not holding my breath.
Thanks for calling it stupid, though :)
You're welcome!
And besides, some web sites have PHP, Perl, jsp, asp and just regular old cgi stuff. How you gonna mash all of that into just .html files?
Not everyone does that. Of course some websites do that, but not all. In fact, not even most. Very few will mix all those technologies, or even subsets of them, on the same server.
Nobody said that one must mix all the technologies. In your scheme one is prevented from even using any two technologies!
BTW: If your ideas here is so intelligent and smart then surely everybody will want one. Let's us know when you're done coding it! ;-)
I don't like that, as the files, when downloaded, are straight HTML.
Well then don't like it all you want however there are good technical reasons for the way it works and to buck such reasons and configure your web server in such a way just because you don't like the way it's done is foolishness.
There are no good technical reasons for it.
Sure there are. Here are two: Speed and Complexity. Also, support of multiple scripting technologies. There are others. Your sole reason for wanting it your way: Think having .html makes it look better! Geeze!
It's done as a short-cut to allow the server to figure out what is what.
Using certain things to identify file types or even say variable types in a language itself is exactly how you do things! Next thing you'll be complaining that having to type <?php ?> is ugly, a short cut and a limitation! Geeze!
I'm saying that figuring out what is what is not always necessary, and I certainly don't want the presentation of my site to be deteriorated due to a perceived problem that isn't even a problem :)
Who the hell do you think goes to a web site and sees say .php in the URL (or .asp, .jsp, .ccf or whatever file extension) and says "Geeze how unprofessional! The presentation of this site is too deteriorated for me to look anymore!" (except for deranged people such as yourself)?
--
Ultimate office automation: networked coffee.
Where to begin.
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. That .PHP is there for my benefit, not theirs, which is unwanted.
FTP requests are not HTTP. When your browser gets files from ftp://, it's not a web browser any more but an FTP client.
I said pissing match, not pissing.
I never said the server should parse MP3 files or whatever, as I'm not generating them dynamically. When I do generate them, I can still have PHP providing them, AND keep the .mp3 as an extension, because of the tools I use on my site. By your logic, if you have a dynamically-generated MP3 on your site, it should end in .php. That's not particularly cool, is it?
My tests have shown, to me at least, that the performance hit is a myth. It's not wasteful. It's a more than reasonable trade-off for having a decent site, with tidy URLs. You wouldn't want your design sloppy, 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 :)
dave
"Andrew DeFaria" <An****@DeFaria.com> wrote in message news:43***********************@news.sonic.net...
d wrote:
Hmmmm... That logic doesn't even make sense. You can have a Perl script or a .exe file that "spits out" just text. Should such files have a .txt extension?!? The .html signifies that the file contains HTML - and pretty
much only HTML. A php script contains both HTML and PHP code so technically speaking it's not just HTML.
It only contains HTML when the user gets it. That's my point. The user is getting a file from your web server, an HTML file, and it has an extension of something other than HTML.
Hmmm...
jupiter:wget http://defaria.com
--07:50:13-- http://defaria.com/
=> `index.html'
Resolving defaria.com... 192.168.1.103
Connecting to defaria.com|192.168.1.103|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]
[ <=> ] 9,689 --.--K/s
07:50:13 (7.06 MB/s) - `index.html' saved [9689]
Yet the index file on my site is index.php.
So surely you must mean they "get" it with a browser and thus the URL has a .php at the end of it. Oh horrors! What if the kids see it! You're sick man!
Having your files named due to your servers requirements is a bit selfish, in my opinion.
Hmmm.... "Doesn't look good" and "selfish". Persuasive arguments indeed! Would you rather that the server change the URL typed in from ..php -> .html and then be pointing at a file that doesn't exist or is it you want the server to have to parse each and every file for every thing known and thus slow down everybody - just so you can see .html instead of .php? A foolish argument at best.
Not to mention it makes websites look terrible.
Oh yes looks horrible - how have we stood for this for so long! It's a crying shame!
Why do you think that browsers shouldn't determine the contents of the file from it's extension? Truth is it does, multiple times over in many, many different occasions. Ever hear of mime.types? Ever actually configure
an Apache server?
Because the RFC says browsers should rely on the content-type header sent.
Content headers are not always sent. For example, an ftp:// style URL doesn't send them I believe. There are many other reasons for a mime.types file. The point (which you missed) was that many things, processes, applications etc make use of file extensions for the purposes of determining what type a file is - and rightly so.
Of course I have configured apache servers. I don't want to get into a pissing match here,
Well you started first by pissing and moaning about URLs not having ..html extensions...
but please rest assured I've configured some massive apache setups on some very expensive hardware for some very big clients paying very good money :) That's all I'll say about that, as it's a vulgar subject at best.
I hope you weren't configuring them as per your personal likes and dislikes but instead were configuring them as per the customer requirements and for speed, etc.
Or, if we have properly-coded modules for our web servers.
Define proper! I think they are proper right now. They work as they are stated to work and they take into account very real world limitations and constraints and don't waste time on essentially cosmetic crap!
We're not hosting things on 386s any more.
Who said we were? Not I!
We have gigahertz of power to play with,
Yes so that means we must waste time? You're logic is strange indeed sir.
and checking a file for "<?" or "<?php" funnily enough doesn't take a cluster of supercomputers. It's not rocket science :)
No, implementing an algorithm to do that is not difficult - it's wasteful. Should the server likewise scan through a 30 Meg mp3 file? A 7 meg bmp file? What if the server find such strings in a <pre> section or in a .txt file? Lots of considerations that you don't even seem to acknowledge as you are probably have never designed and written software before. Again there are very good reasons not to do this and you offer up only emotional "Well it doesn't look right" reasons which quite frankly carry very little to 0 weight.
--
Music is the art which is most nigh to tears and memory. - Oscar Wilde
>It may be by design, but that doesn't mean it's necessarily good.
I believe it is possible with Apache to explicitly state the type
of each and every page without the use of *any* file extensions.
This gets cumbersome to maintain, though. Some people advocate it
because they want URLs that won't change with web server technology.
I'm not sure that matters for stuff that it's not reasonable to
bookmark or put in a search engine, like the current contents of
your shopping cart, or a page showing a product that will itself
obsolete and no longer be sold much faster than web server technology. 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.
And absolutely *NO* files should be called .htm, ever.
Why? MIME types are the way the server communicates to the browser
what the content is. Not file extensions.
And whether you like it or not, it *is* possible to have a page
that changes its type (as presented to the browser) based on the
results of the query (for instance, if there is a single result,
it's video, if there is not a single result, it's a page full of
choices of videos).
If you want them called any number of things, then be my guest. I just
happen to think presentation matters.
And what do file extensions have to do with presentation?
Gordon L. Burditt
"Gordon Burditt" <go***********@burditt.org> wrote in message
news:11*************@corp.supernews.com... It may be by design, but that doesn't mean it's necessarily good.
I believe it is possible with Apache to explicitly state the type
of each and every page without the use of *any* file extensions.
This gets cumbersome to maintain, though. Some people advocate it
because they want URLs that won't change with web server technology.
I'm not sure that matters for stuff that it's not reasonable to
bookmark or put in a search engine, like the current contents of
your shopping cart, or a page showing a product that will itself
obsolete and no longer be sold much faster than web server technology.
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.
And absolutely *NO* files should be called .htm, ever.
Why? MIME types are the way the server communicates to the browser
what the content is. Not file extensions.
But for human readability, the extension should reflect the content, surely?
And whether you like it or not, it *is* possible to have a page
that changes its type (as presented to the browser) based on the
results of the query (for instance, if there is a single result,
it's video, if there is not a single result, it's a page full of
choices of videos).
That's what Location: headers are for ;)
If you want them called any number of things, then be my guest. I just
happen to think presentation matters.
And what do file extensions have to do with presentation?
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.
Gordon L. Burditt
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.
That .PHP is there for my benefit, not theirs, which is unwanted.
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.
[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.
[...] It's a more than reasonable trade-off for having a decent site,
with tidy URLs.
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.
[snip]
Mike
--
Michael Winter
Prefix subject with [News] before replying by e-mail.
d wrote: It may be by design, but that doesn't mean it's necessarily good.
In this case it does. 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)? 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! :-( 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! 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. 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. Your points aren't exactly showstoppers.
And your one point is one of pure aesthetics! If you're confused by having php in html files,
Who ever said that! I'm not stupid! 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!) 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! 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?!? 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. 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! 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.
d wrote: Here are some tests I did:
I created two virtualhosts in apache. One parses .php files, one
parses both .php and .html. I filled it with 150 html documents (from
the apache manual), and wrote a script to download each file from each
server.
The results:
They're identical. Sometimes the HTML site is faster by 0.002s,
sometimes it's slower by the same. So, it's pretty fair to say, that
Apache and PHP don't give a damn if they're parsing HTML files for
PHP, as as I said, the performance hit is minimal. In fact, there
seems to be NO performance hit. In fact, variations of the computer's
stress played a far, far greater role in determining the speed of
parsing than the apache setup. So, to summarise, whether your PHP
module is parsing HTML files with no PHP in them is the least of your
worries.
You did a whopping 150 files. Oh my god! How did your poor little server
put up with all that processing???
How many hits does Google get a day? An hour? I don't think they are
even approaching that whopping 150 hits!
BTW: Things deteriorate over time and side of files too as the server
can grow to taking up more and more resources over time.
d wrote: 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. That .PHP is there for my
benefit, not theirs, which is unwanted.
Here's a hint - they couldn't give a rat's ass what the extension is. FTP requests are not HTTP.
So what? Should all files that are ftp'ed have a .ftp extension?!? 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. I said pissing match, not pissing.
A pissing match starts when somebody starts pissing junk. 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? When I do generate them, I can still have PHP providing them, AND keep
the .mp3 as an extension, because of the tools I use on my site. By
your logic, if you have a dynamically-generated MP3 on your site, it
should end in .php. That's not particularly cool, is it?
Cool?!? I'm not the one who has this fetch with file extensions. I could
care less if it says .txt or if it's dynamic - it's *you* who cares
about these things. My tests have shown, to me at least, that the performance hit is a myth.
For 150 files, perhaps. 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?!? It's a more than reasonable trade-off for having a decent site, with
tidy URLs.
Again, you have this fetish with file extensions in URLs. Nobody else
cares! And to me a .php extension is a little "tidier" than .html - hell
it's one less character! :-) You wouldn't want your design sloppy,
I don't find it sloppy. Indeed I find it very logical. 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!
"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. I mean, the file doesn't contain php when the client gets it, so why should it be named .php?
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.
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.
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 :)
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.
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.
Your points aren't exactly showstoppers.
And your one point is one of pure aesthetics!
Exactly.
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.
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. The extra processing time, as I have demonstrated is nothing. 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.
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, then fine - I can't convince you otherwise. Efficiency doesn't necessarily mean you end up with the best product.
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 "unnecessary work" is absolutely, positively nothing.
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've done tests, and I've seen that the performance hit is nothing. I don't have to make my own web server. 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 :)
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 don't want any dirty laundry out in the open. I want complete control over every aesthetic, from the quality of the HTML to the quality of the addressing. I find ..php a weird extension because the files don't contain a single shred of php when the user gets them. And, after all, websites are about the user, not the sysadmin or the developer.
"Andrew DeFaria" <An****@DeFaria.com> wrote in message news:43***********************@news.sonic.net...
d wrote:
Here are some tests I did:
I created two virtualhosts in apache. One parses .php files, one parses both .php and .html. I filled it with 150 html documents (from the apache manual), and wrote a script to download each file from each server.
The results:
They're identical. Sometimes the HTML site is faster by 0.002s, sometimes it's slower by the same. So, it's pretty fair to say, that Apache and PHP don't give a damn if they're parsing HTML files for PHP, as as I said, the performance hit is minimal. In fact, there seems to be NO performance hit. In fact, variations of the computer's stress played a far, far greater role in determining the speed of parsing than the apache setup. So, to summarise, whether your PHP module is parsing HTML files with no PHP in them is the least of your worries.
You did a whopping 150 files. Oh my god! How did your poor little server put up with all that processing???
So you come up with a better test, sunshine. You asked me to do research, I did. I gave you figures, and suddenly they're not good enough for you. 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. Even someone with a basic grasp of statistics could see that. I never claimed I was representing your average webserver's daily load.
How many hits does Google get a day? An hour? I don't think they are even approaching that whopping 150 hits!
BTW: Things deteriorate over time and side of files too as the server can grow to taking up more and more resources over time.
So I see you haven't written code for anything approaching massive sites, if you claim that. Thanks.
"Michael Winter" <m.******@blueyonder.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.
That .PHP is there for my benefit, not theirs, which is unwanted.
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.
[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.
[...] It's a more than reasonable trade-off for having a decent site,
with tidy URLs.
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.
[snip]
Mike
dave
--
Michael Winter
Prefix subject with [News] before replying by e-mail.
"Andrew DeFaria" <An****@DeFaria.com> wrote in message news:43***********************@news.sonic.net...
d wrote:
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. That .PHP is there for my benefit, not theirs, which is unwanted.
Here's a hint - they couldn't give a rat's ass what the extension is.
Not everyone, but some people. And if you cater for those people, it suddenly gets very important.
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.
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 said pissing match, not pissing.
A pissing match starts when somebody starts pissing junk.
Fantastic. Really great work.
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".
When I do generate them, I can still have PHP providing them, AND keep the .mp3 as an extension, because of the tools I use on my site. By your logic, if you have a dynamically-generated MP3 on your site, it should end in .php. That's not particularly cool, is it?
Cool?!? I'm not the one who has this fetch with file extensions. I could care less if it says .txt or if it's dynamic - it's you who cares about these things.
It's not a fetish. It's called presentation. Just because you can't care less doesn't mean those visiting your site don't.
My tests have shown, to me at least, that the performance hit is a myth.
For 150 files, perhaps.
Repeatedly, about 50 times.
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. If what you say is true, my html test server should have repeatedly out-performed the html-parsing one. It didn't.
It's a more than reasonable trade-off for having a decent site, with tidy URLs.
Again, you have this fetish with file extensions in URLs. Nobody else cares! And to me a .php extension is a little "tidier" than .html - hell it's one less character! :-)
People do care. Just because you don't think so doesn't make them go away. If you're putting the quality of your work up against someone else, and they have taken the small amount of time to make their URLs look human-friendly, then your site won't look as good as theirs. That can lose you contracts.
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 websites are coded to make the user happy, not the webserver, that's a pretty poor excuse.
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. And as for the query string - I agree with you. I don't use query strings. 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.
On Fri, 27 Jan 2006 00:52:31 +0000, d wrote: "Michael Winter" <m.******@blueyonder.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.
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.
[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. [...] 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. [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.
Steve
Message-ID: <LY****************@text.news.blueyonder.co.uk> 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.
--
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/
Message-ID: <j9****************@text.news.blueyonder.co.uk> 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 telecommunications provider in the UK When
I go to pay my bill I get this: https://www2.bt.com/youraccount?coex...cefkdffndfkn.0
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 ?
--
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/
d wrote: So you come up with a better test, sunshine.
It's your assertion therefore you are burdened with the prove. 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. 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. 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 I see you haven't written code for anything approaching massive
sites, if you claim that. Thanks.
Yeah, where exactly do you see that?
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. 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. 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. 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. 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? 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! I won't stop until my site is as perfect as possible.
A sure sign of a neurotic person!
--
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.
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?
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 "unnecessary 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!!
"Geoff Berrow" <bl******@ckdog.co.uk> wrote in message
news:1m********************************@4ax.com... Message-ID: <LY****************@text.news.blueyonder.co.uk> 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/
"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 "unnecessary 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!!
"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.
"Steve" <Th*****@Aint.Valid> wrote in message
news:pa****************************@Aint.Valid... On Fri, 27 Jan 2006 00:52:31 +0000, d wrote:
"Michael Winter" <m.******@blueyonder.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
"Geoff Berrow" <bl******@ckdog.co.uk> wrote in message
news:l0********************************@4ax.com...
Message-ID: <j9****************@text.news.blueyonder.co.uk> 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 telecommunications 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/
"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.
"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?
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 "demonstration" 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 "unnecessary 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. This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: saayan |
last post by:
Hi,
I am using PHP 5.0.1 with Apache 2 on Win XP (SP2).
My index.php file has require_once contents.php and also for
functions.php.
My contents.php file also has a require_once for...
|
by: bb nicole |
last post by:
Below is my php code which i need to save the jobseeker resume in database. But does not function and show the message: Column count doesn't match value count at row 1 after i add a field name...
|
by: comp.lang.php |
last post by:
I am using CLI PHP to run a PHP script, c:\wamp\php\php.exe, but
instead of executing my script, it's actually displaying the raw code
instead.
How can I run my code using CLI PHP? I installed...
|
by: sandeepifw |
last post by:
plz help
I have a php variable $content on page menu.php
now i wnt to use its value on page menu_items.js
hear menu_items.js create a menubar.its contan both static and dynamic menu
my...
|
by: priestyuk |
last post by:
Hi everyone: D,
I recently purchased a very smart and ‘expensive’ template from .
You have to install it on your site etc putting in your mysql details, e-mail address, license key etc. So far...
|
by: sickboy |
last post by:
Hey everyone,
I am working on a new site, ForceFedTV.com and I have gotten reports that the site runs great on mac, but once loaded on a pc, after clicking a few links then going back to the home...
|
by: Benjamin Grieshaber |
last post by:
Hi,
I´m on SuSE 9.3 with xmlrpc-c and xmlrpc-c-devel installed (ver. 0.9.10)
I tried to compile php with xmlrpc support and got the following errors:
...
|
by: mekalai82 |
last post by:
i have information.php file that file contain following coding <?php
echo phpinfo(); ?>
while i calling the URL ("http://localhost/information.php").
i am getting the coding <?php echo...
|
by: Patriot89 |
last post by:
I have a quick question in reference to php file extenstions...
I have code for example like this... This is all located on this site www.ixalliance.com/BHS/Default
(This is my nav.php file)
...
|
by: Chrisjc |
last post by:
Good afternoon,
I am seeking some php configuration help. Here is the run down I am running Windows server 2003 and IIS V6.0 I have never had issues before until now. I have Symantec Antivirus 11.0...
|
by: taylorcarr |
last post by:
A Canon printer is a smart device known for being advanced, efficient, and reliable. It is designed for home, office, and hybrid workspace use and can also be used for a variety of purposes. However,...
|
by: ryjfgjl |
last post by:
If we have dozens or hundreds of excel to import into the database, if we use the excel import function provided by database editors such as navicat, it will be extremely tedious and time-consuming...
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
| | |
