> From: Justin Erenkrantz [mailto:[EMAIL PROTECTED]] > > On Fri, Jun 28, 2002 at 07:01:34PM -0700, Ryan Bloom wrote: > > Have you looked at which of these are causing the most performance > > problems? It seems to me that the easiest thing to do, would be to use > > a persistent brigade, which removes two steps from this. > > I'd really prefer that we decouple this persistent brigade from the > request_rec. We used to have it coupled (req_cfg->bb) and it made > the code too confusing as other places started to rely on this > brigade. So, I'd like to not go back down that road and figure out > a better scope for such a persistent brigade (a filter context seems > about right for the scope).
No. Please use the core_request_config->bb variable for this. That structure is protected by CORE_PRIVATE. The vector in the request_rec was specifically designed for this kind of thing, so not using it because people don't understand the API is completely bogus. Document the API better if that is the problem. > > Until we know where the performance problems are in the current model I > > believe that it makes little sense to redesign the whole model. I think > > you can stream-line this by just re-using the same brigade for every > > header and by moving the copy down to the HTTP_IN filter. > > HTTP_IN is designed to read the entity - not the headers. HTTP_IN is > only active after the request has been setup and the headers have > been read. At this stage, HTTP_IN isn't active, so I'm slightly > confused what you'd move to HTTP_IN. Yes, you would need to move where HTTP_IN is located in order for the design to work. > As far as connection level filters having access to the request, you > are right that they do. However, I don't believe that the connection > filters should be modifying its request_rec since it may change on > each invocation of the filter and something strikes me as wrong if a > connection filter plays with the request - to me, that means it is a > request filter. Of course they shouldn't be modifying the request_rec directly. I read all of the messages as though you were still going to pass the data up to ap_getline() to do anything with the data, not modify the request_rec inside the filter. -1 on using the filter like that, because it removes any chance for any other input filter to re-write the headers as they are read. Ryan
