Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Errors-To: <wrowe@rowe-clan.net>
Message-Id: <5.2.0.9.2.20030228124651.02886c80@pop3.rowe-clan.net>
Date: Fri, 28 Feb 2003 12:53:06 -0600
To: dev@httpd.apache.org
From: "William A. Rowe, Jr." <wrowe@rowe-clan.net>
Subject: Re: internal_fast_redirect question
In-Reply-To: <n2m-g.brvnvwo586gwndparker@news.perlig.de>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

At 08:10 AM 2/28/2003, Andr=E9 Malo wrote:
>Trying again ;-)
>
>In contrast to a "normal" internal redirect the fast variant does an=20
>apr_table_overlay of the header tables of the original and the new request.=
=20
>Can someone explain, why? Why not using only the new header table? It bites=
=20
>us, for example, with cookies, which are set twice (mod_usertrack).

Good question.  It's a bit historical.  Some of the headers are connection
related, and fast internal redirect doesn't do all of the connection work=
 that
the full redirect would.  I'd need to step the code paths, but in the end,=
 these
two flavors should not differ so much.

It would be nice if we set up connection-oriented stuff at the start of the=
 request
in it's own table, duplicated that table for the request, and if a request=
 does any
sort of redirect, simply grab a fresh connection table.

Recognize there are some bits that are preserved with fast internal=
 redirects
that won't be computed again.  But I'd really like to see, after all of the=
=20
optimizations that exist in dir_walk and friends, if fast_internal has any
remaining performance benefit.  If it's negligible, I'd be strongly +1 for=
 finally
axing this oddball that was introduced back in mod_negotiation in Apache=
 1.3.

The behavior existed before it was in the core, that's how negotiation=
 handled
multiviews.  One of my first projects was to rip it from negotiation, expose=
 it,=20
and clean it up for consistency.  It's been a long while since I revisited=
 it.

Bill