> From: "Ryan Bloom" <[EMAIL PROTECTED]> > Sent: Thursday, January 03, 2002 10:14 AM > > > > On Thursday 03 January 2002 05:16 am, Bill Stoddard wrote: > > > > > > > > > Is it valid for r->per_dir_config to be null? Hmm. I wonder if > > > > > ap_get_limit_req_body should be fixed to handle this case instead > > > > > of ap_http_filter? -- justin > > > > > > > > No. It's entirely invalid. > > > > > > > > At the very least - you are looking the r->server->lookup_defaults, plus the > > > > <Location > sections in per_dir_config. > > > > > > > > That's always true, anything that changes that assumption is broken. Now if > > > > either proxy or your patch skips the initial <Location > lookup (or it is > > > > otherwise circumvented) then you get what you pay for. > > > > > > It's not that clear to me what the right solution should be. Checkout > > > ap_proxy_http_process_response(). This function reads the -response- from the proxied > > > server and dummies up a request_rec to do so. So is this a valid approach or >not? If it > > > is, then we do not need to do location/directory walks (and it is fine if > > > r->per_dir_config is NULL. > > > > We must be able to dummy up request_rec structures in order to use filters > > that aren't attached to a request. I believe that r->per_dir_config should be > > allowed to be NULL. > > Now I see... and don't think this is the solution. Think for a moment; any > corrupted module could destroy r->per_dir_config, and we would be none the > wiser. > I agree.
> I think the simplest solution is to fill in r->per_dir_config with > r->server->lookup_defaults. That will not work. Keep in mind we are reading a proxied -response-. It definitely wouldn't be nice to put a limit of say 8192 on a response from a proxied server :-) Now it may make sense to introduce a new config directive to explicitly place a limit on the size of proxied responses. Yea, its possible but that doesn't mean it is useful or is the right thing to do. The check would go into HTTP_IN (or a filter designed specifically to do these types of checks). > The longer solution is to create a default > conf_vector, of an empty configuration. And the best solution, some point > in the future, might be configuring <RemoteProxy > sections. I'd prefer to not do this unless there is a compelling end user requirement to do so. Sure we can make up scenarios where this would be useful, but we live in the real world :-) > The real question > is what is the request actually using within this dummy configuration, and that > would require some single stepping I don't have time for this week. > I've spent some time on this and this is one reason I am sort of interested in a proxy specific input filter. I agree with Ryan that 99.9% would be identical to what is already in HTTP_IN now. Bill
