Re: your mail

Rob McCool (robm@ncsa.uiuc.edu)
Thu, 30 Dec 1993 13:21:57 -0600


/*
* Re: your mail by Robert S. Thau (rst@ai.mit.edu)
* written on Dec 29, 1:54pm.
*
* First off, with regard to aesthetics, de gustibus non disputandum est. My
* personal 'aesthetic' objection to the semicolon syntax is that it keeps me
* from changing directories to scripts-with-path_info and back without making
* the change in status visible in the URLs and making me change all the
* references. (I don't think this is a totally wild idea --- I've been
* chewing over turning the 'people' directory on my server into a script
* which redirects to ~.../public_html areas if they exist for the user in
* question, and makes up a default home page if they don't).

I agree. We need to keep the script/document distinction arbitrary.

* Still, so long as I can turn an ordinary *file* into a script and back
* without having to find and change everything that cites it (which can be a
* real pain in the butt) or doing an Alias or Redirect in srm.conf (which
* could get ugly if they started to add up), this isn't a *major* issue. If
* the new syntax is an optional alternative, I have no real objection (though
* somebody else might --- two ways of specifying PATH_INFO does add a little
* complication to the server). I'm frankly more hung up on the notion of
* incompatible changes to something which has been announced as a standard,
* over what I see as quite minor efficiency concerns.

But it is a major issue for confusion.... if we're changing the first / of
path info to a ;, but we still support the old method, then what have we
gained? A prudent server would have to do the stats anyway, although it
could search for a ;, which would alleviate the stats in a few cases (but
not all, which to me is a crucial point in determining if this change is
worth pursuing).

* This efficiency argument is apparently the nub of the dispute --- I just
* don't find it easy to see how these few extra stat() calls, which needn't
* occur unless PATH_INFO is present, can possibly amount to a potentially
* serious problem, in the context of all the other things the server does
* when processing a request.

They do need to occur regardless of path_info's presence... however, you're
right, looking for .htaccess files in subdirectories is a larger waste of
time.

As an aside, I find it curious that Charles was bringing up efficiency as an
argument for his changes when a month or two ago I was arguing with him
about why he should run his server standalone instead of from inetd.

* To try to put this in context, I've appended a system-call trace of my
* (hacked) httpd processing the request 'GET /cgi-bin/fortune'. The trace
* was collected from a server running as 'ServerType inetd', so to keep
* things fair I've deleted all the initialization, opening of the logs, and
* so forth, and picked up where it actually starts to process the request.
* For convenience, I've pointed out the PATH_INFO search in the middle of it.
* It amounts to one stat() --- it would have been five with the stock httpd
* (Rob goes top down, I go bottom up);

Interesting... maybe I should go bottom up, it would probably reduce the
average case of the number of stats required.

* Against this background, I
* find it difficult to see how another stat() or two, or even ten, done only
* for URLs which happen to invoke a script in the first place, could make
* enough of a difference to matter.

It's mostly because they're abysmally slow under AFS.

*/

--Rob