httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Stoddard" <b...@wstoddard.com>
Subject Re: cvs commit: httpd-2.0/server core.c
Date Thu, 03 Jan 2002 19:31:49 GMT

> From: "Ryan Bloom" <rbb@covalent.net>
> 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


Mime
View raw message