httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paul J. Reder" <rede...@raleigh.ibm.com>
Subject Re: Processing .htaccess files inside regex directory containers (revisited).
Date Sun, 22 Aug 1999 20:07:30 GMT
Dean,

I am sorry (and a little surprised) that I seem to have offended you.
It seems that I implied to you that there was code that must be
fixed. My intention was to get some technical questions answered and
to offer some suggestions for possible fixes/clarifications (most of
which related to documentation). The only lines referring to a
possible code change (at the end of my note) were:

> Alternatively, we could add .htaccess processing (after the match has 
> been determined), or document that it ONLY references the .htaccess
> file in the final fully referenced sub directory and "fix" the code to
> do this.

In this text I indicate that this would be a "fix" (read hack) and should
be documented as such (at least that was my intended message). This
suggestion is made only after a much larger set of suggestions related
to adding more explicit language to the docs (and comments in the code).

I am aware (now - after the first exchange of notes) of the performance
implications of the reg-ex code which is why I primarily suggested 
documentation fixes. I also pointed out (perhaps poorly) the confusion
existing with the situation as it currently exists.

The main question related to code is this:
     If it serves no purpose, why is it there?
     If it serves a purpose (or at very least must be there) then it
         should work as "expected".
"Expectations" may need to be changed via documentation because right
now (at least in two cases) "expectations" did not line up with 
implementation.

The fact that the PRs can be fixed in other ways does not change the
fact that the PRs both came into existence due to a misunderstanding
based on the existing doc/code combo. PRs like this will continue if
nothing is done.

The rest of my previous note asks a question (which I attempted to make
clear was coming from my very inexperienced and naive perspective) and
some possible suggestions related to documentation. This scenario was
created based on the real life attempts (regardless of how misguided)
of real life customers who followed the real life documentation and books.

The majority of my suggested actions related to adding comments to code
and making the docs more explicit (as shown in the following snip):

>From my previous note:
> If the answer is that reg-ex just doesn't support it, it never will, and
> we can't get rid of reg-ex then I suggest that we explicitly document
> that fact (rather than documenting by omission). I also suggest that we
> put a VERY large and noticeable block comment in the code (where I was
> tempted to put the patch) that warns future programmers/users that this 
> lack of support is intentional. I would also suggest that we think 
> strongly about the possibility of making the reg-ex support a compiler
> directive enabled option that is off by default. The docs for how to
> turn it on should make it clear that there is no .htaccess support
> inside reg-ex matching directories.

I am also surprised by your response to the implication that there
is a deficiency in the current code/doc implementation since in a
previous note you said:

Dean Gaudet from a post to new-httpd on Thursday, August 5, 1999:
> I would say the problem is that regex directory containers were ill
> thought out to begin with (given that this is like the umpteenth problem
> with them ;)

It was my intention to offer constructive suggestions to help prevent 
this from being reported for the "umpteenth"+1 time.

The concerns that I have with the documentation are as follows:

http://www.apache.org/docs/mod/core.html#directory

    If multiple (non-regular expression) directory sections match the
    directory (or its parents) containing a document, then the directives
    are applied in the order of shortest match first, interspersed with
    the directives from the .htaccess files.

This tells us what happens for non-regular expression directories. It does
not tell us anything about regular expression directories. The only
implication it makes is that the regular expression directories MAY be
handled differently (although not necessarily).

The documentation does indeed then go on to say what happens during regular
expression processing.

    Regular expression directory sections are handled slightly differently
    by Apache 1.2 and 1.3. In Apache 1.2 ... . In Apache 1.3 regular
    expressions are not considered until after all of the normal sections
    have been applied. Then all of the regular expressions are tested in
    the order they appeared in the configuration file.

     ...

    Suppose that the filename being accessed ... . In Apache 1.3 the regular
    expression isn't considered at all at that point in the tree. It won't
    be considered until after all normal <Directory>s and .htaccess files
    have been applied. Then the regular expression will match on
    /home/abc/public_html/abc and be applied. 

The one comment related to .htaccess processing happens at the end of the last
paragraph ("It won't be considered until after all normal <Directory>s and
.htaccess files have been applied."), and simply states that regular expressions
are processed after all other normal processing. It does not state that no
further .htaccess processing is performed during non-normal (regular expression)
processing.

My initial (incorrect) patch was an (misguided) attempt to address a pair of
PRs from the bug data base (something which is encouraged in the Apache
community). I could not participate in the ensuing discussion due to my
absence. In the series of notes that followed, very reasonable alternatives
were offered for these two specific users. The underlying confusion, however,
was not addressed leaving the door open for future PRs (this may just be my
own incorrect opinion).

By the way, my initial patch and the subsequent note were not in any way
meant to indicate that the optimization to the directory code was a bad idea.
The optimization to pull the less used and very expensive reg-ex code out
of the directory loop was a very good and useful fix. My suggestions were
meant simply to help make things clearer to our customers.

With my subsequent note I was merely trying to make sure that the confusion,
which at least 2 users have experienced, might be addressed and eliminated
in the future. I had some technical questions still left open after your
exchange of notes with Ken and was trying to get them answered.

The American Heritage Dictionary (which is what I happen to have available)
defines Tantrum as "A fit of bad temper." I believe that in my previous note,
as well as this one, I have made every attempt to be technically accurate,
concise, and friendly. Hardly what I would call a tantrum. I will refrain
from making any specific comment on the nature of your response.

Dean, if I could, I'd buy you a beer to diffuse the situation. I meant no
offense. If I run into you at a conference, and you don't punch me in the
eye, I'll buy you one. Have a good remainder of your weekend.

-- 
Paul J. Reder

--------- from Red Hat Linux fortunes -----------------------------
... Any resemblance between the above views and those of my employer,
my terminal, or the view out my window are purely coincidental.  Any
resemblance between the above and my own views is non-deterministic.  The
question of the existence of views in the absence of anyone to hold them
is left as an exercise for the reader.  The question of the existence of
the reader is left as an exercise for the second god coefficient.  (A
discussion of non-orthogonal, non-integral polytheism is beyond the scope
of this article.)

Mime
View raw message