> > The other thing is that we actually want to use the exact same filters. > > My patch replaces the ap_filter_t structures from the original > chain with exact copies in the subreq chain so 1) we have the > exact same filter chain and 2) and adds/removes will only affect > the subrequest chain.
I don't want the adds/removes to only affect the sub-request, unless it is an add/remove of a resource filter. Any add/remove of a connection or protocol filter in a sub-request is a BIG problem. Those filters should be setup based on the headers from the client, not based on which resource we are returning. > > That is one of the goals of subrequests, so I believe that this is the > > wrong solution. I will remove the previous filter ASAP and see if it > > still works. > > I guess I don't see how this fixes the problem that > the subrequest can be adding/subtracting filters > and if we are just copying the pointers from the > main request we had better be sure that before we > return from the subrequest all adds/subtracts are > undone, and I don't see how we can guarantee that. It is guaranteed, because the sub-request shouldn't be adding any protocol filters. If it does, then there is a bigger more important bug. IF the sub-request is only adding resource filters, then they are on a separate filter chain. The problem with doing the copy, is that if the sub-request is adding a protocol filter, then you are hiding that problem instead of pointing it out in big red seg fault letters. > > Can you provide a config that causes this bug? > > A simple SSI file with two #include file directives Okay, I thought that was just causing the first bug, not both. I'll look into it ASAP. Ryan
