|
|
Posted by d on 09/27/81 11:37
"David Haynes" <david.haynes2@sympatico.ca> wrote in message
news:xvPyf.4420$h8.3867@fe56.usenetserver.com...
>d wrote:
>> "David Haynes" <david.haynes2@sympatico.ca> wrote in message
>> news:OHrxf.4737$08.1779@fe71.usenetserver.com...
>>> d wrote:
>>>> Ideally speaking, any file that spits out html should have an .html
>>>> extension, as when the client sees it, it's HTML (regardless of how it
>>>> was created). As others have pointed out, that will require a minor
>>>> change in your server's configuration, but yields more professional
>>>> results.
>>> I'm not sure I agree with that. Isn't this a case of confusing naming
>>> with content? I know that, for reasons of speed, web servers like to tag
>>> content based on file suffixes, but I don't recall any of the standards
>>> bodies specifying it.
>>>
>>> Also, isn't a file that contains php a '.php'-suffixed file until it is
>>> processed and *then* becomes an HTML image? If so, the file doesn't
>>> 'spit out HTML' until it is preprocessed by php.
>>
>> So the file, once spat out, should be called .html. Most web servers
>> still call php files .php even after they've been passed.
>
> At this point the file is simply a byte-stream of HTML code with HTTP
> directives prepended. If you're going to be pedantic about it, it would
> have a type of 'http' at this point.
HTTP is the protocol, not the file. HTTP is being used to move an HTML file
from the server to the client.
>>
>>> AFAIK, the main reason for over-riding the .html extension to include
>>> php processing is so that the file displayed in the browser does not
>>> include the '.php' suffix and, therefore, does not tip off the end-user
>>> as to which preprocessing technology is being used. This was thought to
>>> be a security-related practice. It is similar to changing the '.do'
>>> suffix in struts to something else. (Security through obscurity.)
>>
>> No, it's just a matter of having extensions matching the contents of the
>> file. I guess it's just being polite.
>
> Polite to whom? The web server or the maintainer? I suspect you are
> referring to the latter. If so, I, as a maintainer, would rather know the
> file contained php directives (or asp or jsp etc.) than that it would
> eventually render to HTML. The web server is ambivalent as to the name of
> the file *except* with respect to type processing (see below).
I'm not saying the two are mutually exclusive. I have a server that
contains many .php files, and they show up as .html files once rendered.
It's not hard.
>>> There's nothing magical about any suffix - it's just what you tell the
>>> server to be sensitive to. For example, I could change all the php files
>>> to have a 'pre' suffix to indicate that these files are 'pre'processed
>>> before displaying them.
>>
>> Unfortunately, as long as certain browsers take notice of suffixes, they
>> are somewhat magical. Making sure your extensions match your content is
>> one sure-fire way to get round that :)
>
> Browsers don't care about suffixes - servers do; but, primarily, only as
> they have been taught to care. In apache, it is as easy to add:
Incorrect. Take a look at some of the quirks IE has when looking at
extensions. Granted - they shouldn't look at the extensions, but they sure
as hell do.
> AddType application/x-httpd-php foo
>
> as it is to add
>
> AddType application/x-httpd-php php
>
> in which case all my '.foo' files would be processed via php and, equally
> important, show as xxx.foo in the browser URL line. Therein lies the
> albeit weak security.
Yes, if you leave it like that.
> What you are proposing is that every file display in the browser's URL
> line as 'xxx.html', which is just a specific case of what I have said
> above. (replace 'foo' with 'html'). If you do that, however, even plain
> HTML files will go through the php interpreter before being emitted by the
> server. This may lead to performance penalties on larger systems.
That's not what I'm saying at all. And on Apache running php as a module,
you'll find there's barely any hit at all when passing .html as .php.
> -david-
>
>
Not everyone runs a web server that simply parses and spits out files in a
document root. If you're not doing that any more, you can have greater
flexibility in your naming conventions, which makes it more than possible to
have the correct extensions on your files.
Navigation:
[Reply to this message]
|