Re: svn commit: r159356 - httpd/httpd/trunk/CHANGES
[EMAIL PROTECTED] wrote: Author: trawick Date: Tue Mar 29 00:44:53 2005 New Revision: 159356 URL: http://svn.apache.org/viewcvs?view=revrev=159356 Log: sync with 2.0.54-dev Modified: httpd/httpd/trunk/CHANGES Modified: httpd/httpd/trunk/CHANGES URL: http://svn.apache.org/viewcvs/httpd/httpd/trunk/CHANGES?view=diffr1=159355r2=159356 == --- httpd/httpd/trunk/CHANGES (original) +++ httpd/httpd/trunk/CHANGES Tue Mar 29 00:44:53 2005 @@ -57,10 +57,6 @@ *) Only recompile buildmark.c when we have to relink httpd. [Justin Erenkrantz] - *) Remove formatting characters from ap_log_error() calls. These - were escaped as fallout from CAN-2003-0020. - [Eric Covener ecovener gmail.com] - *) mod_cache: Fix up handling of revalidated responses. [Justin Erenkrantz] @@ -630,6 +626,10 @@ Apache 2.0.xx tree as documented, and except as noted, below.] Changes with Apache 2.0.54 + + *) Remove formatting characters from ap_log_error() calls. These + were escaped as fallout from CAN-2003-0020. + [Eric Covener ecovener gmail.com] *) htdigest: Fix permissions of created files. PR 33765. [Joe Orton] I don't think we should remove entries from the 2.1.x Changes anymore. Since there are real changes between patch releases of 2.1.x, removing this changes entry means that someone upgrading from 2.1.2 would not see this one listed. I think from now on, items should be listed in both 2.1.x and 2.0.x. On a different matter, should truncating the CHANGES be considered for trunk? Eg, only show changes since 2.0 or even 2.1.0? (At a minimum, cut out all the old old old old changes in 1.3..) -Paul
Re: svn commit: r159356 - httpd/httpd/trunk/CHANGES
Jeff Trawick wrote: On Tue, 29 Mar 2005 00:50:45 -0800, Paul Querna [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: Author: trawick Date: Tue Mar 29 00:44:53 2005 New Revision: 159356 URL: http://svn.apache.org/viewcvs?view=revrev=159356 Log: sync with 2.0.54-dev Modified: httpd/httpd/trunk/CHANGES Modified: httpd/httpd/trunk/CHANGES URL: http://svn.apache.org/viewcvs/httpd/httpd/trunk/CHANGES?view=diffr1=159355r2=159356 == --- httpd/httpd/trunk/CHANGES (original) +++ httpd/httpd/trunk/CHANGES Tue Mar 29 00:44:53 2005 @@ -57,10 +57,6 @@ *) Only recompile buildmark.c when we have to relink httpd. [Justin Erenkrantz] - *) Remove formatting characters from ap_log_error() calls. These - were escaped as fallout from CAN-2003-0020. - [Eric Covener ecovener gmail.com] - *) mod_cache: Fix up handling of revalidated responses. [Justin Erenkrantz] @@ -630,6 +626,10 @@ Apache 2.0.xx tree as documented, and except as noted, below.] Changes with Apache 2.0.54 + + *) Remove formatting characters from ap_log_error() calls. These + were escaped as fallout from CAN-2003-0020. + [Eric Covener ecovener gmail.com] *) htdigest: Fix permissions of created files. PR 33765. [Joe Orton] I don't think we should remove entries from the 2.1.x Changes anymore. Since there are real changes between patch releases of 2.1.x, removing this changes entry means that someone upgrading from 2.1.2 would not see this one listed. I think from now on, items should be listed in both 2.1.x and 2.0.x. I had assumed we would do this when 2.2 became GA... +1 Bill
share global data in apache
Hi, I developed a library which is called by PHP. The library has a global data cache which is accessed and updated by the functions in the library. The cache of the library apparently couldn't be shared among multiprocesses. But it seemed to me that apache can't run as a single process multi-thread model. Is this true? If so, what I should do in order to use the global cache in the library? The OS is Linux. Thanks in advance for your kindly help. _ Do You Yahoo!? 150MP3 http://music.yisou.com/ http://image.yisou.com 1G1000 http://cn.rd.yahoo.com/mail_cn/tag/1g/*http://cn.mail.yahoo.com/event/mail_1g/
Re: Backport of AllowEncodedSlashes to Apache 1.3
If there's no objection, shall I just go ahead and commit this?
-aaron
On Mar 24, 2005, at 4:38 PM, Aaron Bannert wrote:
I've attached a patch against the trunk of Apache 1.3 that backports
support for the AllowEncodedSlashes directive. It should behave
identically to the way it works in 2.0. By default Apache will disallow
any request that includes a %-encoded slash ('/') character (which
is '%2F'), but by enabling this directive an administrator can override
this prevention and allow %2Fs in request URLs. If this is an
acceptable
backport, and I can get some +1s for it, I'll be happy to commit it and
update the documentation (at least the English :).
-aaron
Index: src/include/httpd.h
===
--- src/include/httpd.h (revision 158971)
+++ src/include/httpd.h (working copy)
@@ -976,6 +976,7 @@
API_EXPORT(int) ap_is_url(const char *u);
API_EXPORT(int) ap_unescape_url(char *url);
+API_EXPORT(int) ap_unescape_url_keep2f(char *url);
API_EXPORT(void) ap_no2slash(char *name);
API_EXPORT(void) ap_getparents(char *name);
API_EXPORT(char *) ap_escape_path_segment(pool *p, const char *s);
Index: src/include/http_core.h
===
--- src/include/http_core.h (revision 158971)
+++ src/include/http_core.h (working copy)
@@ -318,6 +318,8 @@
/* Digest auth. */
char *ap_auth_nonce;
+unsigned int allow_encoded_slashes : 1; /* URLs may contain %2f
w/o being
+ * pitched indiscriminately */
} core_dir_config;
/* Per-server core configuration */
Index: src/main/util.c
===
--- src/main/util.c (revision 158971)
+++ src/main/util.c (working copy)
@@ -1635,6 +1635,53 @@
return OK;
}
+API_EXPORT(int) ap_unescape_url_keep2f(char *url)
+{
+register int badesc, badpath;
+char *x, *y;
+
+badesc = 0;
+badpath = 0;
+/* Initial scan for first '%'. Don't bother writing values before
+ * seeing a '%' */
+y = strchr(url, '%');
+if (y == NULL) {
+return OK;
+}
+for (x = y; *y; ++x, ++y) {
+if (*y != '%') {
+*x = *y;
+}
+else {
+if (!ap_isxdigit(*(y + 1)) || !ap_isxdigit(*(y + 2))) {
+badesc = 1;
+*x = '%';
+}
+else {
+char decoded;
+decoded = x2c(y + 1);
+if (decoded == '\0') {
+badpath = 1;
+}
+else {
+*x = decoded;
+y += 2;
+}
+}
+}
+}
+*x = '\0';
+if (badesc) {
+return BAD_REQUEST;
+}
+else if (badpath) {
+return NOT_FOUND;
+}
+else {
+return OK;
+}
+}
+
API_EXPORT(char *) ap_construct_server(pool *p, const char *hostname,
unsigned port, const request_rec *r)
{
Index: src/main/http_request.c
===
--- src/main/http_request.c (revision 158971)
+++ src/main/http_request.c (working copy)
@@ -1175,8 +1175,21 @@
/* Ignore embedded %2F's in path for proxy requests */
if (r-proxyreq == NOT_PROXY r-parsed_uri.path) {
- access_status = ap_unescape_url(r-parsed_uri.path);
+ core_dir_config *d;
+ d = ap_get_module_config(r-per_dir_config, core_module);
+ if (d-allow_encoded_slashes) {
+ access_status = ap_unescape_url_keep2f(r-parsed_uri.path);
+ }
+ else {
+ access_status = ap_unescape_url(r-parsed_uri.path);
+ }
if (access_status) {
+ if (! d-allow_encoded_slashes) {
+ ap_log_rerror(APLOG_MARK, APLOG_NOERRNO|APLOG_INFO, r,
+ found %%2f (encoded '/') in URI
+ (decoded='%s'), returning 404,
+ r-parsed_uri.path);
+ }
ap_die(access_status, r);
return;
}
Index: src/main/http_core.c
===
--- src/main/http_core.c(revision 158971)
+++ src/main/http_core.c(working copy)
@@ -143,6 +143,9 @@
conf-etag_add = ETAG_UNSET;
conf-etag_remove = ETAG_UNSET;
+/* disallow %2f (encoded '/') by default */
+conf-allow_encoded_slashes = 0;
+
return (void *)conf;
}
@@ -319,6 +322,8 @@
conf-cgi_command_args = new-cgi_command_args;
}
+conf-allow_encoded_slashes = new-allow_encoded_slashes;
+
return (void*)conf;
}
@@ -2309,6 +2314,18 @@
}
#endif /* AP_ENABLE_EXCEPTION_HOOK */
+static const char *set_allow2f(cmd_parms *cmd, core_dir_config *d,
int arg)
+{
+const char *err = ap_check_cmd_context(cmd, NOT_IN_LIMIT);
+
+if (err != NULL) {
+return err;
+}
+
+d-allow_encoded_slashes =
Re: Backport of AllowEncodedSlashes to Apache 1.3
Since we're extending core_dir_config, we should document the
change in core_dir_config
Aaron Bannert wrote:
If there's no objection, shall I just go ahead and commit this?
-aaron
On Mar 24, 2005, at 4:38 PM, Aaron Bannert wrote:
I've attached a patch against the trunk of Apache 1.3 that backports
support for the AllowEncodedSlashes directive. It should behave
identically to the way it works in 2.0. By default Apache will disallow
any request that includes a %-encoded slash ('/') character (which
is '%2F'), but by enabling this directive an administrator can override
this prevention and allow %2Fs in request URLs. If this is an
acceptable
backport, and I can get some +1s for it, I'll be happy to commit it and
update the documentation (at least the English :).
-aaron
Index: src/include/httpd.h
===
--- src/include/httpd.h (revision 158971)
+++ src/include/httpd.h (working copy)
@@ -976,6 +976,7 @@
API_EXPORT(int) ap_is_url(const char *u);
API_EXPORT(int) ap_unescape_url(char *url);
+API_EXPORT(int) ap_unescape_url_keep2f(char *url);
API_EXPORT(void) ap_no2slash(char *name);
API_EXPORT(void) ap_getparents(char *name);
API_EXPORT(char *) ap_escape_path_segment(pool *p, const char *s);
Index: src/include/http_core.h
===
--- src/include/http_core.h (revision 158971)
+++ src/include/http_core.h (working copy)
@@ -318,6 +318,8 @@
/* Digest auth. */
char *ap_auth_nonce;
+unsigned int allow_encoded_slashes : 1; /* URLs may contain %2f
w/o being
+* pitched indiscriminately */
} core_dir_config;
/* Per-server core configuration */
Index: src/main/util.c
===
--- src/main/util.c (revision 158971)
+++ src/main/util.c (working copy)
@@ -1635,6 +1635,53 @@
return OK;
}
+API_EXPORT(int) ap_unescape_url_keep2f(char *url)
+{
+register int badesc, badpath;
+char *x, *y;
+
+badesc = 0;
+badpath = 0;
+/* Initial scan for first '%'. Don't bother writing values before
+ * seeing a '%' */
+y = strchr(url, '%');
+if (y == NULL) {
+return OK;
+}
+for (x = y; *y; ++x, ++y) {
+if (*y != '%') {
+*x = *y;
+}
+else {
+if (!ap_isxdigit(*(y + 1)) || !ap_isxdigit(*(y + 2))) {
+badesc = 1;
+*x = '%';
+}
+else {
+char decoded;
+decoded = x2c(y + 1);
+if (decoded == '\0') {
+badpath = 1;
+}
+else {
+*x = decoded;
+y += 2;
+}
+}
+}
+}
+*x = '\0';
+if (badesc) {
+return BAD_REQUEST;
+}
+else if (badpath) {
+return NOT_FOUND;
+}
+else {
+return OK;
+}
+}
+
API_EXPORT(char *) ap_construct_server(pool *p, const char *hostname,
unsigned port, const request_rec *r)
{
Index: src/main/http_request.c
===
--- src/main/http_request.c (revision 158971)
+++ src/main/http_request.c (working copy)
@@ -1175,8 +1175,21 @@
/* Ignore embedded %2F's in path for proxy requests */
if (r-proxyreq == NOT_PROXY r-parsed_uri.path) {
- access_status = ap_unescape_url(r-parsed_uri.path);
+ core_dir_config *d;
+ d = ap_get_module_config(r-per_dir_config, core_module);
+ if (d-allow_encoded_slashes) {
+ access_status = ap_unescape_url_keep2f(r-parsed_uri.path);
+ }
+ else {
+ access_status = ap_unescape_url(r-parsed_uri.path);
+ }
if (access_status) {
+ if (! d-allow_encoded_slashes) {
+ ap_log_rerror(APLOG_MARK, APLOG_NOERRNO|APLOG_INFO, r,
+ found %%2f (encoded '/') in URI
+ (decoded='%s'), returning 404,
+ r-parsed_uri.path);
+ }
ap_die(access_status, r);
return;
}
Index: src/main/http_core.c
===
--- src/main/http_core.c(revision 158971)
+++ src/main/http_core.c(working copy)
@@ -143,6 +143,9 @@
conf-etag_add = ETAG_UNSET;
conf-etag_remove = ETAG_UNSET;
+/* disallow %2f (encoded '/') by default */
+conf-allow_encoded_slashes = 0;
+
return (void *)conf;
}
@@ -319,6 +322,8 @@
conf-cgi_command_args = new-cgi_command_args;
}
+conf-allow_encoded_slashes = new-allow_encoded_slashes;
+
So what is the real status of 2.1.x...
The STATUS file says: 2.1.4 : in development 2.1.3 : Released on 2/22/2005 as alpha. The ap_release.h header file says: 2.1.5-dev The distribution page /dist/httpd says: httpd-2.1.3-beta.tar.gz Are we BETA yet or not? I am assuming that the true status is: - httpd-2.1.3-beta.tar.gz - should really be ALPHA - STATUS file needs to be updated to 2.1.5 : in development 2.1.4 : pending BETA released 2.1.3 : Released on 2/22/2005 as alpha. - ap_release.h - no change. Am I missing something? Brad
Re: Enhancement of mod_charset_lite
Open an enhancement request in Bugzilla http://httpd.apache.org/bug_report.html an include the patch file there. Brad [EMAIL PROTECTED] Thursday, March 24, 2005 4:47:52 AM Hello, for my personal needs i had to add some functionality to mod_charset_lite. Here is what i did: 1) Add an option AllowProxied that makes it work also on proxied requests (usefull in a reverse proxy environment which uses mod_proxy_html to return to the original encoding). 2) Add an option AdjustHeader that adjusts the content-type header according to the destination encoding. If someone is interested in these changes, i am not sure where to post them. Greetings, Jens Stutte
Re: Subrequests should not inherit entity-header fields from the mainline request
Bill Stoddard wrote: Joe Schaefer wrote: As it turns out, we clone all of the main request's input headers when we create the subrequest, including C-L. Whacking the subrequest's C-L header fixes the hang. Since the main request's body could also have be chunked, we should probably remove the subrequest's Transfer-Encoding header as well. Shouldn't you remove Content-Type also? The problem is that the subrequest is inheriting entity-header fields from the mainline request (mainline request was a POST). This patch should be generalised to remove all inherited entity-header fields from the subrequest. done (rev 159410). thanks for the tip. Greg
Re: Subrequests should not inherit entity-header fields from the mainline request
Paul Querna wrote: Bill Stoddard wrote: The problem is that the subrequest is inheriting entity-header fields from the mainline request (mainline request was a POST). This patch should be generalised to remove all inherited entity-header fields from the subrequest. Something that popped into my mind is, what about when you actually want to do a POST subrequest? from ap_set_sub_req_protocol(): rnew-method = GET; rnew-method_number = M_GET; rnew-protocol= INCLUDED; ...so I say we drive off that bridge when we get to it, to mis-quote Ted Kennedy. Greg
Re: So what is the real status of 2.1.x...
--On Tuesday, March 29, 2005 11:22 AM -0700 Brad Nicholes [EMAIL PROTECTED] wrote: Are we BETA yet or not? I am assuming that the true status is: OtherBill has consistently repeated that he will -1 anything entering beta. So, until he resolves his issues, we're at a standstill. My current understanding is that OtherBill's -1 has some thing to do with APR-iconv and nothing at all with httpd. As such, there's absolutely nothing [EMAIL PROTECTED] can do to remove his -1. Every time I have tried to remove his stated arguments against going beta (I lost count at 4 different rationales against beta), OtherBill suddenly presents more arguments as to why httpd can't enter beta. I'm frankly very tired of shooting at moving targets and trying to persuade folks that we should have entered beta when we have committers looking for excuses to prevent us from making forward progress. Hence, any desire that I had to see 2.2 start the release cycle is diminished because I don't have time for more arguments as to why we should start the beta cycle. I still maintain that the current state of trunk is sufficient to branch off 2.2.x (keeping the branch version at 2.1.x until we go GA with 2.2.0) and consequently bump trunk to 2.3.x today. -- justin
Re: So what is the real status of 2.1.x...
Brad Nicholes wrote: The STATUS file says: 2.1.4 : in development I was tagged as alpha. It sort of died, because of problems in apr-iconv. The Status file should be updated. 2.1.3 : Released on 2/22/2005 as alpha. It had enough votes for beta, but I am not sure on the RM's decision. Either way, the Status file should be updated. The ap_release.h header file says: 2.1.5-dev This is correct. Look at: http://svn.apache.org/repos/asf/httpd/httpd/tags/ Once Tagged, you should bump the ap_release.h to the next revision for /trunk/.
Re: So what is the real status of 2.1.x...
2.1.3 : Released on 2/22/2005 as alpha. It had enough votes for beta, but I am not sure on the RM's decision. It isn't the RM's decision. A majority vote of the PMC is a decision to release provided there are at least three +1s. The RM is just the person doing the heavy lifting. Roy
Re: Backport of AllowEncodedSlashes to Apache 1.3
At 10:47 AM 3/29/2005, Jim Jagielski wrote: Since we're extending core_dir_config, we should document the change in core_dir_config Since the bit breaks binary compatibility, I'll toss my -1 into the ring. It's non-technical though, so not a veto. I wish we had pool datum, which would gracefully walk around this issue. But the patch may break mod_perl and other modules which do their own thing with per-dir configs. It's definately an mmn bump, major. Index: src/include/http_core.h === --- src/include/http_core.h (revision 158971) +++ src/include/http_core.h (working copy) @@ -318,6 +318,8 @@ /* Digest auth. */ char *ap_auth_nonce; +unsigned int allow_encoded_slashes : 1; /* URLs may contain %2f w/o being +* pitched indiscriminately */ } core_dir_config;
Re: So what is the real status of 2.1.x...
At 12:40 PM 3/29/2005, Justin Erenkrantz wrote: --On Tuesday, March 29, 2005 11:22 AM -0700 Brad Nicholes [EMAIL PROTECTED] wrote: Are we BETA yet or not? I am assuming that the true status is: OtherBill has consistently repeated that he will -1 anything entering beta. So, until he resolves his issues, we're at a standstill. Well, this beta/nobeta decision is a non-technical vote. So no, not a standstill, per say. Yes my vote was -1 on 2.1.3, both as a tarball, and a beta candidate. My current understanding is that OtherBill's -1 has some thing to do with APR-iconv and nothing at all with httpd. Yes, iconv is the final significant issue I have with a beta in principal. However... I also had a -host- of issues with 2.1.3, especially pcre changes, which I have fixed on svn trunk. So I was -1 for 2.1.3, period. If 2.1.3 included the old pcre, why release it? If it included those pcre changes, they needed to actually build. As of my last test, httpd trunk + apr 1.1.x trunk built clean. Note that there were other apr / apr-util issues, but I believe all of the remaining bullets except apr-iconv are closed. I'll take action today on the apr list to ensure we have some resolution by Friday, such that another tarball could be created, voted, and perhaps, voted to beta. Technical question; did we decide it's 2.1.x-beta, or 2.2.0-beta? As such, there's absolutely nothing [EMAIL PROTECTED] can do httpd has been doing fine... to remove his -1. Every time I have tried to remove his stated arguments against going beta (I lost count at 4 different rationales against beta), OtherBill suddenly presents more arguments as to why httpd can't enter beta. Justin, your answer was, with several specific problems to solve, to shove a tarball down our throats. Screw that. Good way to ensure my -1 your every attempt. But that's not my purpose, the only rational for my voting is, is the candidate for beta the best version of httpd available. I think we made some missteps, that the first httpd 2.0 beta and release could and should have been a bit more robust. I think we lost face with 2.0's early release, and have succeeded in regaining it. I want to avoid repeating that misstep and increase our users' confidence. Yes, I believe the candidate today falls short. I believe that we have several fundamental 2.0-specific issues to address. And like you, I've given up, only I've given up that these will make it into 2.2. Such things as more specific filtering semantics to order filter behavior, etc. So my only remaining objections are on specifics, and only those that should -not- change after beta. That includes the API and which apr we build from. One, is the use of iconv. I'm frankly ready to propose we dump it; it's widely supported only under the GPL, the FreeBSD port that GNU 'borrowed' is close to death. I'm hoping to change that. And I think there is a better proposal to be offered, which I'm tossing to apr this afternoon. Two, are two Win32 mechanical questions, which I'll toss at the list under a separate note. Would be a 15 minute project. I still maintain that the current state of trunk is sufficient to branch off 2.2.x (keeping the branch version at 2.1.x until we go GA with 2.2.0) and consequently bump trunk to 2.3.x today. -- justin And I still see no reason to do that until we vote 2.2.0-beta, until the day you want to commit something for the 2.4 (or even for the 3.0 track). Just as soon as you have anything that fits that criteria, seems perfectly rational to just jump into svn and create the new branch. Copies are cheap, no? Seems the biggest sticking point is the existence of /trunk, and what it means. I'd have no objection to getting rid of that stale concept entirely :) By all means, fork branches/2.3 today.
Forthcoming 2.2 - Win32 specific questions
'Apache' was our program. It became our project. It's become our entire organization. In 2.2, I -will- be changing the default location for the Win32 installer from %programsdir%\Apache Group\Apache2\ over to %programsdir%\Apache Software Foundation\Apache HTTP Server 2.2\. This is consistent with the Tomcat group's installer changes. They actually considered taking a step backwards and changing their installer from 'Software Foundation' to 'Group'. I assured them we will be changing to better reflect today's organization. As the unix binary is 'httpd', it seems time to change the Win32 binary to 'httpd.exe'. It just seems to be a bit archaic to continue to use 'Apache.exe' when you look at www.apache.org and consider what the foundation's become. So can I have a quick vote before beta to rename our program to 'httpd.exe' on Windows, matching our Unix builds? Bill
Re: [PROPOSAL] How to treat release candidate branches
+1, I agree with using Lazy Consensus(CTR) for non-API changes in a 2.2.x branch, until it reaches GA. -Paul Justin Erenkrantz wrote: Assuming that we can get a beta approved to eventually become 2.2.x, I'd like to propose the following policy that tries to balance the need for review with the need for stability: Any code changes can be backported to a release candidate branch from trunk via lazy consensus (CTR) if it does not change binary compatibility. However, if a change impacts binary compatibility or the external API in anyway (i.e. adds a new function or whatnot), it must receive 3 +1s before it can be committed to the release candidate branch (RTC). This way, we can add new features or binary-incompatible changes to a beta if three committers are in agreement that it should be present before the stable release. And, bug fixes ported back from trunk can be brought back with minimal hassle. At the point that we issue the first GA release, everything in that release candidate branch switches over to RTC (as we do right now for 2.0.x). Of course, this would not apply to trunk - which remains under CTR for all changes. For those who like concrete examples: If 2.1.3 is approved, we copy the tags/2.1.3 to branches/2.2.x. Trunk becomes 2.3.0. branches/2.2.x is immediately bumped to 2.1.4 (or perhaps 2.1.5 to identify those snapshots that came from the trunk before we branched). All changes must still hit the trunk (2.3.0) first. If you have a bug fix or a change that doesn't impact the API, it can be immediately backported to branches/2.2.x under CTR. If it changes the API in any way, it must enter branches/2.2.x/STATUS to receive votes for backport. What do ya'll think? -- justin
Re: Forthcoming 2.2 - Win32 specific questions
William A. Rowe, Jr. wrote: So can I have a quick vote before beta to rename our program to 'httpd.exe' on Windows, matching our Unix builds? Makes Sense, +1. -Paul
Re: Forthcoming 2.2 - Win32 specific questions
William A. Rowe, Jr. wrote: 'Apache' was our program. It became our project. It's become our entire organization. In 2.2, I -will- be changing the default location for the Win32 installer from %programsdir%\Apache Group\Apache2\ over to %programsdir%\Apache Software Foundation\Apache HTTP Server 2.2\. +1 This is consistent with the Tomcat group's installer changes. They actually considered taking a step backwards and changing their installer from 'Software Foundation' to 'Group'. I assured them we will be changing to better reflect today's organization. As the unix binary is 'httpd', it seems time to change the Win32 binary to 'httpd.exe'. It just seems to be a bit archaic to continue to use 'Apache.exe' when you look at www.apache.org and consider what the foundation's become. So can I have a quick vote before beta to rename our program to 'httpd.exe' on Windows, matching our Unix builds? +0. Changing to httpd.exe is consistent, but that's about all it has going for it. Any other httpd.exe's out there that could get lost in task manager? Bill
Re: Backport of AllowEncodedSlashes to Apache 1.3
William A. Rowe, Jr. wrote: At 10:47 AM 3/29/2005, Jim Jagielski wrote: Since we're extending core_dir_config, we should document the change in core_dir_config Since the bit breaks binary compatibility, I'll toss my -1 into the ring. It's non-technical though, so not a veto. I wish we had pool datum, which would gracefully walk around this issue. But the patch may break mod_perl and other modules which do their own thing with per-dir configs. It's definately an mmn bump, major. Other ones have not been (ap_auth_nonce). But looking things over, I see that unfortunately MODULE_MAGIC_NUMBER_MINOR was NOT updated when ap_auth_nonce was added, so we may have some silent issues floating around out there -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ There 10 types of people: those who read binary and everyone else.
Re: So what is the real status of 2.1.x...
On Mar 29, 2005, at 1:36 PM, William A. Rowe, Jr. wrote: to remove his -1. Every time I have tried to remove his stated arguments against going beta (I lost count at 4 different rationales against beta), OtherBill suddenly presents more arguments as to why httpd can't enter beta. Justin, your answer was, with several specific problems to solve, to shove a tarball down our throats. Screw that. Good way to ensure my -1 your every attempt. Bill, why don't you just fix whatever it is that you think of as broken rather than send negative votes? It can't possibly take as long as this to patch a bug, so maybe there is no bug to be patched, or the patch requires too much effort to consider, or you are simply too busy arguing about it to supply a fix? Pick one and solve it -- nobody here is going to stop you from fixing a bug in APR. If you think this is a showstopper, then I have no problem removing win32 from the list of supported platforms for Apache httpd -- in my opinion, that community of users is too lazy to support their own platform and we (as a project) cannot continue to rely on one person to do all of the necessary work to keep it up to date. I see no reason to treat Win32 as any more significant than Irix, at least not until we have a group of dedicated developers who care enough about that platform to keep up with its never-ending baggage of broken system libraries and compilers. It terms of technical issues, APR has no business shipping an implementation of iconv and I don't care if whatever is in that directory can't compile -- if it isn't supported, then delete iconv from APR and let people install it separately. Meanwhile, please end the paranoid crap you keep shoveling about Justin doing this or Justin doing that. He is following the guidelines and trying to make progress while at the same time trying to make sense of your cryptic problem reports and not step on any toes. At some point we have to stop trying to reach consensus on every platform and just make progress on those platforms with bodies to support them. Cheers, Roy T. Fieldinghttp://roy.gbiv.com/ Chief Scientist, Day Software http://www.day.com/
Re: Forthcoming 2.2 - Win32 specific questions
So can I have a quick vote before beta to rename our program to 'httpd.exe' on Windows, matching our Unix builds? That's change at a confuse-the-lusers level. I can just see the flood of where's apache.exe? questions on users@ and other fora. -- Nick Kew
Re: Enhancement of mod_charset_lite
Hello, for my personal needs i had to add some functionality to mod_charset_lite. Here is what i did: 1) Add an option AllowProxied that makes it work also on proxied requests (usefull in a reverse proxy environment which uses mod_proxy_html to return to the original encoding). 2) Add an option AdjustHeader that adjusts the content-type header according to the destination encoding. If someone is interested in these changes, i am not sure where to post them. Some such updates to mod_charset_lite have been on my wishlist for a long time! Nice to see you've tackled it. Did you enter your stuff into bugzilla as suggested by Brad? It sounds definitely worth looking at. -- Nick Kew
Re: So what is the real status of 2.1.x...
At 05:08 PM 3/29/2005, Roy T.Fielding wrote: On Mar 29, 2005, at 1:36 PM, William A. Rowe, Jr. wrote Bill, why don't you just fix whatever it is that you think of as broken rather than send negative votes? The last release simply came to quickly between announce of the intent and the tarball. As I say they most *all* are fixed now, and were fixed the evening before the tarball was expected to have been rolled. except for apr-iconv which the few commentors are at disagreement. I stopped to explain the right solution to the apr@ list, which I will then commit tomorrow barring any reasonable objections. So plan is patch Wednesday afternoon, tar and vote on apr for the apr-iconv release. Release as early as Thursday if we have 3+1's and httpd will have a new release to roll into 2.1.(5?) If you think this is a showstopper, then I have no problem removing win32 from the list of supported platforms for Apache httpd -- in my opinion, that community of users is too lazy to support their own platform and we (as a project) cannot continue to rely on one person to do all of the necessary work to keep it up to date. Little disagreement here but perhaps overreacting. If this is your wish propose it for a vote. I see no reason to treat Win32 as any more significant than Irix, at least not until we have a group of dedicated developers who care enough about that platform to keep up with its never-ending baggage of broken system libraries and compilers. Wholeheartedly agree. While I see enough traffic to know that many build on Win32 (for ssl, or module development, or whatever), but we know we don't see traffic to this list of other Win32 folks contributing. I can count on one hand how many Win32-centric contributors there are to httpd + apr, and on two hands how many have become proficient at 'stubbing in' new modules into the win32 build. I was pleasantly shocked and amazed in the cli-dev community to find a user who pointed out an issue, and then, proposed the fix! This is reassuring, perhaps the developers on the mod_aspdotnet side will find it productive to offer httpd code fixes back to our project when they discover httpd bugs. There are now about three not-Bill's contribute some diagnostics of the source code along with their problem reports. I hope several will stick around to become project members over the next few months. I just wonder if, as a % of users, are the Win32 users really that less contributing than, say linux users? Count the total number of folks running a linux server, divide by the number who have posted some code contribution to [EMAIL PROTECTED] Do the same for Win32. I'd suspect the difference isn't as great as you might imagine. It terms of technical issues, APR has no business shipping an implementation of iconv and I don't care if whatever is in that directory can't compile -- if it isn't supported, then delete iconv from APR and let people install it separately. I agree, and propose we remove pcre (from 2.0), regex (from 1.3) and expat (from apr). It doesn't mean we can't/won't provide the binary builds, built from the current stable release provided by those projects, when appropriate. Just as we do today for zlib (on win32, we ship the library built from zlib 1.1.4 src.) But these don't belong in our tree. Any disagreement? I would also propose we drop apr_xlate and mod_charset_lite if the only way to support this is GNU iconv, which incompatible with the ASL. However, as I mention I'm looking for some traction for a supported BSD-licensed version. FreeBSD has a new platform maintainer for that package, the newlib folks adopted it, so I'm hoping a community can be reformed around that code. Bill
Re: Backport of AllowEncodedSlashes to Apache 1.3
At 04:56 PM 3/29/2005, Jim Jagielski wrote: William A. Rowe, Jr. wrote: At 10:47 AM 3/29/2005, Jim Jagielski wrote: Since we're extending core_dir_config, we should document the change in core_dir_config Since the bit breaks binary compatibility, I'll toss my -1 into the ring. It's non-technical though, so not a veto. I wish we had pool datum, which would gracefully walk around this issue. But the patch may break mod_perl and other modules which do their own thing with per-dir configs. It's definately an mmn bump, major. Other ones have not been (ap_auth_nonce). But looking things over, I see that unfortunately MODULE_MAGIC_NUMBER_MINOR was NOT updated when ap_auth_nonce was added, so we may have some silent issues floating around out there Yup it needed a bump. But I have good news, and switch my vote to +0 (I still don't like rewrite interacting with encoded slashes)... I forgot that the create_core_dir_config member of the core_module is actually responsible for creating those dir configs, even for a third party module. No one should ever directly create that structure, so with an mmn minor bump mod_perl and so forth should not trip us up when the create their own dir sections. Bill
Re: Forthcoming 2.2 - Win32 specific questions
At 04:40 PM 3/29/2005, Bill Stoddard wrote: As the unix binary is 'httpd', it seems time to change the Win32 binary to 'httpd.exe'. It just seems to be a bit archaic to continue to use 'Apache.exe' when you look at www.apache.org and consider what the foundation's become. So can I have a quick vote before beta to rename our program to 'httpd.exe' on Windows, matching our Unix builds? +0. Changing to httpd.exe is consistent, but that's about all it has going for it. Any other httpd.exe's out there that could get lost in task manager? In the task manager, we set the 'Description' string to the server's signature so there can't be any confusion, methinks. The other reason I propose the change is that we have worked very hard for the benefit of other projects that we are the 'Apache HTTP Server' project (httpd for short) and have tried to quit using 'Apache' as if the HTTP project -is- the end-all, or purpose of the foundation. As to Nik's suggestion, I could see adding an Apache.bat (or more appropriately, ApacheCtl.bat) file that makes it easier to type common commands, following apachectl.sh. This would let users use the same apachectl startssl semantics, right now you have to either use -D SSL with -k start or -k config to accomplish it. The rename seems like a pre-beta change to me, while adding the Apache[Ctl].bat file could be during the beta process. Bill
Re: Backport of AllowEncodedSlashes to Apache 1.3
On Mar 29, 2005, at 8:47 AM, Jim Jagielski wrote: Since we're extending core_dir_config, we should document the change in core_dir_config Should I elaborate more in my core_dir_config from what I already have? Index: src/include/http_core.h === --- src/include/http_core.h (revision 158971) +++ src/include/http_core.h (working copy) @@ -318,6 +318,8 @@ /* Digest auth. */ char *ap_auth_nonce; +unsigned int allow_encoded_slashes : 1; /* URLs may contain %2f w/o being +* pitched indiscriminately */ } core_dir_config; /* Per-server core configuration */
