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

On Fri, 27 Jan 2006 00:52:31 +0000, d wrote:

> "Michael Winter" <m.winter@xxxxxxxxxxxxxxxx> wrote in message
> news:D2aCf.9698$wl.2@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx
>> 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
.

Relevant Pages

  • Loading DLLs from different path
    ... PHP is a popular server-side scripting language for web servers. ... It popularity is mainly due that it has many 3rd party extensions. ... The issue is that our DLL is dependent on RPC application server API DLLs in a different folder. ... The problem is that we never recommended putting dlls on the PATH nor do we recommend for our customers to have copies of DLLS over all the place. ...
    (microsoft.public.win32.programmer.kernel)
  • Re: IIS or directory security issue on 2003 E server
    ... "Allow unknown CGI/ISAPI extensions" to Allow. ... You also need the appropriate ISAPI filters ... *assume* PHP is implemented through an ISAPI filter, ... I think I had some other apps running on the server before maybe 3 years ...
    (microsoft.public.windows.server.security)
  • Re: php?
    ... Also does this mean i can run php on the subsites while not affecting the ... When you use PHP with FrontPage 2003, you create the overall Web page design ... If you do not administer your own Web server, ... Disable features that require the FrontPage Server Extensions ...
    (microsoft.public.windows.server.sbs)
  • Re: PHP-Yes, HTML-No --- Why?
    ... they don't have any PHP in them. ... which does indeed do away with extensions altogether. ... I hit two identical servers, one set to parse html via php, and one ... html-parsing server being quicker, ...
    (comp.lang.php)
  • Re: [PHP] PHP Performance and System Load
    ... server then you can move the mod_rewrite directive to the apache.conf file ... Your PHP coding style itself likely has little if any impact on ... to the time taken to parse code, hit the database, hit the disk, etc. ... Opcode cache is good, but if you can give it less to cache ...
    (php.general)