[PATCH] mpm_winnt fix the ap_mpm_query
Hi, The patch enables finding a child slot in the scoreboard using find_child_by_pid. Right now the reported number of childs is 0 which is not true, cause we have a single child, and it is in the scoreboard image already. It's not a big problem, but disables writing portable code among different platforms, cause Netware will always report 1, and the unix versions >= 1, and the WIN report that as 0! Index: mpm_winnt.c === RCS file: /home/cvspublic/httpd-2.0/server/mpm/winnt/mpm_winnt.c,v retrieving revision 1.285 diff -u -3 -r1.285 mpm_winnt.c --- mpm_winnt.c 2 Jul 2002 19:03:15 - 1.285 +++ mpm_winnt.c 4 Jul 2002 06:23:24 - @@ -57,6 +57,7 @@ */ #define CORE_PRIVATE + #include "httpd.h" #include "http_main.h" #include "http_log.h" @@ -1969,7 +1970,7 @@ *result = ap_max_requests_per_child; return APR_SUCCESS; case AP_MPMQ_MAX_DAEMONS: -*result = 0; +*result = 1; return APR_SUCCESS; } return APR_ENOTIMPL; MT.
[STATUS] (httpd-2.0) Wed Jul 3 23:45:13 EDT 2002
APACHE 2.0 STATUS: -*-text-*- Last modified at [$Date: 2002/06/28 20:16:26 $] Release: 2.0.40 : in development. 2.0.39 : rolled June 17, 2002. 2.0.38 : rolled June 16, 2002. not released. 2.0.37 : rolled June 11, 2002. not released. 2.0.36 : released May 6, 2002 as GA. 2.0.35 : released April 5, 2002 as GA. 2.0.34 : tagged March 26, 2002. 2.0.33 : tagged March 6, 2002. not released. 2.0.32 : released Feburary 16, 2002 as beta. 2.0.31 : rolled Feburary 1, 2002. not released. 2.0.30 : tagged January 8, 2002. not rolled. 2.0.29 : tagged November 27, 2001. not rolled. 2.0.28 : released November 13, 2001 as beta. 2.0.27 : rolled November 6, 2001 2.0.26 : tagged October 16, 2001. not rolled. 2.0.25 : rolled August 29, 2001 2.0.24 : rolled August 18, 2001 2.0.23 : rolled August 9, 2001 2.0.22 : rolled July 29, 2001 2.0.21 : rolled July 20, 2001 2.0.20 : rolled July 8, 2001 2.0.19 : rolled June 27, 2001 2.0.18 : rolled May 18, 2001 2.0.17 : rolled April 17, 2001 2.0.16 : rolled April 4, 2001 2.0.15 : rolled March 21, 2001 2.0.14 : rolled March 7, 2001 2.0a9 : released December 12, 2000 2.0a8 : released November 20, 2000 2.0a7 : released October 8, 2000 2.0a6 : released August 18, 2000 2.0a5 : released August 4, 2000 2.0a4 : released June 7, 2000 2.0a3 : released April 28, 2000 2.0a2 : released March 31, 2000 2.0a1 : released March 10, 2000 Please consult the following STATUS files for information on related projects: * srclib/apr/STATUS * srclib/apr-util/STATUS * docs/STATUS CURRENT RELEASE NOTES: RELEASE SHOWSTOPPERS: * apr_sendfile() is broken on FreeBSD 4.6-STABLE as of 20020627 (and presumably more leading edge levels) because of a "fix" in the kernel. Apache 2.0.39 is unreliable on that kernel. CURRENT VOTES: * apachectl should revert to just being an init script and httpd.sh should be the wrapper for httpd which sources envvars and allows any options to be passed through +1: trawick * Should we always build [support*] binaries statically unless otherwise indicated? Message-ID: <[EMAIL PROTECTED]> +1: Ken, *wrowe [they are PITAs on OSX] -1: Justin, Ian * If the parent process dies, should the remaining child processes "gracefully" self-terminate. Or maybe we should make it a runtime option, or have a concept of 2 parent processes (one being a "hot spare"). See: Message-ID: <[EMAIL PROTECTED]> Self-destruct: Ken, Martin Not self-destruct: BrianP, Ian, Cliff, BillS Make it runtime configurable: Aaron, Jim, Justin Have 2 parents: +1: Jim -1: Justin, wrowe [for 2.0] +0: Martin (while standing by, could it do something useful?) * Make the worker MPM the default MPM for threaded Unix boxes. +1: Justin, Ian, Cliff, BillS +0: BrianP, Aaron (mutex contention is looking better with the latest code, let's continue tuning and testing) -0: Lars RELEASE NON-SHOWSTOPPERS BUT WOULD BE REAL NICE TO WRAP THESE UP: * All handlers should always send content down even if r->header_only is set. If not, it means that the HEAD requests don't generate the same headers as a GET which is wrong. Is this a showstopper? +1: Justin -1: Aaron * server pushed CGI's not working. (Is this a showstopper??) PR: 8482 Message-ID: <[EMAIL PROTECTED]> * HP/UX 10.20: compile breakage in APR. Looks like it should be easy to fix, probably just some extraneous #include's that are fouling things up. PR: 9457 Jeff: See my reply and patch in the PR (and previous commit to stop using "pipe" as a field name). If patch is committed, we should be okay. I'll wait to see if the user tests the patch. * exec cmd and suexec arg-passing enhancements Status: Patches proposed Message-ID: <[EMAIL PROTECTED]> (see the "proc.patch" and "suexec-shell.patch" links in this message) * Get mod_cache/mod_mem_cache out of experimental (still some work items left to complete) * The 2.0.36 worker MPM graceless shutdown changes work but are a bit clunky on some platforms; eg, on Linux, the loop to join each worker thread seems to hang, and the parent ends up killing off the child with SIGKILL. But at least it shuts down. * --enable-mods-shared="foo1 foo2" is busted on Darwin. Pier posted a patch (Message-ID: <[EMAIL PROTECTED]>). * We do not properly substitute the prefix-variables in the configuration scripts or generated-configs. (i.e. if sysconfdir is etc, httpd-std.conf point
[STATUS] (apache-1.3) Wed Jul 3 23:45:08 EDT 2002
APACHE 1.3 STATUS: -*-text-*- Last modified at [$Date: 2002/06/27 20:57:21 $] Release: 1.3.27-dev: In development 1.3.26: Tagged June 18, 2002. 1.3.25: Tagged June 17, 2002. Not released. 1.3.24: Tagged Mar 21, 2002. Announced Mar 22, 2002. 1.3.23: Tagged Jan 21, 2002. 1.3.22: Tagged Oct 8, 2001. Announced Oct 12, 2001. 1.3.21: Not released. (Pulled for htdocs/manual config mismatch. t/r Oct 5, 2001) 1.3.20: Tagged and rolled May 15, 2001. Announced May 21, 2001. 1.3.19: Tagged and rolled Feb 26, 2001. Announced Mar 01, 2001. 1.3.18: Tagged and rolled Not released. (Pulled because of an incorrect unescaping fix. t/r Feb 19, 2001) 1.3.17: Tagged and rolled Jan 26, 2001. Announced Jan 29, 2001. 1.3.16: Not released. (Pulled because of vhosting bug. t/r Jan 20, 2001) 1.3.15: Not released. (Pulled due to CVS dumping core during the tagging when it reached src/os/win32/) 1.3.14: Tagged and Rolled Oct 10, 2000. Released/announced on the 13th. 1.3.13: Not released. (Pulled in the "first minutes" due to a Netware build bug) 1.3.12: Tagged and rolled Feb. 23, 2000. Released/announced on the 25th. 1.3.11: Tagged and rolled Jan. 19, 2000. Released/announced on the 21st. 1.3.10: Not released. (Pulled at "last minute" due to a build bug in the MPE port) 1.3.9: Tagged and rolled on Aug. 16. Released and announced on 19th. 1.3.8: Not released. 1.3.7: Not released. 1.3.6: Tagged and rolled on Mar. 22. Released and announced on 24th. 1.3.5: Not released. 1.3.4: Tagged and rolled on Jan. 9. Released on 11th, announced on 12th. 1.3.3: Tagged and rolled on Oct. 7. Released on 9th, announced on 10th. 1.3.2: Tagged and rolled on Sep. 21. Announced and released on 23rd. 1.3.1: Tagged and rolled on July 19. Announced and released. 1.3.0: Tagged and rolled on June 1. Announced and released on the 6th. 2.0 : Available for general use, see httpd-2.0 repository RELEASE SHOWSTOPPERS: * Current vote on 2 PRs for inclusion: Bugz #9181 (Unable to set headers on non-2XX responses) +1: Martin, Jim Gnats #10246 (Add ProxyConnAllow directive) +0: Martin (or rather -.5, see dev@ Message <[EMAIL PROTECTED]>) RELEASE NON-SHOWSTOPPERS BUT WOULD BE REAL NICE TO WRAP THESE UP: * htpasswd.c and htdigest.c use tmpnam()... consider using mkstemp() when available. Message-ID: <[EMAIL PROTECTED]> Status: * Dean's "unescaping hell" (unescaping the various URI components at the right time and place, esp. unescaping the host name). Message-ID: <[EMAIL PROTECTED]> Status: * Martin observed a core dump because a ipaddr_chain struct contains a NULL-"server" pointer when being dereferenced by invoking "httpd -S". Message-ID: <[EMAIL PROTECTED]> Status: Workaround enabled. Clean solution can come after 1.3.19 * long pathnames with many components and no AllowOverride None Workaround is to define with AllowOverride None, which is something all sites should do in any case. Status: Marc was looking at it. (Will asks 'wasn't this patched?') * Ronald Tschalär's patch to mod_proxy to allow other modules to set headers too (needed by mod_auth_digest) Message-ID: <[EMAIL PROTECTED]> Status: Available Patches (Most likely, will be ported to 2.0 as appropriate): * Backport of 2.0 ForceLanguagePriority directive /dist/httpd/contrib/patches/1.3/force_language_priority.patch Message-ID: <[EMAIL PROTECTED]> Status: * A rewrite of ap_unparse_uri_components() by Jeffrey W. Baker <[EMAIL PROTECTED]> to more fully close some segfault potential. Message-ID: Status: Jim +1 (for 1.3.19), Martin +0 * Andrew Ford's patch (1999/12/05) to add absolute times to mod_expires Message-ID: <[EMAIL PROTECTED]> Status: Martin +1, Jim +1, Ken +1 (on concept) * Raymond S Brand's path to mod_autoindex to fix the header/readme include processing so the envariables are correct for the included documents. (Actually, there are two variants in the patch message, for two different ways of doing it.) Message-ID: <[EMAIL PROTECTED]> Status: Martin +1(concept) * Jayaram's patch (10/27/99) for bugfix to mod_autoindex IndexIgnore should hide the files with this file- extension in directory listings. This was NOT happening because the total filename was being compared with the file-extension. Status: Martin +1(untested), Ken +1(untested) * Salvador Ortiz Garcia <[EMAIL PROTECTED]>' patch to allow DirectoryIndex to refer to URIs for non-static resources. MID: <[EMAIL PROTECTED]> Statu
RE: [PATCH] optimized reading of request headers
This is an analysis of one request from ap_read_request to ap_graceful_stop_signalled serving file out of mod_mem_cache, with a couple of hacks (which I am working to turn into production quality patches) to bypass ap_http_header_filter... Before Jeff's poll-timeout patch: 58115 instructions (this is from the last profile I posted) Apply Jeff's patch: 54888 instructions (I have not posted this profile) Apply Jeff's patch and this patch: 51917 instructions (profile posted here) Definitely going in the right direction! Space %Cycles = = User 20.0 45126 Shared Library45.4 102161 Kernel34.6 77821 Total 225108 (4.34 per instruction) /usr/local/apachetest/bin/httpd : Subroutine Name Source File Ratio Enter % Cycles === === = = == .core_input_filter core.c3.11 11 1.6 3591 .ap_rgetline_coreprotocol.c3.02 6 1.3 3025 .get_filter_handle util_filter.c 4.84 2 1.3 2859 .add_any_filter_handle util_filter.c 4.18 6 0.9 1997 .net_time_filter core.c3.16 12 0.8 1869 ._ptrgl ptrgl.s 4.58 66 0.8 1814 .core_output_filter core.c4.22 2 0.8 1708 .fix_hostnamevhost.c 3.61 1 0.7 1610 .add_any_filter util_filter.c 5.60 1 0.6 1439 .ap_update_child_status_from_indexes scoreboard.c 15.29 2 0.5 1223 .ap_get_brigade util_filter.c 3.61 25 0.5 1172 ._moveeq moveeq.s 5.08 14 0.5 1102 .ap_find_token util.c4.60 3 0.5 1052 .ap_get_mime_headers_core protocol.c 3.22 1 0.3 753 .ap_read_request protocol.c5.23 1 0.3 753 .ap_set_keepalivehttp_protocol.c 5.06 1 0.3 749 .ap_getword_whiteutil.c2.85 2 0.3 724 .log_error_core log.c 5.42 4 0.3 651 .ap_pass_brigade util_filter.c 5.35 5 0.3 647 .isspace glink.s 4.51 22 0.3 596 .apr_palloc glink.s 4.27 22 0.3 563 .core_create_req core.c9.43 1 0.2 547 .read_request_line protocol.c4.13 1 0.2 516 .ap_content_length_filter protocol.c 3.14 1 0.2 496 .ap_http_filter http_protocol.c 4.73 2 0.2 468 .apr_brigade_cleanup glink.s 6.83 11 0.2 451 .apr_table_get glink.s 5.76 12 0.2 414 .ap_recent_rfc822_date util_time.c 2.16 1 0.2 410 .tolower glink.s 3.55 19 0.2 404 .isalpha glink.s 3.32 19 0.2 378 .ap_run_log_transaction protocol.c 11.21 1 0.2 370 .writev_it_all core.c7.48 1 0.1 336 .ap_add_output_filters_by_type core.c 13.68 1 0.1 315 .ap_process_http_connection http_core.c8.31 0 0.1 291 .ap_run_quick_handlerconfig.c 10.26 1 0.1 287 .ap_run_create_request request.c 6.30 1 0.1 283 .ap_run_post_read_request protocol.c 8.19 1 0.1 278 .basic_http_header http_protocol.c 3.29 1 0.1 276 .avoid_xlc_bug core.c6.17 11 0.1 272 .ap_log_errorlog.c 2.99 4 0.1 263 .cached_explode util_time.c 3.86 1 0.1 251 .apr_setsocketoptglink.s 3.53 11 0.1 233 .ap_discard_request_body http_protocol.c 3.14 1 0.1 223 .ap_process_request http_request.c8.05 1 0.1 217 .lookup_builtin_method http_protocol.c 7.99 1 0.1 216 .apr_table_make glink.s 5.83 6 0.1 210 .ap_parse_uriprotocol.c4.75 1 0.1 209 .http_create_request http_core.c 5.43 1 0.1 206 .ap_get_server_version core.c 40.44 1 0.1 202 .apr_brigade_split_line glink.s 5.61 6 0.1 202 .__divi64glink.s 11.09 3 0.1 200 .ap_update_vhost_from_headers vhost.c 6.37 1 0.1 197 .basic_http_header_check http_protocol.c 4.70 1 0.1 197 .apr_brigade_putsglink.s
Re: Christopher Williamson: URGENT: Bug/compatability issue in Apache 1.3.26
Aaron Bannert wrote: > > > Can't they offer a patch for their existing user base? I'm not > > unsympathetic, but introducing these kind of hacks seems like it would > > make the code grow more complicated with each change in server behavior. > > That might work in some cases, but if they are under a controlled/hosting > environment, it is unlikely that their hosts will allow unchecked patches > to be applied to the server. It just seems to me like one of those times > where we inadvertently broke the principle of least surprise. > > -aaron I meant a patch to their product, not Apache. -- Jerry Baker
[PATCH] optimized reading of request headers
This patch uses the same temp brigade to read all the lines of
an HTTP request, in order to eliminate the overhead of brigade
creation and destruction that we've seen in recent performance
profiling. The patch changes the signature of ap_rgetline_core()
and adds a new ap_get_mime_headers_core(), but it leaves ap_getline()
unchanged for compatibility with code outside the core (like
mod_proxy).
Bill S: if you have time, can you try this code in your benchmarking
environment?
Thanks,
--Brian
Index: include/http_protocol.h
===
RCS file: /home/cvs/httpd-2.0/include/http_protocol.h,v
retrieving revision 1.81
diff -u -r1.81 http_protocol.h
--- include/http_protocol.h 31 May 2002 05:03:09 - 1.81
+++ include/http_protocol.h 3 Jul 2002 22:38:05 -
@@ -95,7 +95,16 @@
* Read the mime-encoded headers.
* @param r The current request
*/
-void ap_get_mime_headers(request_rec *r);
+AP_DECLARE(void) ap_get_mime_headers(request_rec *r);
+
+/**
+ * Optimized version of ap_get_mime_headers() that requires a
+ * temporary brigade to work with
+ * @param r The current request
+ * @param bb temp brigade
+ */
+AP_DECLARE(void) ap_get_mime_headers_core(request_rec *r,
+ apr_bucket_brigade *bb);
/* Finish up stuff after a request */
@@ -573,6 +582,7 @@
* @param read The length of the line.
* @param r The request
* @param fold Whether to merge continuation lines
+ * @param bb Working brigade to use when reading buckets
* @return APR_SUCCESS, if successful
* APR_ENOSPC, if the line is too big to fit in the buffer
* Other errors where appropriate
@@ -580,14 +590,16 @@
#if APR_CHARSET_EBCDIC
AP_DECLARE(apr_status_t) ap_rgetline(char **s, apr_size_t n,
apr_size_t *read,
- request_rec *r, int fold);
+ request_rec *r, int fold,
+ apr_bucket_brigade *bb);
#else /* ASCII box */
-#define ap_rgetline(s, n, read, r, fold) \
-ap_rgetline_core((s), (n), (read), (r), (fold))
+#define ap_rgetline(s, n, read, r, fold, bb) \
+ap_rgetline_core((s), (n), (read), (r), (fold), (bb))
#endif
AP_DECLARE(apr_status_t) ap_rgetline_core(char **s, apr_size_t n,
apr_size_t *read,
- request_rec *r, int fold);
+ request_rec *r, int fold,
+ apr_bucket_brigade *bb);
/**
* Get the method number associated with the given string, assumed to
Index: server/protocol.c
===
RCS file: /home/cvs/httpd-2.0/server/protocol.c,v
retrieving revision 1.109
diff -u -r1.109 protocol.c
--- server/protocol.c 2 Jul 2002 23:51:21 - 1.109
+++ server/protocol.c 3 Jul 2002 22:38:05 -
@@ -243,31 +243,28 @@
*/
AP_DECLARE(apr_status_t) ap_rgetline_core(char **s, apr_size_t n,
apr_size_t *read, request_rec *r,
- int fold)
+ int fold, apr_bucket_brigade *bb)
{
apr_status_t rv;
-apr_bucket_brigade *b;
apr_bucket *e;
apr_size_t bytes_handled = 0, current_alloc = 0;
char *pos, *last_char = *s;
int do_alloc = (*s == NULL), saw_eos = 0;
-b = apr_brigade_create(r->pool, r->connection->bucket_alloc);
-rv = ap_get_brigade(r->input_filters, b, AP_MODE_GETLINE,
+apr_brigade_cleanup(bb);
+rv = ap_get_brigade(r->input_filters, bb, AP_MODE_GETLINE,
APR_BLOCK_READ, 0);
if (rv != APR_SUCCESS) {
-apr_brigade_destroy(b);
return rv;
}
/* Something horribly wrong happened. Someone didn't block! */
-if (APR_BRIGADE_EMPTY(b)) {
-apr_brigade_destroy(b);
+if (APR_BRIGADE_EMPTY(bb)) {
return APR_EGENERAL;
}
-APR_BRIGADE_FOREACH(e, b) {
+APR_BRIGADE_FOREACH(e, bb) {
const char *str;
apr_size_t len;
@@ -280,7 +277,6 @@
rv = apr_bucket_read(e, &str, &len, APR_BLOCK_READ);
if (rv != APR_SUCCESS) {
-apr_brigade_destroy(b);
return rv;
}
@@ -294,7 +290,6 @@
/* Would this overrun our buffer? If so, we'll die. */
if (n < bytes_handled + len) {
-apr_brigade_destroy(b);
return APR_ENOSPC;
}
@@ -342,7 +337,6 @@
*/
if (bytes_handled == 0) {
*read = 0;
-apr_brigade_destroy(b);
return APR_SUCCESS;
}
@@ -365,10 +359,9 @@
next_size = n - bytes_handled;
-rv = ap_rgetline_core(&tmp, next_size, &next_len, r, fold);
+rv = ap_rgetline_core(&tmp, next_size, &next_len, r, f
Re: Christopher Williamson: URGENT: Bug/compatability issue in Apache 1.3.26
http://www.apache.org/dist/httpd/patches/ has patches for every released version of Apache 1.2.x and 1.3.x On Wed, 3 Jul 2002, Andrew Ho wrote: > Hello, > > Is there a patch for earlier versions of Apache that fix the chunked > Transfer-Encoding security hole, but nothing else? I know OpenBSD, for > example, has an Apache 1.3.24 in ports that has the chunked > Transfer-Encoding fixed. That would certainly be a good short term > solution for this guy--it doesn't sound like it's a good idea for him to > wait for 1.3.27! > > Humbly, > > Andrew > > -- > Andrew Ho http://www.tellme.com/ [EMAIL PROTECTED] > Engineer [EMAIL PROTECTED] Voice 650-930-9062 > Tellme Networks, Inc. 1-800-555-TELLFax 650-930-9101 > -- >
Re: Christopher Williamson: URGENT: Bug/compatability issue in Apache 1.3.26
Hello, Is there a patch for earlier versions of Apache that fix the chunked Transfer-Encoding security hole, but nothing else? I know OpenBSD, for example, has an Apache 1.3.24 in ports that has the chunked Transfer-Encoding fixed. That would certainly be a good short term solution for this guy--it doesn't sound like it's a good idea for him to wait for 1.3.27! Humbly, Andrew -- Andrew Ho http://www.tellme.com/ [EMAIL PROTECTED] Engineer [EMAIL PROTECTED] Voice 650-930-9062 Tellme Networks, Inc. 1-800-555-TELLFax 650-930-9101 --
Re: Christopher Williamson: URGENT: Bug/compatability issue in Apache 1.3.26
On Wed, 3 Jul 2002, Rodent of Unusual Size wrote: >> Not acked (by me, at least). I can feel their pain.. .. > I am sure I am not the only one with this problem, as there are several > socket tutorials and such that incorrectly say 'HTTP-1.0'. Now he has a case - the above is true; I've correted this at least twice in translations - and we could be leisure in what we expect and still be strict in what we sent. But then again - the very fact that HTTP-1.0 worked... is to be blamed on that same priciple. Dw
Re: Christopher Williamson: URGENT: Bug/compatability issue in Apache 1.3.26
> > controlled/hosting environment, it is unlikely that their > > hosts will allow unchecked patches to be applied to the server. > > Also, we rather violated the principle of 'be strict in what you > send, liberal in what you accept.' We suddenly became 'strict in > what you accept' without warning or relief. Good argument - you convinced me. +1 to go back to: > Principle of Least Astonishment. I am willing to code it (for 1.3 only) and willing to make it a config directive (with the default to be liberal). Dw
Re: Christopher Williamson: URGENT: Bug/compatability issue in Apache
FWIW: httpd-2.0 does not appear to perform this check... +0 for removing the check +1 for making it runtime either way :) Jim Jagielski wrote: > > Hrm I would be prone to either removing this patch, or at least > redoing it. As some of you may recall, I mentioned this area a little > bit ago regarding our use and expectation of ANSI sscanf() here as > well. > > > Original Message > > Subject: Christopher Williamson: URGENT: Bug/compatability issue in Apache 1.3.26 > > Date: Wed, 03 Jul 2002 12:49:26 -0600 > > From: Christopher Williamson <[EMAIL PROTECTED]> > > To: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] > > > > Due to an error in OUR online game code, we were incorrectly requesting > > files using 'HTTP-1.0' instead of 'HTTP/1.0' on the GET request line. As you > > know, this is wrong. However, suprisingly, this worked just fine for several > > years with both Apache and other Web servers, presumably because the server > > just ignored it or defaulted to HTTP/1.0. -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ "A society that will trade a little liberty for a little order will lose both and deserve neither" - T.Jefferson
CGI 1.1 Compliance wrt CGI-sent status codes.
Problem:
Apache 1.3.x breaks the CGI 1.1 specification with its handling of
script-generated status codes. It appears to work in the case of status 302,
but this appearance is only maintained via an uncoditional redirect in the
cast that the "location" header is set and an OK status exists.
Referring to the spec:
http://CGI-Spec.Golux.Com/draft-coar-cgi-v11-03-clean.html#7.2.1.3
we have:
'The "Status" header field is used to indicate to the server what status code
the server MUST use in the response message.'
I have not confirmed that this problem exists in Apache httpd 2.x
Solution:
The following patch to mod_cgi.c has been used in a production environment
for some time now. Any comments/critique are welcome.
Disclaimer:
If I happen to be way off base on this, please feel free to let me know.
-Wade Klaver
570a571,575
> else if ( r->status != 200 ) {
> /* CGI set a status code try to observe it */
> return r->status;
> }
>
Re: Christopher Williamson: URGENT: Bug/compatability issue in Apache
Hrm I would be prone to either removing this patch, or at least redoing it. As some of you may recall, I mentioned this area a little bit ago regarding our use and expectation of ANSI sscanf() here as well. However, isn't what we are doing correct? It *is* an invalid protocol statement... I'd be willing to wrap this in a new directive, so we have both. Rodent of Unusual Size wrote: > > Not acked (by me, at least). I can feel their pain.. > > Original Message > Subject: Christopher Williamson: URGENT: Bug/compatability issue in Apache 1.3.26 > Date: Wed, 03 Jul 2002 12:49:26 -0600 > From: Christopher Williamson <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] > > I sent this a week ago directly to Martin and never got a response, can anyone > else please help? If not, I will open a bug in BugZilla about it. > > --- Forwarded Message > > Forwarded: Tue, 25 Jun 2002 22:39:36 -0600 > Forwarded: "jon,ben,roden " > Subject: URGENT: Bug/compatability issue in Apache 1.3.26 > To: [EMAIL PROTECTED] > X-URL: http://www.dq.com/ > Date: Tue, 25 Jun 2002 17:52:59 -0600 > From: Christopher Williamson > > I am writing in hopes that you can help us with an urgent problem we are > having with a bug fix you put into Apache 1.3.26 I have spent two days > tracking this down and am certain the issue is with your fix. > > Due to an error in OUR online game code, we were incorrectly requesting > files using 'HTTP-1.0' instead of 'HTTP/1.0' on the GET request line. As you > know, this is wrong. However, suprisingly, this worked just fine for several > years with both Apache and other Web servers, presumably because the server > just ignored it or defaulted to HTTP/1.0. If you want to test, try our > down-level Apache server at lobby.dqsoft.com with GET /index.html HTTP-1.0 > I am sure I am not the only one with this problem, as there are several > socket tutorials and such that incorrectly say 'HTTP-1.0'. > > However, as of 1.3.26 this GET request now results in a 400 Bad Request > and as a result, all of our current online games cannot retrieve the config > files causing numerous problems. > > You would correctly argue that we should fix this on our end, which we already > have done. However, the 'we are screwed' part is that the 50,000 some odd > folks out there with our online games can no longer get news, updates, alerts, > etc. from our Web site using Apache. To make matters worse, we cant simply > redirect the files since the requests fail immediately, the only solution for > us is to switch to a M$ server or a down-level Apache build with the security > vulnerability for our entire domain! > > In the short-term, I am convincing our Web hosts to move us to a down-level > server. However, I would like to ask if you would please strongly consider > putting a 'fix' into the next Apache release to handle this incorrect format > in a backward-compatible fashion. When the next update occurs, we can ask > our host to then upgrade us knowing that our old games will still work > without compromising our site's security or resorting to a competing server. > > I thank you for your time and support of Apache. If you need help or > clarification, please dont hesitate to write back. Even just a quick > 'we are looking into it' would help me rest easier. > > Christopher Williamson > President, DreamQuest Software (http://dq.com/) > "Championship Spades is the first cross-platform wireless game!" > > --- End of Forwarded Message > -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ "A society that will trade a little liberty for a little order will lose both and deserve neither" - T.Jefferson
RE: Christopher Williamson: URGENT: Bug/compatability issue in Apache 1.3.26
> > Aaron Bannert wrote: > > > > On Wed, Jul 03, 2002 at 01:19:53PM -0600, Jerry Baker wrote: > > > > > > Can't they offer a patch for their existing user base? I'm not > > > unsympathetic, but introducing these kind of hacks seems like it > > > would make the code grow more complicated with each > change in server > > > behavior. > > > > That might work in some cases, but if they are under a > > controlled/hosting environment, it is unlikely that their > hosts will > > allow unchecked patches to be applied to the server. > > Also, we rather violated the principle of 'be strict in what > you send, liberal in what you accept.' We suddenly became > 'strict in what you accept' without warning or relief. Agreed. +1 to revert this back to a more liberal accept mode.
Re: quick docs patch..
James Cox wrote: > > Quick patch to bring some old docs up-to-date. Should be sent to the [EMAIL PROTECTED] list rather than the code development list.. -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/ Author, developer, opinionist http://Apache-Server.Com/ "Millennium hand and shrimp!"
Re: Christopher Williamson: URGENT: Bug/compatability issue in Apache 1.3.26
Aaron Bannert wrote: > > On Wed, Jul 03, 2002 at 01:19:53PM -0600, Jerry Baker wrote: > > > > Can't they offer a patch for their existing user base? I'm not > > unsympathetic, but introducing these kind of hacks seems like it > > would make the code grow more complicated with each change in > > server behavior. > > That might work in some cases, but if they are under a > controlled/hosting environment, it is unlikely that their > hosts will allow unchecked patches to be applied to the server. Also, we rather violated the principle of 'be strict in what you send, liberal in what you accept.' We suddenly became 'strict in what you accept' without warning or relief. > It just seems to me like one of those times > where we inadvertently broke the principle > of least surprise. Principle of Least Astonishment. -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/ Author, developer, opinionist http://Apache-Server.Com/ "Millennium hand and shrimp!"
Re: Christopher Williamson: URGENT: Bug/compatability issue in Apache 1.3.26
On Wed, Jul 03, 2002 at 01:19:53PM -0600, Jerry Baker wrote: > > Same here, I'm sympathetic. I think that it might be beneficial to > > introduce an "Enable old behavior for backward-compatibility" mode, for > > just these occasions where we have altered the behaviour of the server > > to be more strict on protocol parsing. > > Can't they offer a patch for their existing user base? I'm not > unsympathetic, but introducing these kind of hacks seems like it would > make the code grow more complicated with each change in server behavior. That might work in some cases, but if they are under a controlled/hosting environment, it is unlikely that their hosts will allow unchecked patches to be applied to the server. It just seems to me like one of those times where we inadvertently broke the principle of least surprise. -aaron
Re: Christopher Williamson: URGENT: Bug/compatability issue in Apache 1.3.26
Aaron Bannert wrote: > > On Wed, Jul 03, 2002 at 03:15:51PM -0400, Rodent of Unusual Size wrote: > > I can feel their pain.. > > Same here, I'm sympathetic. I think that it might be beneficial to > introduce an "Enable old behavior for backward-compatibility" mode, for > just these occasions where we have altered the behaviour of the server > to be more strict on protocol parsing. > > -aaron Can't they offer a patch for their existing user base? I'm not unsympathetic, but introducing these kind of hacks seems like it would make the code grow more complicated with each change in server behavior. -- Jerry Baker
Re: Christopher Williamson: URGENT: Bug/compatability issue in Apache 1.3.26
On Wed, Jul 03, 2002 at 03:15:51PM -0400, Rodent of Unusual Size wrote: > I can feel their pain.. Same here, I'm sympathetic. I think that it might be beneficial to introduce an "Enable old behavior for backward-compatibility" mode, for just these occasions where we have altered the behaviour of the server to be more strict on protocol parsing. -aaron
Re: Christopher Williamson: URGENT: Bug/compatability issue in Apache 1.3.26
Not acked (by me, at least). I can feel their pain.. Original Message Subject: Christopher Williamson: URGENT: Bug/compatability issue in Apache 1.3.26 Date: Wed, 03 Jul 2002 12:49:26 -0600 From: Christopher Williamson <[EMAIL PROTECTED]> To: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] I sent this a week ago directly to Martin and never got a response, can anyone else please help? If not, I will open a bug in BugZilla about it. --- Forwarded Message Forwarded: Tue, 25 Jun 2002 22:39:36 -0600 Forwarded: "jon,ben,roden " Subject: URGENT: Bug/compatability issue in Apache 1.3.26 To: [EMAIL PROTECTED] X-URL: http://www.dq.com/ Date: Tue, 25 Jun 2002 17:52:59 -0600 From: Christopher Williamson I am writing in hopes that you can help us with an urgent problem we are having with a bug fix you put into Apache 1.3.26 I have spent two days tracking this down and am certain the issue is with your fix. Due to an error in OUR online game code, we were incorrectly requesting files using 'HTTP-1.0' instead of 'HTTP/1.0' on the GET request line. As you know, this is wrong. However, suprisingly, this worked just fine for several years with both Apache and other Web servers, presumably because the server just ignored it or defaulted to HTTP/1.0. If you want to test, try our down-level Apache server at lobby.dqsoft.com with GET /index.html HTTP-1.0 I am sure I am not the only one with this problem, as there are several socket tutorials and such that incorrectly say 'HTTP-1.0'. However, as of 1.3.26 this GET request now results in a 400 Bad Request and as a result, all of our current online games cannot retrieve the config files causing numerous problems. You would correctly argue that we should fix this on our end, which we already have done. However, the 'we are screwed' part is that the 50,000 some odd folks out there with our online games can no longer get news, updates, alerts, etc. from our Web site using Apache. To make matters worse, we cant simply redirect the files since the requests fail immediately, the only solution for us is to switch to a M$ server or a down-level Apache build with the security vulnerability for our entire domain! In the short-term, I am convincing our Web hosts to move us to a down-level server. However, I would like to ask if you would please strongly consider putting a 'fix' into the next Apache release to handle this incorrect format in a backward-compatible fashion. When the next update occurs, we can ask our host to then upgrade us knowing that our old games will still work without compromising our site's security or resorting to a competing server. I thank you for your time and support of Apache. If you need help or clarification, please dont hesitate to write back. Even just a quick 'we are looking into it' would help me rest easier. Christopher Williamson President, DreamQuest Software (http://dq.com/) "Championship Spades is the first cross-platform wireless game!" --- End of Forwarded Message
Re: URL parsing changed between 1.3.23 and 1.3.26?
Cliff Woolley wrote: > You're supposed to encode a query string like so: > > http://myserver.com/file.html?arg1=val1&arg2=val2&arg3=val3 Sure, but we also support path info, which can be used like a query string: http://bugs.apache.org/index.cgi/full/3708 to get some Chinese spam, and Marc's subtle reply. Greg
RE: Apache 2 cycle vs instruction profiling (2.0.40-dev)
> On Tue, 2002-07-02 at 21:09, Bill Stoddard wrote: > > > .ap_rgetline_coreprotocol.c3.32 6 >1.4 3428 > > I'll try the persistent-temp-brigade approach for ap_rgetline_core() > to see how much it helps. > > > .get_filter_handle util_filter.c 4.62 2 >1.1 2730 > Hacked mod_cache. I use this in removing ap_http_header_filter. I've not spent a lot of time on this part of the hack to see if there is a better way. > Is this being called from a custom module? > > > .apr_brigade_putsglink.s 6.88 4 >0.1 165 > > Does this test include your hack to bypass the normal writing of the > response header? (Or is apr_brigade_puts() just in much better shape > now?) This includes my hack to mod_cache to apr_brigade_write() a bunch of pre-built headers. It's performance is still pretty bad, I am just not calling it as often. > > > .apr_table_get apr_tables.c 3.26 17 >1.8 4255 > > Here's some more information on the performance of apr_table_get(): > For typical requests, we do an average of 0.25 strcasecmp() ops > per apr_table_get(). The good news is that the checksum code is > doing its job by eliminating the need for most string comparisons. > The bad news is that we're typically doing N integer checksum > comparisons for an N-element table (i.e., at least 3/4 of all > apr_table_get() calls don't find a match, which means that we > have to scan through the entire table). > > I can think of three ways to potentially speed up apr_table_get() > >1. Keep the basic design the same, but optimize the checksum > computation. We might be able to replace the 4 character > reads from memory with a single integer read from memory > in the common case where the start of the string is > word-aligned. > >2. Add some form of optional indexing to the tables. > >3. Add an "is_sorted" flag to apr_table_t, and do a binary > search in apr_table_get() if the table is sorted. (I > think we can get the request headers sorted for free as > a side effect of the apr_table_overlap() implementation.) > > > .apr_palloc apr_pools.c 2.13 95 >1.5 3641 > > In my last round of profiling, 30+% of the apr_palloc() cycles were > related to brigade creation. Thus the persistent-brigade hack for > ap_rgetline_core() may provide a measurable improvement here. > > --Brian > >
RE: c-l filter and buffering of the entire response
I stand corrected... But there's no reason why the HTTP header cannot be compressed either. This is especially critical when conserving bandwidth in an wireless environment. 1200 byte headers are not uncommon and it a latency laden environment every bit saved enhances the consumers experience. Is Apache ready for HTTP header compression? Peter -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Wednesday, July 03, 2002 6:15 AM To: [EMAIL PROTECTED] Subject: RE: c-l filter and buffering of the entire response > 3. What if servers start supporting compressed headers. RFC 1144 The 'header' as refered to by the rfc 1144 is not the HTTP header but the IP/TCP header. Or in other words Van Jacobson Compression and other ethernet, IP, TCP level compression techniques have fundamentally nothing to do with the socked based TCP stream level on which apache, or any internet protocol -application- functions. Dw
RE: c-l filter and buffering of the entire response
> 3. What if servers start supporting compressed headers. RFC 1144 The 'header' as refered to by the rfc 1144 is not the HTTP header but the IP/TCP header. Or in other words Van Jacobson Compression and other ethernet, IP, TCP level compression techniques have fundamentally nothing to do with the socked based TCP stream level on which apache, or any internet protocol -application- functions. Dw
RE: c-l filter and buffering of the entire response
Couple of thoughts... 1. What if the content is compressed. 2. What about compressed chunked encoding. 3. What if servers start supporting compressed headers. RFC 1144 Regards, Peter -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Jeff Trawick Sent: Wednesday, July 03, 2002 5:55 AM To: [EMAIL PROTECTED] Subject: c-l filter and buffering of the entire response c-l filter thinks that a partial send is not okay if using HTTP 0.9. connection->keepalive is AP_CONN_UNKNOWN. If this were set to AP_CONN_CLOSE, c-l filter would allow a partial send. I dunno what else that would break. Right now Apache is eating lots and lots of storage on a big CGI response on HTTP 0.9 request. The entire response is getting buffered. With HTTP/1.0, the entire response is getting buffered too. Do we absolutely have to get the content length, or can we set connection close and omit the content length field? (Haven't we been through this before?) -- Jeff Trawick | [EMAIL PROTECTED] Born in Roswell... married an alien...
c-l filter and buffering of the entire response
c-l filter thinks that a partial send is not okay if using HTTP 0.9. connection->keepalive is AP_CONN_UNKNOWN. If this were set to AP_CONN_CLOSE, c-l filter would allow a partial send. I dunno what else that would break. Right now Apache is eating lots and lots of storage on a big CGI response on HTTP 0.9 request. The entire response is getting buffered. With HTTP/1.0, the entire response is getting buffered too. Do we absolutely have to get the content length, or can we set connection close and omit the content length field? (Haven't we been through this before?) -- Jeff Trawick | [EMAIL PROTECTED] Born in Roswell... married an alien...
