Message-Id: <199703162013.VAA09047@en1.engelschall.com>
Subject: Re: config/234: REMOTE_IDENT not always available to mod_rewrite
 (fwd)
To: new-httpd@hyperreal.com (Apache Developer ML)
Date: Sun, 16 Mar 1997 21:13:34 +0100
From: rse@engelschall.com (Ralf S. Engelschall)
Organization: Engelschall, Germany.
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: new-httpd-owner@apache.org
Precedence: bulk
Reply-To: new-httpd@hyperreal.com


In article <97031613203636@decus.org> you wrote:
> From the fingers of Ralf S. Engelschall flowed the following:

> >
> >Because get_remote_logname() actually only calls rfc1413() if
> >r->connection->remote_logname is not set, I've just replaced the
> >get_remote_logname() call in mod_rewrite by the code segment
> >
> >    if (r->connection->remote_logname != NULL)
> >        result = r->connection->remote_logname;
> >    else 
> >        result = rfc1413(r->connection, r->server);

>     Um..  get_remote_logname calls rfc1413() only if
>     r->connection->remote_logname is NULL *and* if RFC1413 checking is
>     supposed to be done.

>     It looks like the above patch is going to cause mod_rewrite to call
>     rfc1413() unconditionally, because you don't (and really can't)
>     check for the presence of IdentityCheck the way get_remote_logname
>     does.

>     So mod_rewrite will incur the overhead of RFC1413 processing even if
>     the server configuration doesn't call for it.  Or am I missing
>     something?

Correct, but this lookup is only done if there is a rewrite rule which
explicitly asks for this value, i.e. it uses the %{REMOTE_IDENT} variable. I
think it makes sense that a (always explicit) usage of this variable leads to
an explicit lookup of the identification string over the net if _it is still
not known_. Only this way you can write rulesets which do what they should.

Think is is ok this way because mod_rewrite will only do the lookups if the
user asks it to do it. 

Greetings,
                                       Ralf S. Engelschall
                                       rse@engelschall.com
                                       www.engelschall.com