Re: cvs commit: httpd-2.0/server request.c

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

My gut instinct?  You break something here.

ap_location_walk, IIRC, sets up the default_conf.  Which means the
default_conf may not be brought in - given the case you've optimized
for here.  I might be mistaken, and don't have the energy to research
this early morning, but I thought I better point it out sooner.

At 10:45 PM 5/11/2002, brianp@apache.org wrote:
>brianp      02/05/11 20:45:47
>
>   Modified:    server   request.c
>   Log:
>   Optimization: skip cache setup in location_walk() if the vhost
>   config contains no <Location> blocks
>
>   Revision  Changes    Path
>   1.113     +2 -2      httpd-2.0/server/request.c
>
>   Index: request.c
>   ===================================================================
>   RCS file: /home/cvs/httpd-2.0/server/request.c,v
>   retrieving revision 1.112
>   retrieving revision 1.113
>   diff -u -r1.112 -r1.113
>   --- request.c 24 Apr 2002 04:20:10 -0000      1.112
>   +++ request.c 12 May 2002 03:45:47 -0000      1.113
>   @@ -1192,8 +1192,6 @@
>        walk_cache_t *cache;
>        const char *entry_uri;
>
>   -    cache = prep_walk_cache(AP_NOTE_LOCATION_WALK, r);
>   -
>        /* No tricks here, there are no <Locations > to parse in this vhost.
>         * We won't destroy the cache, just in case _this_ redirect is later
>         * redirected again to a vhost with <Location > blocks to optimize.
>   @@ -1201,6 +1199,8 @@
>        if (!num_sec) {
>            return OK;
>        }
>   +
>   +    cache = prep_walk_cache(AP_NOTE_LOCATION_WALK, r);
>
>        /* Location and LocationMatch differ on their behaviour w.r.t. 
> multiple
>         * slashes.  Location matches multiple slashes with a single slash,
>
>
>

Re: cvs commit: httpd-2.0/server request.c

[Brian Pane <bp...@pacbell.net>]

William A. Rowe, Jr. wrote:

> My gut instinct?  You break something here.
>
> ap_location_walk, IIRC, sets up the default_conf.  Which means the
> default_conf may not be brought in - given the case you've optimized
> for here.  I might be mistaken, and don't have the energy to research
> this early morning, but I thought I better point it out sooner. 


We should be okay...the default values set by prep_walk_cache()
are stored with key AP_NOTE_LOCATION_WALK, which is only ever
accessed in location_walk itself.  So if one call to location_walk
skips the prep_walk_cache() call but the next call can't skip it,
the second call will invoke prep_walk_cache() and initialize the
defaults.

--Brian