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
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
