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 think the simplest solution is to fill in r->per_dir_config with r->server->lookup_defaults. 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. 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. Bill
