httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@lyra.org>
Subject Re: cvs commit: apache-2.0/src/main http_core.c
Date Tue, 17 Oct 2000 11:40:04 GMT
On Tue, Oct 17, 2000 at 07:10:30AM -0400, Jeff Trawick wrote:
> Greg Stein <gstein@lyra.org> writes:
> 
> > I'm a little confused here...
> > 
> > *why* is runtime state being placed into the config structures? That makes
> > zero sense. What am I missing?
> 
> I don't think you're missing anything...

Oh. Then excuse me if my tone tends towards a rant :-) hehe...

> It seems that the filter
> lists and ap_get_client_block()'s brigade need to be in
> r->request_config instead of r->per_dir_config.

It has nothing to do with configs. Why not fields in request_rec?

If the desire is to keep the information relatively private (e.g. avoid
r->remaining or some such), then introduce "struct http_parse_ctx" and put a
pointer in the request. Hold the HTTP parsing and chunking info in there,
and keep the structure private to http_protocol.c

> I was confused that Ryan wanted the brigade used by
> ap_get_client_block() in core_dir_config. I double checked with
> somebody else and they said that there was a core_dir_config per
> request.  But last night I was playing some more with this and I don't
> see create_core_dir_config called per request.  I need to understand
> this stuff a bit more before I "fix" it.

Because there isn't. core_dir_config structures are created when you have a
<Location> or a <Directory> directive (e.g. *before* the server ever starts
up!). They are also created by the merge function when a request "walks"
down the dir/location trees merging configuration data.

Theoretically, there is a core_dir_config per request because of the merging
stuff. But holy crap... that is just the wrong location for runtime data.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

Mime
View raw message