[Patch] mod_proxy round 2

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

... it seems my karma has failed me this afternoon [if someone would fix my
karma to modproxy, I would be greatly appreciative.]

  Introduce the proxy_walk for <Proxy > sections.  This patch takes advantage
  of the new map_to_storage hook to override the default mod_http TRACE 
  behavior, and eliminate the <Files > and <Directory > block processing.

  This is the next step in cleaning out the <Directory > processing.  It would
  be more elegant if the proxy: prefix weren't required or used.  Feel free to
  extend this solution.

Before you even think to complain about <Files > being gone, consider that
there is no way for the Proxy server to detect the difference between
/somessi.shtml and /somessi.shmtl/with/some/args.  We don't have the
concept of path_info the way that the 'real' server would.  So <Files > really
hasn't been useful in any meaningful way.

I'm going on with the next part of the core patches, this one is required before
mod_proxy will run again.  Also (at the end) are some changes that use the cross
compatible VC5/6/7 debug flag (the /ZI flag isn't recognized by VC5).

Bill

Re: [Patch] mod_proxy round 2

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

From: "William A. Rowe, Jr." <wr...@rowe-clan.net>
Sent: Saturday, August 25, 2001 10:01 PM


>   Introduce the proxy_walk for <Proxy > sections.  This patch takes advantage
>   of the new map_to_storage hook to override the default mod_http TRACE 
>   behavior, and eliminate the <Files > and <Directory > block processing.

This leaves exactly one step undone - the <Proxy > blocks are processed in their
given order.  Since they bore no relationship to the 'usual' case, where we would
have sorted out regex'ed _AFTER_ straight or fnmatch blocks, I'm not certain we
should sort these at all.  Any comments?

>   This is the next step in cleaning out the <Directory > processing.  It would
>   be more elegant if the proxy: prefix weren't required or used.  Feel free to
>   extend this solution.

My final patch solved this two ways.  proxy: is ignored in the r->filename, and the
following two directives are both accepted;

<Proxy proxy:*>
<Proxy *>

Canonicalization of the uri form, and case sensitivity are the only two remaining
questions.  mod_proxy is now free to do whatever it thinks is right, without messing
in <Directory > block processing anymore.

> I'm going on with the next part of the core patches, this one is required before
> mod_proxy will run again.  Also (at the end) are some changes that use the cross
> compatible VC5/6/7 debug flag (the /ZI flag isn't recognized by VC5).

Committed, looking at httpd-2.0, I was certain I had already committed this fix 
across the board :(  Essentially, with /Zi, VC 5.0/6.0/7.0 users should all be able
to simply load the .dsp/.dsw projects and run with them.