DO NOT REPLY [Bug 13945] - Missing Transfer-Encoding: chunked header from proxy.

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13945

Missing Transfer-Encoding: chunked header from proxy.





--- Additional Comments From [EMAIL PROTECTED]  2002-10-24 22:13 ---
Some more details.
The missing Transfer-Encoding header is not the real/ only problem here.
(tryed my luck by adding it with mod_headers with no success)

Forcing my browser to 1.0 with the BrowserMatch directive did not help either.
(Sends same reply (should not the 1.0 conversation use content-length?? Don´t 
think chunked is allowed in 1.0 ...)).

The "body" does not contain the chunked headers or trailers length\r\n, which 
leads me to suspect that chunked encoding is not implemented in mod_proxy (if 
it at all should be?) but the content-length headers are taken away for some 
reason.

Same problem in 2.0.42. Reverting back to 2.0.40 where content-length is passed.
The "only" problem there is the "long" wait (only when the complete file is 
buffered at the proxy, does the client get the 200 ok reply with content-length)
for big files.

Should I go back to V1.3 if I want to run a production proxy?

Regards,
Dario.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 13946] New: - reverse proxy errors when a document expires from the cache

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13946

reverse proxy errors when a document expires from the cache

   Summary: reverse proxy errors when a document expires from the
cache
   Product: Apache httpd-2.0
   Version: 2.0.43
  Platform: PC
OS/Version: Linux
Status: NEW
  Severity: Normal
  Priority: Other
 Component: mod_proxy
AssignedTo: bugs@httpd.apache.org
ReportedBy: [EMAIL PROTECTED]


Hi!
Using apache as a reverse proxy with mod_mem_cache, when using simple HTTP/1.0 
requests to files, sometimes (when the object in the cache is expired) the 
proxy does weird requisitions:

The request:
GET /index.html HTTP/1.0
Host: 10.0.0.2

Document cached:
[Fri Oct 25 18:52:07 2002] [debug] mod_cache.c(118): cache: URL /index.html is 
being handled by mem
[Fri Oct 25 18:52:07 2002] [debug] mod_cache.c(232): cache: fresh cache - add 
cache_out filter and handle request
[Fri Oct 25 18:52:07 2002] [debug] mod_cache.c(357): cache: running CACHE_OUT 
filter
[Fri Oct 25 18:52:07 2002] [debug] mod_cache.c(366): cache: serving cached 
version of /index.html

After the document expires:
[Fri Oct 25 18:59:00 2002] [debug] proxy_http.c(109): proxy: HTTP: 
canonicalising URL //10.0.0.2/proxy:http://10.0.0.2/index.html
[Fri Oct 25 18:59:00 2002] [debug] mod_proxy.c(461): Trying to run 
scheme_handler
[Fri Oct 25 18:59:00 2002] [debug] proxy_http.c(1061): proxy: HTTP: serving 
URL http://10.0.0.2/proxy:http://10.0.0.2/index.html
[Fri Oct 25 18:59:00 2002] [debug] proxy_http.c(221): proxy: HTTP connecting 
http://10.0.0.2/proxy:http://10.0.0.2/index.html to 10.0.0.2:80

and after a few mseconds:
[Fri Oct 25 18:59:00 2002] [debug] mod_cache.c(118): cache: URL /index.html is 
being handled by mem
[Fri Oct 25 18:59:00 2002] [debug] mod_cache.c(203): cache: no cache - add 
cache_in filter and DECLINE

Here is a piece of my httpd.conf file:
ProxyRequests Off
ProxyVia Full
ProxyTimeout 30
ProxyReceiveBufferSize 16384
ProxyMaxForwards 10
CacheEnable mem /
CacheDefaultExpire 10
CacheMaxExpire 30
CacheLastModifiedFactor 0.1
CacheMaxStreamingBuffer 65536 
MCacheSize 524288
MCacheMaxObjectCount 32768
MCacheMinObjectSize 1 
MCacheMaxObjectSize 10
MCacheRemovalAlgorithm GDSF
RewriteEngine   on
RewriteRule ^(.*)$ $1 [P,L]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 13945] New: - Missing Transfer-Encoding: chunked header from proxy.

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13945

Missing Transfer-Encoding: chunked header from proxy.

   Summary: Missing Transfer-Encoding: chunked header from proxy.
   Product: Apache httpd-2.0
   Version: 2.0.43
  Platform: PC
   URL: http://www.redbooks.ibm.com
OS/Version: Linux
Status: NEW
  Severity: Critical
  Priority: Other
 Component: mod_proxy
AssignedTo: bugs@httpd.apache.org
ReportedBy: [EMAIL PROTECTED]


Target:  ibm-http-server (apache 1.3.xx) 
Flow:
1- Browser sends request to proxy
2- Proxy passes request for PDF doc to IBM
3- IBM ws starts returning the data to the proxy using content-length headers 
(HTTP/1.1)
4- When the complete document is retrieved to the proxy (this is also a bit 
confusing but never mind) the 200 OK reply from the proxy to the browser is 
returned with the following headers:
HTTP/1.1 200 OK\r\n
Date: (correct date)
Server: IBM_HTTP_SERVER/1.3.19.2 Apache/1.3.20 (Unix)\r\n
Last-Modified: (last modified date)
ETag: "21aca-49."\r\n
Accept-Ranges: bytes\r\n
Content-Type: application/pdf\r\n
Connection: close\r\n
\r\n
data


Now IE either closes the connection and re-tries (user still dont have the 
document) the get, or sends a (reset) On TCP level and retries the get.

My guess is that IE 5 does not understand that it is a chuncked encoding apache 
wants to perform because the Transfer-Encoding: chunked header is missing.

I will send the complete sniffer file in "any" format (ethereal / tcpdump 
snoop ..) on request for further analysis.
Regards,
Dario.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 10144] - Request: Please provide bzip2 tarballs for httpd downloads

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10144

Request: Please provide bzip2 tarballs for httpd downloads

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2002-10-24 18:54 ---
Not a bug

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 10446] - spaces in link to http server seen as foreign characters in 1.3.26

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10446

spaces in link to http server seen as foreign characters in 1.3.26

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 8482] - nph- CGIs and/or server-pushed methodes not working properly

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8482

nph- CGIs and/or server-pushed methodes not working properly





--- Additional Comments From [EMAIL PROTECTED]  2002-10-24 18:10 ---
The nph flavor of teststream.pl works fine for me with this patch.

Wanna try the patch with the more complicated test (irc script)?

Index: server/core.c
===
RCS file: /home/cvs/httpd-2.0/server/core.c,v
retrieving revision 1.213
diff -u -r1.213 core.c
--- server/core.c   14 Oct 2002 20:08:15 -  1.213
+++ server/core.c   24 Oct 2002 17:26:10 -
@@ -3653,6 +3653,7 @@
 conn_rec *c = f->c;
 core_net_rec *net = f->ctx;
 core_output_filter_ctx_t *ctx = net->out_ctx;
+apr_read_type_e eblock = APR_NONBLOCK_READ;

 if (ctx == NULL) {
 ctx = apr_pcalloc(c->pool, sizeof(*ctx));
@@ -3728,7 +3729,16 @@
 const char *str;
 apr_size_t n;

-rv = apr_bucket_read(e, &str, &n, APR_BLOCK_READ);
+rv = apr_bucket_read(e, &str, &n, eblock);
+if (APR_STATUS_IS_EAGAIN(rv)) {
+/* send what we have so far since we shouldn't expect more
+ * output for a while...  next time we read, block
+ */
+more = apr_brigade_split(b, e);
+eblock = APR_BLOCK_READ;
+break;
+}
+eblock = APR_NONBLOCK_READ;
 if (n) {
 if (!fd) {
 if (nvec == MAX_IOVEC_TO_WRITE) {

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 8482] - nph- CGIs and/or server-pushed methodes not working properly

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8482

nph- CGIs and/or server-pushed methodes not working properly





--- Additional Comments From [EMAIL PROTECTED]  2002-10-24 15:43 ---
Thanks for the reminder about calling the script nph-...  Nothing written
to the network in that case, so I'll start debugging that.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 8482] - nph- CGIs and/or server-pushed methodes not working properly

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8482

nph- CGIs and/or server-pushed methodes not working properly





--- Additional Comments From [EMAIL PROTECTED]  2002-10-24 14:38 ---
I've just installed apache 2.0.43 to test with - using mod_cgi and prefork
(default ./configure options). 

teststream works fine -but- if it is called nph-teststream.cgi all but one of
the tests fail (and it's out by much more than a second).

So, the first problem is fixed by renaming it something not beinging with nph-
(I don't understand that - I thought the idea was to do less processing on nph-
scripts). For CGI:IRC renaming nph-irc.cgi to something like irc-main.cgi and
updating config (and removing the 'HTTP/1.0 200 OK' line on non-CVS versions)
fixes it. 

The other problem briefly mentioned above is still present, no signal is sent to
the process to terminate it when the user stops the request, Apache 1.3 does,
although I can't find this in any CGI specification, but it's a very useful 
feature.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 7617] - Apache 1.3.x race condition causes gratuitous 3-second CGI delay

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7617

Apache 1.3.x race condition causes gratuitous 3-second CGI delay





--- Additional Comments From [EMAIL PROTECTED]  2002-10-24 14:14 ---
A few random thoughts...

Does "SetEnv nokeepalive" inside container for CGI directory help?

---/---

Note that mod_cgi already plays a game to avoid the possibility of delay
when the CGI is run as a subrequest.  See the comment, and the pool
passed to ap_bspawn_child():

/*
 * we spawn out of r->main if it's there so that we can avoid
 * waiting for free_proc_chain to cleanup in the middle of an
 * SSI request -djg
 */
if (!ap_bspawn_child(r->main ? r->main->pool : r->pool, cgi_child,
 (void *) &cld, kill_after_timeout,
 &script_out, &script_in, &script_err)) {
ap_log_rerror(APLOG_MARK, APLOG_ERR, r,
"couldn't spawn child process: %s", r->filename);
return HTTP_INTERNAL_SERVER_ERROR;
}

If the pool were r->connection->pool, the cleanup (and possible sleeping)
wouldn't happen until a point where it wouldn't hold up output for the client,
but on the other hand you could have undesired storage growth if many
CGIs were run on the same connection. You'd need to tune MaxKeepAliveRequests
accordingly.

---/---

Another possible kludge:

save the CGI process pid (retcode from ap_bspawn_child()), then after the 
call "ap_send_fb(script_in, r)" to send the output of the CGI, do this:

  if (kill(saved_pid, 0) == 0) { /* child process still alive */
ap_rflush(r);  /* flush any held output to the client before we
* risk waiting for the CGI process to exit
*/
  }

--/--

It might be useful to change free_proc_change() to sleep first for
300ms or so instead of 3 seconds.  But it shouldn't start sending
signals any sooner than the current code does.  It just should be
able to reap status sooner.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 7617] - Apache 1.3.x race condition causes gratuitous 3-second CGI delay

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7617

Apache 1.3.x race condition causes gratuitous 3-second CGI delay





--- Additional Comments From [EMAIL PROTECTED]  2002-10-24 13:36 ---
I agree with Bengdt.  The problem lies more fundamentally with how keep-alives
are being dealt with.  The cost of using keep-alives in this situation can be
quite an annoyance.  I also used a similiar solution, except I only changed the
sleep(3); to sleep(0);.  Those are the ones that cause the problem in my mind,
and I don't have a heavy enough load on my machine to warrant anything else.  My
machine is a a 1GHz, single process machine with 256 MB RAM running RH 7.3.  I
am essentially the only user of the machine besides for occasional application
testing which occurs. 1.3.27 is still producing this bug.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 8482] - nph- CGIs and/or server-pushed methodes not working properly

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8482

nph- CGIs and/or server-pushed methodes not working properly





--- Additional Comments From [EMAIL PROTECTED]  2002-10-24 12:58 ---
weird..

testing with CGI:IRC v0.5

2.0.43:
client receives an exact number of bytes, then nothing for about 10 secs. after 
that, CGI:IRC connects to the IRC-Server and the client completely receives the 
rest. the connection is now closed. (data can be sent to (irc-)server, but 
cannot be received)

2.0.44-dev: (httpd-2.0_20021024101256.tar.gz)
client receives exact number of bytes, too. no waiting. CGI:IRC starts 
immediately. BUT the client doesn't receive the all the data. the amount of 
bytes, received by the client after CGI:IRC has connected to IRC-Server, is 
changing from time to time; after a dozen tests, the data hasn't been fully 
received one single time.
the connection stays alive till termination (by user =)
(same as above: data sending, not receiving...)

maybe david can provide some more details, what's going on that could terminate 
the data-flow.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 8482] - nph- CGIs and/or server-pushed methodes not working properly

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8482

nph- CGIs and/or server-pushed methodes not working properly





--- Additional Comments From [EMAIL PROTECTED]  2002-10-24 12:01 ---
If you were using mod_cgi with 2.0.43, you have all the fixes that are
available.

Here is teststream.pl on cvs HEAD with mod_cgid:

-
Testing streaming of content (with scripting)
If most of the tests below succeed then it is likely streaming of content works
fine. If they fail then either the webserver, a proxy between you and the
webserver or your browser is having problems with streams (and sometimes scripts
embedded inside streams). If the difference in any failed tests is only a second
then it is more likely that your internet connection to the server is slow.

Test 0: OK
Test 1: Failed: 1035460289 != 1035460288
Test 2: Failed: 1035460294 != 1035460293
Test 3: Failed: 1035460299 != 1035460298
Test 4: Failed: 1035460304 != 1035460303
Test 5: Failed: 1035460309 != 1035460308
Less than 4 tests were successful. You probably have a problem with streaming of
content (or a slow internet connection)
End of test.


Note that the failures were all only 1 second too late.

Here is teststream.pl on cvs HEAD with mod_cgi:

--
Testing streaming of content (with scripting)
If most of the tests below succeed then it is likely streaming of content works
fine. If they fail then either the webserver, a proxy between you and the
webserver or your browser is having problems with streams (and sometimes scripts
embedded inside streams). If the difference in any failed tests is only a second
then it is more likely that your internet connection to the server is slow.

Test 0: OK
Test 1: OK
Test 2: OK
Test 3: OK
Test 4: OK
Test 5: OK
6 out of 6 tests were OK, looks like streaming is working
End of test.
-

Should I assume that there is a functional problem with mod_cgid based
on this test, or perhaps it is just a bit slower than mod_cgi?

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 8482] - nph- CGIs and/or server-pushed methodes not working properly

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8482

nph- CGIs and/or server-pushed methodes not working properly





--- Additional Comments From [EMAIL PROTECTED]  2002-10-24 10:23 ---
hi trawick

LoadModule cgi_module libexec/apache2/mod_cgi.so

we're going to update to the latest CVS version this (maybe tomorrow) 
afternoon. keep u informed!

any ideas, when v2.0.43++ will be released?

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 8867] - make install fails for httpd-2.0.36 on Solaris 8

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8867

make install fails for httpd-2.0.36 on Solaris 8

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2002-10-24 10:18 ---
Not applicable anymore.
Have a later version installed.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 13914] - CGI script command line broken

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13914

CGI script command line broken





--- Additional Comments From [EMAIL PROTECTED]  2002-10-24 05:18 ---
Created an attachment (id=3590)
CGI command line argument fix

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 13914] New: - CGI script command line broken

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13914

CGI script command line broken

   Summary: CGI script command line broken
   Product: Apache httpd-2.0
   Version: HEAD
  Platform: All
   URL: http://cgi-spec.golux.com/draft-coar-cgi-v11-03-
clean.html#5.0
OS/Version: All
Status: NEW
  Severity: Normal
  Priority: Other
 Component: mod_cgi
AssignedTo: bugs@httpd.apache.org
ReportedBy: [EMAIL PROTECTED]


CGI script command line is broken in 2.0.40, the query string is *always* passed
to all CGI scripts as the first argument, whether it contains '=' or not.

I took a look and the patch I'm attaching to this report seems obviously correct
to me (it's against CVS HEAD), but I haven't tested it.  Please take a look
ASAP, this prevents running eg. the W3C checklink,
.

For more info, see the CGI spec at
.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 13868] - Exceed Serverlimit directive when REGET are accessing

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13868

Exceed Serverlimit directive when REGET are accessing

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2002-10-24 02:29 ---
Hi,
I found more smart way to fix the big on worker.c.
Following code add on between line 1540-1541.
---
if (free_length > totally_free_length ) {
free_length = totally_free_length;
}
---
We do not need to define 'MAX_SPAWN_RATE (1)' any more.
Default definision is OK!.
New httpd has no more make child proseses than ServerLimit directive.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]