[PATCH] Re: Time for 1.3.28?

[Mike Cramer <cr...@webkist.com>]

Jim Jagielski wrote:
> I'm considering releasing 1.3.28 soonish... comments?

The patch attached to bugzilla 14648 (and this message) fixes a long 
standing mod_proxy/mod_rewrite/mod_include problem. The same bug is in 
the old bug db several times: PR2074, PR5338, PR6804.

-- 
Mike Cramer
http://www.webkist.com/

Re: [PATCH] Re: Time for 1.3.28?

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

At 04:15 PM 2/19/2003, Mike Cramer wrote:
>Jim Jagielski wrote:
>>I'm considering releasing 1.3.28 soonish... comments?
>
>The patch attached to bugzilla 14648 (and this message) fixes a long standing mod_proxy/mod_rewrite/mod_include problem. The same bug is in the old bug db several times: PR2074, PR5338, PR6804.

>-        request_rec *rr = ap_sub_req_lookup_uri(name_ptr, r);
>+        request_rec *rr = ap_sub_req_lookup_file(name_ptr, r);

This change would break existing usages and the documented
behavior ... 

  http://httpd.apache.org/docs/mod/mod_dir.html#directoryindex

where /cgi-bin/index.php would no longer process the directory index.
It makes this patch unacceptable.

It would be nice to allow some file:/xxxx syntax or something that lets
the user include absolute files.  But we can't break the existing config
language, even if it is the band-aid to another bug.

I don't know anything about the following change so I can't comment;

>-             p->flags & RULEFLAG_PROXY          ||


Anyways, I'm +1 to moving out .28, so we are that much closer to releasing
a .29 point release for further bug fixes perhaps three months down the road.
Development on 1.3 isn't dead - it's simply lethargic because 1.3 simply
works so well for the 99.99/.01 (as opposed to 80/20) rule.

Bill