[RESULT] Re: [VOTE] Release 2.3.16-beta as beta
With (binding) +1 votes from: igor, graham, jim, stefen I call this vote CLOSED and PASSED. I will start the release process. Thanks to all! On Dec 15, 2011, at 9:48 AM, Jim Jagielski wrote: The 2.3.16-beta (prerelease) tarballs are available for download at test: http://httpd.apache.org/dev/dist/ I'm calling a VOTE on releasing these as 2.3.16-beta BETA and, with luck, this IS our last beta and the next release in ~2weeks or less will be 2.4.0 GA!! Vote will last the normal 72 hours...
mod_substitute buggy execution order
Directive execution order is performed in a very strange way in mod_substitute. Look at the following example: Substitute s/aaa/global/inq Location /test/ Substitute s/aaa/local/inq /Location If I have aaa in a page, I expect it to be replaced by global. No luck, it is replaced by local. Even more crazy: Location /test/ Substitute s/aaa/local1/inq /Location Location /test/ Substitute s/aaa/local2/inq Substitute s/aaa/local3/inq /Location I expect the first directive to execute and see local1. No luck again, it is replaced by local2 - yes, not local3. The merging of directive by Apache is performed in the following order: global, local1, local2, local3 but directives are executed in the following order: : local2, local3, local1, global Am I confused or should we fix that? Thanks, Nick
Re: mod_substitute buggy execution order
On 12/19/2011 8:40 AM, Nick Gearls wrote:
Directive execution order is performed in a very strange way in
mod_substitute.
Look at the following example:
Substitute s/aaa/global/inq
Location /test/
Substitute s/aaa/local/inq
/Location
If I have aaa in a page, I expect it to be replaced by global.
No luck, it is replaced by local.
Not a bug. {global} is broader scope than /test/ URI. Therefore the
server is performing the narrowest-scope replacements, first.
Otherwise, there would be no way to fine-tune the results in more
narrow contexts!
Even more crazy:
Location /test/
Substitute s/aaa/local1/inq
/Location
Location /test/
Substitute s/aaa/local2/inq
Substitute s/aaa/local3/inq
/Location
I expect the first directive to execute and see local1.
No luck again, it is replaced by local2 - yes, not local3.
The merging of directive by Apache is performed in the following order:
global, local1,
local2, local3
but directives are executed in the following order: : local2, local3, local1,
global
Am I confused or should we fix that?
I think this is fine. It certainly should be documented, and we could
process replacements in last-to-first order within the same scope, but
I'm not sure that makes a huge difference (and would be inappropriate
to change this late in 2.2). Since mod_substitute is gone from 2.4, I
doubt there is really an opportunity to change this anymore.
questions about rewrite module
hi,
I encountered a problem while configured virtual host. My experiment
environment is Apache2+fastcgi+php-cgi.
I want to implement mass virtual hosting using rewrite rules based on
apache rewrite module. That is, for a request url like:
http://1000.xyz.com/test.php, apache will translate it to a absolute file
path like: $DOCUMENT_ROOT/1000/test.php, and then get this script to
execute.
And my conf is:
*RewriteEngine On*
*RewriteCond %{HTTP_HOST} !^www.xyz.com*
*RewriteCond %{HTTP_HOST} ^([^.]+)\.xyz\.com [NC]*
*RewriteRule (.*) /%1$1 [PT]*
I use inner redirection in order not to expose this detail to users.
Besides, I succeeded when I use external redirection, namely the [R] tag
instead of [PT] tag.
When I use [PT] tag, apache cannot run expectedly. I request a url :
http://1000.xyz.com/test.php, error message pops out like: The requested
URL /1000/cgi-bin/php.fcgi/1000/test.php was not found on this server.
I don't know if this error results from fastcgi, is it the inappropriate
config in fastcgi or inevitable problem by using it?
Really appreciate your help.
Vic
--
Best regards,
Rui Hu
State Key Laboratory of Networking Switching Technology
Beijing University of Posts and Telecommunications(BUPT)
MSN: tchrb...@gmail.com
-
Re: svn commit: r1220867 - in /httpd/httpd/branches/2.4.x: ./ CHANGES Makefile.in build/rpm/httpd.spec.in build/rules.mk.in support/Makefile.in test/Makefile.in
On 12/19/2011 11:27 AM, minf...@apache.org wrote:
Modified: httpd/httpd/branches/2.4.x/Makefile.in
URL:
http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/Makefile.in?rev=1220867r1=1220866r2=1220867view=diff
==
--- httpd/httpd/branches/2.4.x/Makefile.in (original)
+++ httpd/httpd/branches/2.4.x/Makefile.in Mon Dec 19 17:27:13 2011
@@ -12,8 +12,8 @@ PROGRAM_DEPENDENCIES = \
$(MPM_LIB) \
os/$(OS_DIR)/libos.la
-PROGRAMS= $(PROGRAM_NAME)
-TARGETS = $(PROGRAMS) $(shared_build) $(other_targets)
+sbin_PROGRAMS = $(PROGRAM_NAME)
+TARGETS = $(sbin_PROGRAMS) $(shared_build) $(other_targets)
Yow. That defies every naming convention I've ever observed. Can't we
pick one case or the other? Perhaps even SPROGRAMS vs PROGRAMS, or
SYSPROGRAMS?
Modified: httpd/httpd/branches/2.4.x/build/rpm/httpd.spec.in
URL:
http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/build/rpm/httpd.spec.in?rev=1220867r1=1220866r2=1220867view=diff
==
--- httpd/httpd/branches/2.4.x/build/rpm/httpd.spec.in (original)
+++ httpd/httpd/branches/2.4.x/build/rpm/httpd.spec.in Mon Dec 19 17:27:13
2011
%{_sbindir}/ab
sbin?
%{_sbindir}/logresolve
%{_sbindir}/httxt2dbm
sbin?
%{_sbindir}/apxs
sbin?
None of these require the user to be administrator, except to use the
apxs -i option. Not really sure if these make sense. Any pointers to
a decent canonical definition of sbin v bin?
--- httpd/httpd/branches/2.4.x/support/Makefile.in (original)
+++ httpd/httpd/branches/2.4.x/support/Makefile.in Mon Dec 19 17:27:13 2011
@@ -3,8 +3,9 @@ DISTCLEAN_TARGETS = apxs apachectl dbmma
CLEAN_TARGETS = suexec
-PROGRAMS = htpasswd htdigest rotatelogs logresolve ab htdbm htcacheclean
httxt2dbm $(NONPORTABLE_SUPPORT)
-TARGETS = $(PROGRAMS)
+bin_PROGRAMS = htpasswd htdigest htdbm
+sbin_PROGRAMS = rotatelogs logresolve ab htcacheclean httxt2dbm
$(NONPORTABLE_SUPPORT)
Here again, pick a case?
Fwd: mod_substitute buggy execution order
That's very different from other modules.
Most (all?) modules do the opposite: first global, then local - ex: rewrite
Furthermore, narrowing does not work the way you expect as
Location /test/
Substitute s/aaa/local1/inq
/Location
Location /
Substitute s/aaa/local2/inq
Substitute s/aaa/local3/inq
/Location
will end up with local2 which is not the narrowest-scope.
I understand your concern, but this definitely breaks the usual way of
working which thus introduces an inconsistency with other modules .
mod_substitute is gone from 2.4
Is it replaced by mod_sed? What is the logic there?
Thanks,
Nick
Original Message
Subject:Re: mod_substitute buggy execution order
Date: Mon, 19 Dec 2011 15:34:41 -0600
From: William A. Rowe Jr. wr...@rowe-clan.net
To: dev@httpd.apache.org
CC: Nick Gearls nickgea...@gmail.com
On 12/19/2011 8:40 AM, Nick Gearls wrote:
Directive execution order is performed in a very strange way in mod_substitute.
Look at the following example:
Substitute s/aaa/global/inq
Location /test/
Substitute s/aaa/local/inq
/Location
If I have aaa in a page, I expect it to be replaced by global.
No luck, it is replaced by local.
Not a bug. {global} is broader scope than /test/ URI. Therefore the
server is performing the narrowest-scope replacements, first.
Otherwise, there would be no way to fine-tune the results in more
narrow contexts!
Even more crazy:
Location /test/
Substitute s/aaa/local1/inq
/Location
Location /test/
Substitute s/aaa/local2/inq
Substitute s/aaa/local3/inq
/Location
I expect the first directive to execute and see local1.
No luck again, it is replaced by local2 - yes, not local3.
The merging of directive by Apache is performed in the following order:
global, local1,
local2, local3
but directives are executed in the following order: : local2, local3, local1,
global
Am I confused or should we fix that?
I think this is fine. It certainly should be documented, and we could
process replacements in last-to-first order within the same scope, but
I'm not sure that makes a huge difference (and would be inappropriate
to change this late in 2.2). Since mod_substitute is gone from 2.4, I
doubt there is really an opportunity to change this anymore.
