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. Bill
