Re: PHP-Yes, HTML-No --- Why?
- From: "d" <d@xxxxxxxxxxx>
- Date: Thu, 26 Jan 2006 10:50:15 GMT
"Andrew DeFaria" <Andrew@xxxxxxxxxxx> wrote in message
news:43d85f6e$0$95966$742ec2ed@xxxxxxxxxxxxxxxxx
>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...
.
- Follow-Ups:
- Re: PHP-Yes, HTML-No --- Why?
- From: Andrew DeFaria
- Re: PHP-Yes, HTML-No --- Why?
- References:
- PHP-Yes, HTML-No --- Why?
- From: Lennart Björk
- Re: PHP-Yes, HTML-No --- Why?
- From: Barry
- Re: PHP-Yes, HTML-No --- Why?
- From: Lennart Björk
- Re: PHP-Yes, HTML-No --- Why?
- From: Barry
- Re: PHP-Yes, HTML-No --- Why?
- From: Lennart Björk
- Re: PHP-Yes, HTML-No --- Why?
- From: d
- Re: PHP-Yes, HTML-No --- Why?
- From: Lennart Björk
- Re: PHP-Yes, HTML-No --- Why?
- From: d
- Re: PHP-Yes, HTML-No --- Why?
- From: Andrew DeFaria
- PHP-Yes, HTML-No --- Why?
- Prev by Date: Re: PHP-Yes, HTML-No --- Why?
- Next by Date: Re: Automate access to password protected sites
- Previous by thread: Re: PHP-Yes, HTML-No --- Why?
- Next by thread: Re: PHP-Yes, HTML-No --- Why?
- Index(es):
Relevant Pages
|