httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <>
Subject Re: internal_fast_redirect question
Date Fri, 28 Feb 2003 18:53:06 GMT
At 08:10 AM 2/28/2003, André Malo wrote:
>Trying again ;-)
>In contrast to a "normal" internal redirect the fast variant does an 
>apr_table_overlay of the header tables of the original and the new request. 
>Can someone explain, why? Why not using only the new header table? It bites 
>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 
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, 
and clean it up for consistency.  It's been a long while since I revisited it.


View raw message