Re: Pre-release test tarballs of httpd 1.3.40, 2.0.62 and 2.2.7 available
On Jan 9, 2008, at 4:42 PM, Jim Jagielski wrote: Just a FYI: Since I have some plans for this evening, the TR of the Holy Trinity :) will occur tomorrow am. Will give it a few more hours and then will TR around 11/12 eastern
Re: Pre-release test tarballs of httpd 1.3.40, 2.0.62 and 2.2.7 available
On Thu, 10 Jan 2008 09:06:49 -0500 Jim Jagielski [EMAIL PROTECTED] wrote: On Jan 9, 2008, at 4:42 PM, Jim Jagielski wrote: Just a FYI: Since I have some plans for this evening, the TR of the Holy Trinity :) will occur tomorrow am. Will give it a few more hours and then will TR around 11/12 eastern Please increment doc version ref before tag http://svn.apache.org/repos/asf/httpd/httpd/branches/2.0.x/docs/manual/style/version.ent http://svn.apache.org/repos/asf/httpd/httpd/branches/2.2.x/docs/manual/style/version.ent
Re: Pre-release test tarballs of httpd 1.3.40, 2.0.62 and 2.2.7 available
-Ursprüngliche Nachricht- Von: Nick Kew Gesendet: Mittwoch, 9. Januar 2008 01:27 An: dev@httpd.apache.org Betreff: Re: Pre-release test tarballs of httpd 1.3.40, 2.0.62 and 2.2.7 available On Mon, 07 Jan 2008 11:29:43 +0100 Ruediger Pluem [EMAIL PROTECTED] wrote: I will also propose the optimizations. If someone has cycles to review then fine, if not then in 2.2.9 :-). At lines 364 and 460 (trunk), you set HTTP_SERVICE_UNAVAILABLE when broken chunking is encountered. I don't think that's right: That's because this was the error code that was used there before for empty chunk size lines, but I agree that this error code might be wrong. - bad chunking in a request should return HTTP_BAD_REQUEST - bad chunking in a proxy response should return HTTP_BAD_GATEWAY Can we know if we're processing request or response at this point? IMHO unfortunately not, but it does not matter in the proxy case anyway, because the error messages sent via bail_out_on_error are sent to the backend server in this case and not the client :-). This is because we have switched the meaning of INPUT and OUTPUT filters for our proxy connection to the backend. The client will receive internal server error just as with your test with the insane sized chunk extension. This is no regression it has worked forever like this. So in the light of this it might make sense to change this simply from HTTP_SERVICE_UNAVAILABLE to HTTP_BAD_REQUEST. WDYT? Also, I committed a simple edge-case fix against empty data buckets getting in the way of detecting a lineend. I presume you're OK with r610240? Thanks. Your patch is much better than my stupid one. Regards Rüdiger
Re: Pre-release test tarballs of httpd 1.3.40, 2.0.62 and 2.2.7 available
On Wed, 9 Jan 2008 11:15:57 +0100 Plüm, Rüdiger, VF-Group [EMAIL PROTECTED] wrote: At lines 364 and 460 (trunk), you set HTTP_SERVICE_UNAVAILABLE when broken chunking is encountered. I don't think that's right: That's because this was the error code that was used there before for empty chunk size lines, but I agree that this error code might be wrong. - bad chunking in a request should return HTTP_BAD_REQUEST - bad chunking in a proxy response should return HTTP_BAD_GATEWAY Can we know if we're processing request or response at this point? IMHO unfortunately not, but it does not matter in the proxy case anyway, because the error messages sent via bail_out_on_error are sent to the backend server in this case and not the client :-). This is because we have switched the meaning of INPUT and OUTPUT filters for our proxy connection to the backend. The client will receive internal server error just as with your test with the insane sized chunk extension. This is no regression it has worked forever like this. So in the light of this it might make sense to change this simply from HTTP_SERVICE_UNAVAILABLE to HTTP_BAD_REQUEST. WDYT? Not so sure here - we're not really returning an error status in any case, and sending errors to the backend falls outside the scope of HTTP. I've just voted +1 on keeping that as-is, in the hope of getting backported in time for Jim's 2.2.8 schedule. Also, I committed a simple edge-case fix against empty data buckets getting in the way of detecting a lineend. I presume you're OK with r610240? Thanks. Your patch is much better than my stupid one. Or in other words a trivial improvement on yours. But I added it to the backport proposal in STATUS. -- Nick Kew Application Development with Apache - the Apache Modules Book http://www.apachetutor.org/
Re: Pre-release test tarballs of httpd 1.3.40, 2.0.62 and 2.2.7 available
On Jan 9, 2008, at 9:42 AM, Nick Kew wrote: Not so sure here - we're not really returning an error status in any case, and sending errors to the backend falls outside the scope of HTTP. I've just voted +1 on keeping that as-is, in the hope of getting backported in time for Jim's 2.2.8 schedule. Reviewing and testing http://people.apache.org/~niq/ chunk_optimization.diff as we speak... I'd also like this in 2.2.8...
Re: Pre-release test tarballs of httpd 1.3.40, 2.0.62 and 2.2.7 available
On Jan 9, 2008, at 9:59 AM, Jim Jagielski wrote:
On Jan 9, 2008, at 9:42 AM, Nick Kew wrote:
Not so sure here - we're not really returning an error status in
any case, and sending errors to the backend falls outside the scope
of HTTP.
I've just voted +1 on keeping that as-is, in the hope of getting
backported in time for Jim's 2.2.8 schedule.
Reviewing and testing http://people.apache.org/~niq/
chunk_optimization.diff
as we speak... I'd also like this in 2.2.8...
In the case where we have nothing but zero-length data buckets
in the brigade, we leveraging that when we leave the
loop, we'll be at a sentinel. Even so, any issues with
the small can't happen check below?
/* We had no data in this brigade */
if (!len || e == APR_BRIGADE_SENTINEL(b)) {
return APR_EAGAIN;
}
Re: Pre-release test tarballs of httpd 1.3.40, 2.0.62 and 2.2.7 available
-Ursprüngliche Nachricht-
Von: Jim Jagielski [mailto:[EMAIL PROTECTED]
Gesendet: Mittwoch, 9. Januar 2008 16:17
An: dev@httpd.apache.org
Betreff: Re: Pre-release test tarballs of httpd 1.3.40,
2.0.62 and 2.2.7 available
On Jan 9, 2008, at 9:59 AM, Jim Jagielski wrote:
On Jan 9, 2008, at 9:42 AM, Nick Kew wrote:
Not so sure here - we're not really returning an error status in
any case, and sending errors to the backend falls outside the scope
of HTTP.
I've just voted +1 on keeping that as-is, in the hope of getting
backported in time for Jim's 2.2.8 schedule.
Reviewing and testing http://people.apache.org/~niq/
chunk_optimization.diff
as we speak... I'd also like this in 2.2.8...
In the case where we have nothing but zero-length data buckets
in the brigade, we leveraging that when we leave the
loop, we'll be at a sentinel. Even so, any issues with
the small can't happen check below?
/* We had no data in this brigade */
if (!len || e == APR_BRIGADE_SENTINEL(b)) {
return APR_EAGAIN;
}
No. Safety first.
Regards
Rüdiger
Re: Pre-release test tarballs of httpd 1.3.40, 2.0.62 and 2.2.7 available
Just a FYI: Since I have some plans for this evening, the TR of the Holy Trinity :) will occur tomorrow am.
Re: Pre-release test tarballs of httpd 1.3.40, 2.0.62 and 2.2.7 available
William A. Rowe, Jr. wrote: START httpd goes into it's goofy mode because it has no interactive behavior, but has no cmd to exit to, and cmd sees it's process is still running. start -k httpd should not exhibit this behavior. If there was a start -hide -k httpd, it wouldn't be offensive. FYI - contrary to Stephan's claims, messages are displayed on the console. As Tom correctly diagnosed, the cmd.exe window's refresh/paint loop is dead. I'm thinking of a scenario where the console *parent only* and on win32 might hold onto the stdin handle. I'll research and reply. I'm becoming more certain that without stdout (we *do* launch with stdin to the console, because it's only deprived from the child) we have changed the behavior of console services. The most suspicious, there is one fewer thread (yup, I'm guessing it's a cmd.exe monitor thread) when run from start.exe rather than on this existing console. It's also possible that our WaitForMultipleObjects in the parent really needs to be MsgWaitForMultipleObjects. Stdin is never closed for the parent; about to experiment with that (it's also closed by prefork and worker MPM's at the point we enter the daemonize() phase). Bill
Re: Pre-release test tarballs of httpd 1.3.40, 2.0.62 and 2.2.7 available
William A. Rowe, Jr. wrote: I'm thinking of a scenario where the console *parent only* and on win32 might hold onto the stdin handle. I'll research and reply. I'm becoming more certain that without stdout (we *do* launch with stdin to the console, because it's only deprived from the child) we have changed the behavior of console services. Boy, I was off-base. *READ* the help start docs before you go blaming httpd ;-) The most suspicious, there is one fewer thread (yup, I'm guessing it's a cmd.exe monitor thread) when run from start.exe rather than on this existing console. It's also possible that our WaitForMultipleObjects in the parent really needs to be MsgWaitForMultipleObjects. BINGO. HTTPD is unwilling to manage the console except when it's doing its very goofy Win9x-service dance. You have two choices; start.exe cmd /c httpd.exe start.exe /b httpd.exe The first command gives you a controllable httpd that can be stopped with ^C / ^BREAK. The second command starts httpd in the current console, gives you back the console (although the display of messages make this confusing) and just like a unix daemon, you _must_ kill it by-pid (and like unix, httpd doesn't do this.) Although closing the console window *does* kill it, ^C / ^BREAK will not. The behavior of start.exe httpd.exe has definitely not been a design consideration, and sure isn't worth holding up Apache 2.2.8. To whatever degree it accidentally worked before, its senseless. Long and short of things; perhaps we should also evaluate closing stdin as the unix daemon does, and figure out the mechanics to httpd -k stop either a service or by logs/httpd.pid, but this is certainly good enough for release 2.2.8 and 2.0.63. Bill
Re: Pre-release test tarballs of httpd 1.3.40, 2.0.62 and 2.2.7 available
On Fri, Jan 04, 2008 at 03:00:46PM -0500, Jim Jagielski wrote: The latest versions of all 3 variants of Apache HTTP Server (1.3.40, 2.0.62 and 2.2.7) have been tagged. 2.2.7 tested and working on BS2000 and FreeBSD-4.x. Martin -- [EMAIL PROTECTED]| Fujitsu Siemens http://www.fujitsu-siemens.com/imprint.html | 81730 Munich, Germany
Re: Pre-release test tarballs of httpd 1.3.40, 2.0.62 and 2.2.7 available
On 01/07/2008 06:38 PM, Justin Erenkrantz wrote: On Jan 7, 2008 2:34 AM, Joe Orton [EMAIL PROTECTED] wrote: I've added a test case to t/modules/proxy.t in perl-framework which exercises the non-blockingness of the chunked encoding parser a little by dripfeeding a chunked response at it, byte by byte, it passes with the trunk and fails with 2.2.x FWIW. Thanks! -- justin Also a thanks from me Joe. FWIW 2.2.x with r609394 and r609538 applied passes the test. Regards Rüdiger
Re: Pre-release test tarballs of httpd 1.3.40, 2.0.62 and 2.2.7 available
On Mon, 07 Jan 2008 11:29:43 +0100 Ruediger Pluem [EMAIL PROTECTED] wrote: Nick could you please test latest trunk (already contains optimizations) and 2.2.x with r609394 and (minimum stuff to fix all aspects of the bug including chunk extensions) backported which should apply cleanly, again? Thanks. OK, I've tested both /trunk/ and 2.2.7+r609394+r609538, and all is well. The issues we've been grappling with are fixed, and no new nasties appeared. n.b. my /trunk/ *may* differ from svn.apache.org at any time! -- Nick Kew Application Development with Apache - the Apache Modules Book http://www.apachetutor.org/
Re: Pre-release test tarballs of httpd 1.3.40, 2.0.62 and 2.2.7 available
On Mon, 07 Jan 2008 11:29:43 +0100 Ruediger Pluem [EMAIL PROTECTED] wrote: Once the tests are positive I will propose r609394 and r609538 for backport such that TR of 2.2.x and all other branches can start soon. It works, but a couple of niggles reviewing those. Taking line numbers on a diff applying those to 2.2.7 (the configuration I tested): Line 80: if (len 0). It's better future-proof if len is declared (signed) int, so that test fails if something happens to screw up computing len. Lines 47-55: what about a brigade with no data bucket, or with a zero-length last data bucket? If you've addressed those in the later revisions, then +1 to this proposal. It passes the real-life practical test. -- Nick Kew Application Development with Apache - the Apache Modules Book http://www.apachetutor.org/
Re: Pre-release test tarballs of httpd 1.3.40, 2.0.62 and 2.2.7 available
On 01/08/2008 03:30 PM, Nick Kew wrote: On Mon, 07 Jan 2008 11:29:43 +0100 Ruediger Pluem [EMAIL PROTECTED] wrote: Once the tests are positive I will propose r609394 and r609538 for backport such that TR of 2.2.x and all other branches can start soon. It works, but a couple of niggles reviewing those. Taking line numbers on a diff applying those to 2.2.7 (the configuration I tested): Line 80: if (len 0). It's better future-proof if len is declared (signed) int, so that test fails if something happens to screw up computing len. It is apr_size_t, because this whats apr_brigade_flatten needs. What is your worry? That the computation above can fail and cause the result to be negative? Lines 47-55: what about a brigade with no data bucket, or with a zero-length last data bucket? Good point. I will address this. If you've addressed those in the later revisions, then +1 to this proposal. It passes the real-life practical test. No they are not. I am sorry. Regards Rüdiger
proxy-SSL-woes in 2.2.7 [was:Re: Pre-release test tarballs of httpd 1.3.40, 2.0.62 and 2.2.7 available]
Okay, I found a new bug in the 2.2.7 proxy while testing SSL and non-SSL CONNECTions both with and without a ProxyRemote directive. verbose To recap, totally different things happen in the presence or absence of a ProxyRemote: * with ProxyRemote, the web server acts as a forwarder, and connects to an upstream proxy in a proxy chain (speaking the HTTP protocol to it), while * without ProxyRemote, the web server connects directly to the origin server, speaking the native protocol to it (i.e., speaking FTP when executing a ftp://originserver/ proxy URL, or simply tunnelling the net data when doing http:// or ssl CONNECT proxy requests) /verbose In the test matrix, the forwarder situation was working allright. The direct connection, however, breaks in SSL mode, and the connection is closed by the 2.2.7 proxy too early (before receiving the 1st response to the SSL CLIENT-HELLO). The chunk_filter patch seems to improve the situation: the connection sometimes succeeds. But in most cases, I get (with a slightly patched openssl s_client that can use a HTTP proxy): --snip-- % openssl s_client -connect originserver:443 -proxy apacheproxy227:8227 -verify 0 -msg verify depth is 0 HTTP/1.0 200 Connection Established CONNECTED(0005) SSL 2.0 [length 00c5], CLIENT-HELLO 01 03 01 00 9c 00 00 00 20 00 c0 14 00 c0 0a 00 00 39 00 00 38 00 00 88 00 00 87 00 c0 0f 00 c0 05 00 00 35 00 00 84 00 c0 12 00 c0 08 00 00 16 00 00 13 00 c0 0d 00 c0 03 00 00 0a 07 00 c0 00 c0 13 00 c0 09 00 00 33 00 00 32 00 00 9a 00 00 99 00 00 45 00 00 44 00 c0 0e 00 c0 04 00 00 2f 00 00 96 00 00 41 00 00 07 05 00 80 03 00 80 00 c0 11 00 c0 07 00 c0 0c 00 c0 02 00 00 05 00 00 04 01 00 80 00 00 15 00 00 12 00 00 09 06 00 40 00 00 14 00 00 11 00 00 08 00 00 06 04 00 80 00 00 03 02 00 80 b8 a2 32 64 e5 0b 51 ae ec a1 2f f0 f9 6e b1 8f ab af 9c 97 c2 de a1 d4 f3 34 1d a9 c3 9c ef 10 38921:error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol:s23_clnt.c:631: --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 7 bytes and written 199 bytes --- New, (NONE), Cipher is (NONE) Compression: NONE Expansion: NONE --- --snip-- so the connection is closed before the response has arrived. On the server side, the proxy_connect (with DEBUGGING) logs: --snip-- [Tue Jan 08 15:00:44 2008] [debug] mod_proxy_connect.c(145): proxy: CONNECT: connecting to remote host originserver [Tue Jan 08 15:00:44 2008] [debug] proxy_util.c(1525): proxy: CONNECT: fam 2 socket created to connect to originserver [Tue Jan 08 15:00:44 2008] [debug] mod_proxy_connect.c(241): proxy: CONNECT: Returning 200 OK Status [Tue Jan 08 15:00:44 2008] [debug] mod_proxy_connect.c(262): proxy: CONNECT: setting up poll() [Tue Jan 08 15:00:44 2008] [debug] mod_proxy_connect.c(299): proxy: CONNECT: woke from select(), i=1 [Tue Jan 08 15:00:44 2008] [debug] mod_proxy_connect.c(344): proxy: CONNECT: client was set [Tue Jan 08 15:00:44 2008] [debug] mod_proxy_connect.c(353): proxy: CONNECT: read 199 from client [Tue Jan 08 15:00:44 2008] [debug] mod_proxy_connect.c(299): proxy: CONNECT: woke from select(), i=1 [Tue Jan 08 15:00:44 2008] [debug] mod_proxy_connect.c(344): proxy: CONNECT: client was set [Tue Jan 08 15:00:44 2008] [debug] mod_proxy_connect.c(371): proxy: CONNECT: client: apr_socket_recv() = rv=70014 = End of file found [Tue Jan 08 15:00:44 2008] [debug] mod_proxy_connect.c(404): proxy: CONNECT: finished with poll() - cleaning up --snip-- so it gets an EOF when there should be more data available. On Sun, Jan 06, 2008 at 07:47:03PM +0100, Ruediger Pluem wrote: Ok, next one. I missed to set the correct state in some situations. Can you please give it a try again? As I said, without this patch, the connection apparently never succeeds. With the patch, *sometimes* it succeeds: --snip-- HTTP/1.0 200 Connection Established Proxy-agent: Apache/2.2.8-dev (Unix) mod_ssl/2.2.8-dev OpenSSL/0.9.7d-p1 DAV/2 CONNECTED(0005) SSL 2.0 [length 00c5], CLIENT-HELLO 01 03 01 00 9c 00 00 00 20 00 c0 14 00 c0 0a 00 ... 7c ef c1 73 83 TLS 1.0 Handshake [length 004a], ServerHello 02 00 00 46 03 01 47 83 b4 82 03 e4 d2 49 95 34 ... 0b 57 ce 53 cb c4 4f 00 16 00 TLS 1.0 Handshake [length 0335], Certificate 0b 00 03 31 00 03 2e 00 03 2b 30 82 03 27 30 82 ... 80 d2 18 87 92 ... SSL handshake has read 1367 bytes and written 389 bytes --- New, TLSv1/SSLv3, Cipher is EDH-RSA-DES-CBC3-SHA Server public key is 1024 bit Compression: NONE Expansion: NONE SSL-Session: Protocol : TLSv1 Cipher: EDH-RSA-DES-CBC3-SHA Session-ID: 6E931441168A6742E4155B0ED687B8CAA9CC3BC20E18B802A00B57CE53CBC44F Session-ID-ctx: Master-Key: 98FE7321DCEE24063FE2B9B57DA8D534656FD85621E41F0985DEA84CCB9C68BD24BDB412DE7F701E4DA0E516E56FF326 Key-Arg : None PSK identity: None PSK identity hint: None
Re: Pre-release test tarballs of httpd 1.3.40, 2.0.62 and 2.2.7 available
William A. Rowe, Jr. wrote: Tom Donovan wrote: Steffen wrote: William A. Rowe, Jr. wrote: Tom Donovan's confirmed the state of mpm_winnt as again working with mod perl across service, console, and -X modes (and some other slightly more obscure models). I'll backport the correction to 2.0.63 and 2.2.8 and put this whole issue to bed. Now committed. Indeed mod_perl is working in the mentioned cases, But, in console, it breaks the control over the Dos-box. It is cleared and had to kill httpd.exe's manually when I want to stop Apache. Arrrgh! I can't believe I missed that! You're right Steffen. ... With the current code, closing the child window doesn't stop Apache, it just removes the window. With the previous patch this wasn't a problem - Apache shut down OK. I don't really know why, but I'll try to find out. I am going to hazard a guess. As of pre_config hook, we no longer have a single handle to the console window; the have all been entirely detached (stdin/stdout/stderr). In effect, I think win32 is treating this as being daemonized and will no longer pass console events to the child. This should not be true for -X mode, perhaps it is also? One source of confusion here may be the various ways to start Apache via the command-line. When r609366 (comment #9 in bug 43534) is applied to 2.2.7: If Apache is started with the command: httpd.exe the problem isn't apparent. If Apache is started with the command: START httpd.exe this creates an Apache window with odd behavior: * The window does not display all the parent's messages * Closing the window does not stop Apache * The window is not re-drawn when it is covered and uncovered (i.e. it has no event loop). With an earlier patch from comment #6 in bug 43534, mod_perl and the Apache window seem fine in all startup cases I can think to try - but there is a concern about exactly when stdout gets directed to the null device. I don't quite follow this concern - but I'm sure there is a history somewhere. Is there a bug, post, or test case which shows the problem with delaying this redirection of stdout on Windows? I can't seem to find the history of this concern searching Bugzilla (back to change r88358 in Feb, 2001) or the apache-dev archives. thx, -tom-
Re: Pre-release test tarballs of httpd 1.3.40, 2.0.62 and 2.2.7 available
Tom Donovan wrote: With an earlier patch from comment #6 in bug 43534, mod_perl and the Apache window seem fine in all startup cases I can think to try - but there is a concern about exactly when stdout gets directed to the null device. I don't quite follow this concern - but I'm sure there is a history somewhere. Is there a bug, post, or test case which shows the problem with delaying this redirection of stdout on Windows? I can't seem to find the history of this concern searching Bugzilla (back to change r88358 in Feb, 2001) or the apache-dev archives. Nope, it was a design decision early on by the original authors. The goal was always to present configuration errors on the first-pass to the end user at the console, and then daemonize. Ryan and Jeff in particular noted that many fds 'leaked' into any extra spawned processes, such as cgid etc, if the console was still open. It would not successfully daemonize (completely). So this was moved from the post config phase to the pre config phase. Some errors are still reported, but many cannot be. It's a bad design but something that perhaps should be addressed in 2.4 across all platforms, where there's lots of attention during the alpha/beta. Now to Win32, again it's a design consideration; early tests had all sorts of traumatic failures when we couldn't even use file stdout, stdin or stderr and httpd expects those to exist. Service processes have all NULL handles in these cases. So open-early became the strategy and I refactored those into the actual pre-argv[] processing phase. Back to consoles; you'll see there were many stages of evolution if you review the svn history. Tweaks and new components for 9x, for NT, and so forth. Never entirely rationalized because httpd is a daemon, on win32 a daemon is a service, ergo httpd should not be run in a console since it would 'go away' upon logout. Only a dev who fronts a localized webapp for the logged in user would ever want to treat it as such. Of course it's a fun mode for local development and testing. Your patch worked in conjunction with that iteration of httpd for one of a couple of possible reasons. Perhaps the console handles were not effectively closed, and some duplicate hung around. Perhaps one of the handles like stdin hung around, which was changed in behavior between 2.2.4 and 2.2.7. I'm not entirely certain, but I am sure that the handles of the daemonized process are now properly closed; and this leads to the console really paying no attention at all. START httpd goes into it's goofy mode because it has no interactive behavior, but has no cmd to exit to, and cmd sees it's process is still running. start -k httpd should not exhibit this behavior. If there was a start -hide -k httpd, it wouldn't be offensive. I'm thinking of a scenario where the console *parent only* and on win32 might hold onto the stdin handle. I'll research and reply. Bill
Re: proxy-SSL-woes in 2.2.7 [was:Re: Pre-release test tarballs of httpd 1.3.40, 2.0.62 and 2.2.7 available]
On 01/08/2008 06:41 PM, Martin Kraemer wrote: Okay, I found a new bug in the 2.2.7 proxy while testing SSL and non-SSL CONNECTions both with and without a ProxyRemote directive. verbose To recap, totally different things happen in the presence or absence of a ProxyRemote: * with ProxyRemote, the web server acts as a forwarder, and connects to an upstream proxy in a proxy chain (speaking the HTTP protocol to it), while * without ProxyRemote, the web server connects directly to the origin server, speaking the native protocol to it (i.e., speaking FTP when executing a ftp://originserver/ proxy URL, or simply tunnelling the net data when doing http:// or ssl CONNECT proxy requests) /verbose In the test matrix, the forwarder situation was working allright. The direct connection, however, breaks in SSL mode, and the connection is closed by the 2.2.7 proxy too early (before receiving the 1st response to the SSL CLIENT-HELLO). The chunk_filter patch seems to improve the situation: the connection sometimes succeeds. But in most cases, I get (with a slightly patched openssl s_client that can use a HTTP proxy): --snip-- % openssl s_client -connect originserver:443 -proxy apacheproxy227:8227 -verify 0 -msg verify depth is 0 HTTP/1.0 200 Connection Established CONNECTED(0005) SSL 2.0 [length 00c5], CLIENT-HELLO 01 03 01 00 9c 00 00 00 20 00 c0 14 00 c0 0a 00 00 39 00 00 38 00 00 88 00 00 87 00 c0 0f 00 c0 05 00 00 35 00 00 84 00 c0 12 00 c0 08 00 00 16 00 00 13 00 c0 0d 00 c0 03 00 00 0a 07 00 c0 00 c0 13 00 c0 09 00 00 33 00 00 32 00 00 9a 00 00 99 00 00 45 00 00 44 00 c0 0e 00 c0 04 00 00 2f 00 00 96 00 00 41 00 00 07 05 00 80 03 00 80 00 c0 11 00 c0 07 00 c0 0c 00 c0 02 00 00 05 00 00 04 01 00 80 00 00 15 00 00 12 00 00 09 06 00 40 00 00 14 00 00 11 00 00 08 00 00 06 04 00 80 00 00 03 02 00 80 b8 a2 32 64 e5 0b 51 ae ec a1 2f f0 f9 6e b1 8f ab af 9c 97 c2 de a1 d4 f3 34 1d a9 c3 9c ef 10 38921:error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol:s23_clnt.c:631: --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 7 bytes and written 199 bytes --- New, (NONE), Cipher is (NONE) Compression: NONE Expansion: NONE --- --snip-- so the connection is closed before the response has arrived. On the server side, the proxy_connect (with DEBUGGING) logs: --snip-- [Tue Jan 08 15:00:44 2008] [debug] mod_proxy_connect.c(145): proxy: CONNECT: connecting to remote host originserver [Tue Jan 08 15:00:44 2008] [debug] proxy_util.c(1525): proxy: CONNECT: fam 2 socket created to connect to originserver [Tue Jan 08 15:00:44 2008] [debug] mod_proxy_connect.c(241): proxy: CONNECT: Returning 200 OK Status [Tue Jan 08 15:00:44 2008] [debug] mod_proxy_connect.c(262): proxy: CONNECT: setting up poll() [Tue Jan 08 15:00:44 2008] [debug] mod_proxy_connect.c(299): proxy: CONNECT: woke from select(), i=1 [Tue Jan 08 15:00:44 2008] [debug] mod_proxy_connect.c(344): proxy: CONNECT: client was set [Tue Jan 08 15:00:44 2008] [debug] mod_proxy_connect.c(353): proxy: CONNECT: read 199 from client [Tue Jan 08 15:00:44 2008] [debug] mod_proxy_connect.c(299): proxy: CONNECT: woke from select(), i=1 [Tue Jan 08 15:00:44 2008] [debug] mod_proxy_connect.c(344): proxy: CONNECT: client was set [Tue Jan 08 15:00:44 2008] [debug] mod_proxy_connect.c(371): proxy: CONNECT: client: apr_socket_recv() = rv=70014 = End of file found [Tue Jan 08 15:00:44 2008] [debug] mod_proxy_connect.c(404): proxy: CONNECT: finished with poll() - cleaning up --snip-- so it gets an EOF when there should be more data available. On Sun, Jan 06, 2008 at 07:47:03PM +0100, Ruediger Pluem wrote: Ok, next one. I missed to set the correct state in some situations. Can you please give it a try again? As I said, without this patch, the connection apparently never succeeds. With the patch, *sometimes* it succeeds: Very, very strange because in the SSL proxy forward case you 1. use mod_proxy_connect which wasn't touched in 2.2.x for the last 11 month, so I doubt that this is a regression- 2. The HTTP_IN filter does not do anything in the SSL proxy forward case (it is not in the filter chain) as in contrast to non SSL proxying mod_proxy_connect does not care about the contents of the backend at all and is a pure data pump on TCP level. Or are you talking about reverse proxying a SSL backend? Regards Rüdiger
Re: proxy-SSL-woes in 2.2.7 [was:Re: Pre-release test tarballs of httpd 1.3.40, 2.0.62 and 2.2.7 available]
On Tue, Jan 08, 2008 at 08:37:10PM +0100, Ruediger Pluem wrote: Very, very strange because in the SSL proxy forward case you 1. use mod_proxy_connect which wasn't touched in 2.2.x for the last 11 month, so I doubt that this is a regression- I must confess that I have always tested the proxy as a forwarder, and only found the bug now. It may have been lingering there for a long time already. 2. The HTTP_IN filter does not do anything in the SSL proxy forward case (it is not in the filter chain) as in contrast to non SSL proxying mod_proxy_connect does not care about the contents of the backend at all and is a pure data pump on TCP level. Then perhaps the patch really did not change it at all, and I only happened to get a few successful connections after having tried the patch (and would have gotten them without it, too, had I tried hard enough :-) Or are you talking about reverse proxying a SSL backend? Nope, this is the forward proxy situation. SSL-Browser --CONNECT-- httpd-2.2.7-proxy -- origin server Martin -- [EMAIL PROTECTED]| Fujitsu Siemens http://www.fujitsu-siemens.com/imprint.html | 81730 Munich, Germany
Re: Pre-release test tarballs of httpd 1.3.40, 2.0.62 and 2.2.7 available
On Mon, 07 Jan 2008 11:29:43 +0100 Ruediger Pluem [EMAIL PROTECTED] wrote: I will also propose the optimizations. If someone has cycles to review then fine, if not then in 2.2.9 :-). At lines 364 and 460 (trunk), you set HTTP_SERVICE_UNAVAILABLE when broken chunking is encountered. I don't think that's right: - bad chunking in a request should return HTTP_BAD_REQUEST - bad chunking in a proxy response should return HTTP_BAD_GATEWAY Can we know if we're processing request or response at this point? Also, I committed a simple edge-case fix against empty data buckets getting in the way of detecting a lineend. I presume you're OK with r610240? -- Nick Kew Application Development with Apache - the Apache Modules Book http://www.apachetutor.org/
Re: Pre-release test tarballs of httpd 1.3.40, 2.0.62 and 2.2.7 available
On 01/06/2008 07:47 PM, Ruediger Pluem wrote: On 01/06/2008 11:39 AM, Ruediger Pluem wrote: On 01/06/2008 02:20 AM, Nick Kew wrote: On Sat, 05 Jan 2008 20:28:33 +0100 Ruediger Pluem [EMAIL PROTECTED] wrote: On 01/05/2008 07:04 PM, Nick Kew wrote: On Sat, 05 Jan 2008 12:38:58 +0100 Ruediger Pluem [EMAIL PROTECTED] wrote: Ok. Can you setup a tcpdump between proxy and server and between client and proxy? I guess the network traces would be very helpful in finding out where things are starting to get wrong. One testcase with its tcpdump at http://people.apache.org/~niq/2.2.7/ Thanks for this, but I think this is not sufficient: 1. It seems the dump is incomplete as I cannot see a 0 chunk at the end. 2. I would prefer the binary dump as it offers more possibilities to analyse it with wireshark. Sorry for being that demanding :-) Do you mean as in tcpdump -x? I've uploaded a pair of dumps (one of client-proxy, the other of proxy-server) at the same location. Ok, next one. I missed to set the correct state in some situations. Can you please give it a try again? Ok, hopefully final one. Though I still have some optimizations in the pipe they do not relate directly to the bug. Nick could you please test latest trunk (already contains optimizations) and 2.2.x with r609394 and r609538 (minimum stuff to fix all aspects of the bug including chunk extensions) backported which should apply cleanly, again? Thanks. Once the tests are positive I will propose r609394 and r609538 for backport such that TR of 2.2.x and all other branches can start soon. I will also propose the optimizations. If someone has cycles to review then fine, if not then in 2.2.9 :-). Regards Rüdiger
Re: Pre-release test tarballs of httpd 1.3.40, 2.0.62 and 2.2.7 available
On Mon, Jan 07, 2008 at 11:29:43AM +0100, Ruediger Pluem wrote: Ok, hopefully final one. Though I still have some optimizations in the pipe they do not relate directly to the bug. Nick could you please test latest trunk (already contains optimizations) and 2.2.x with r609394 and r609538 (minimum stuff to fix all aspects of the bug including chunk extensions) backported which should apply cleanly, again? Thanks. Once the tests are positive I will propose r609394 and r609538 for backport such that TR of 2.2.x and all other branches can start soon. I will also propose the optimizations. If someone has cycles to review then fine, if not then in 2.2.9 :-). I've added a test case to t/modules/proxy.t in perl-framework which exercises the non-blockingness of the chunked encoding parser a little by dripfeeding a chunked response at it, byte by byte, it passes with the trunk and fails with 2.2.x FWIW. joe
Re: Pre-release test tarballs of httpd 1.3.40, 2.0.62 and 2.2.7 available
From what I can tell, all 3 versions should be not-released and we should instead move ahead with 1.3.41, 2.0.63 and 2.2.8 to address the current concerns... 1.3.41 looks releasable with the current state of HEAD. 2.0.63 requires one more vote for the ssl lib stuff 2.2.8 requires more testing/review of the drip-feed, chunked patches, as well as an update by Rüdiger concerning his optimization status.
Re: Pre-release test tarballs of httpd 1.3.40, 2.0.62 and 2.2.7 available
On Jan 7, 2008 3:03 PM, Jim Jagielski [EMAIL PROTECTED] wrote: From what I can tell, all 3 versions should be not-released and we should instead move ahead with 1.3.41, 2.0.63 and 2.2.8 to address the current concerns... 1.3.41 looks releasable with the current state of HEAD. 2.0.63 requires one more vote for the ssl lib stuff 2.2.8 requires more testing/review of the drip-feed, chunked patches, as well as an update by Rüdiger concerning his optimization status. +1 on not-releasing and moving on to 1.3.41, 2.0.63 and 2.2.8 but only if its in within a short time span. -- ~Jorge
Re: Pre-release test tarballs of httpd 1.3.40, 2.0.62 and 2.2.7 available
On Jan 7, 2008, at 9:12 AM, Jorge Schrauwen wrote: On Jan 7, 2008 3:03 PM, Jim Jagielski [EMAIL PROTECTED] wrote: From what I can tell, all 3 versions should be not-released and we should instead move ahead with 1.3.41, 2.0.63 and 2.2.8 to address the current concerns... 1.3.41 looks releasable with the current state of HEAD. 2.0.63 requires one more vote for the ssl lib stuff 2.2.8 requires more testing/review of the drip-feed, chunked patches, as well as an update by Rüdiger concerning his optimization status. +1 on not-releasing and moving on to 1.3.41, 2.0.63 and 2.2.8 but only if its in within a short time span. I'm expecting this week... The main question is having more eyes look at the chunked patch, both the stripped down version which solves the bug as well as any potential optimizations.
Re: Pre-release test tarballs of httpd 1.3.40, 2.0.62 and 2.2.7 available
On 01/07/2008 03:03 PM, Jim Jagielski wrote: From what I can tell, all 3 versions should be not-released and we should instead move ahead with 1.3.41, 2.0.63 and 2.2.8 to address the current concerns... 1.3.41 looks releasable with the current state of HEAD. 2.0.63 requires one more vote for the ssl lib stuff Added missing vote. 2.2.8 requires more testing/review of the drip-feed, chunked patches, as well as an update by Rüdiger concerning his optimization status. Added proposals. Bug fixes proposal is ready to vote, optimizations proposal will be updated with a conflict free patch once the bug fix is committed. All optimizations are committed to trunk and I finished my optimizations. Regards Rüdiger
Re: Pre-release test tarballs of httpd 1.3.40, 2.0.62 and 2.2.7 available
On 01/07/2008 03:55 PM, Ruediger Pluem wrote: On 01/07/2008 03:03 PM, Jim Jagielski wrote: From what I can tell, all 3 versions should be not-released and we should instead move ahead with 1.3.41, 2.0.63 and 2.2.8 to address the current concerns... 1.3.41 looks releasable with the current state of HEAD. 2.0.63 requires one more vote for the ssl lib stuff Added missing vote. Committed in r609625. Regards Rüdiger
Re: Test suite on Darwin was Re: Pre-release test tarballs of httpd 1.3.40, 2.0.62 and 2.2.7 available
On Jan 6, 2008 11:41 PM, Sander Temme [EMAIL PROTECTED] wrote: I actually built my own perl 5.10.0, put its bin in front of my PATH and installed all the requisite modules. I did this mainly because I don't want to mess with the system installation, but prefer to hose one I can easily replace. (: That's what I thought. Perl 5.10.0 Crypt::SSLeay 0.57 LWP 5.808 MIME::Base64 3.07_01 Digest::MD5 2.36_01 I'm kind of concerned if we diverge on Intel vs. PowerPC... -- justin Your failure pattern actually smacks of broken Crypt::SSLeay, Digest::MD5 or even MIME::Base64 fu: try forcing those modules to (re)install. For the 2.2.8 go-'round, I'll try again. But, at least I'll have 'known good versions' this time. Thanks. -- justin
Re: Pre-release test tarballs of httpd 1.3.40, 2.0.62 and 2.2.7 available
On Jan 7, 2008 2:34 AM, Joe Orton [EMAIL PROTECTED] wrote: I've added a test case to t/modules/proxy.t in perl-framework which exercises the non-blockingness of the chunked encoding parser a little by dripfeeding a chunked response at it, byte by byte, it passes with the trunk and fails with 2.2.x FWIW. Thanks! -- justin
Re: Pre-release test tarballs of httpd 1.3.40, 2.0.62 and 2.2.7 available
William A. Rowe, Jr. wrote: Jim Jagielski wrote: From what I can tell, all 3 versions should be not-released and we should instead move ahead with 1.3.41, 2.0.63 and 2.2.8 to address the current concerns... 1.3.41 looks releasable with the current state of HEAD. 2.0.63 requires one more vote for the ssl lib stuff 2.2.8 requires more testing/review of the drip-feed, chunked patches, as well as an update by Rüdiger concerning his optimization status. Tom Donovan's confirmed the state of mpm_winnt as again working with mod perl across service, console, and -X modes (and some other slightly more obscure models). I'll backport the correction to 2.0.63 and 2.2.8 and put this whole issue to bed. Now committed. Agreed with the above; once chunking of proxy works as expected, handles invalid data properly, does not generate invalid responses, I'll be happy to see 2.2.8 put to rest as well.
Re: Pre-release test tarballs of httpd 1.3.40, 2.0.62 and 2.2.7 available
- Original Message - From: William A. Rowe, Jr. [EMAIL PROTECTED] To: dev@httpd.apache.org Sent: Monday, 07 January, 2008 19:52 Subject: Re: Pre-release test tarballs of httpd 1.3.40, 2.0.62 and 2.2.7 available William A. Rowe, Jr. wrote: Jim Jagielski wrote: From what I can tell, all 3 versions should be not-released and we should instead move ahead with 1.3.41, 2.0.63 and 2.2.8 to address the current concerns... 1.3.41 looks releasable with the current state of HEAD. 2.0.63 requires one more vote for the ssl lib stuff 2.2.8 requires more testing/review of the drip-feed, chunked patches, as well as an update by Rüdiger concerning his optimization status. Tom Donovan's confirmed the state of mpm_winnt as again working with mod perl across service, console, and -X modes (and some other slightly more obscure models). I'll backport the correction to 2.0.63 and 2.2.8 and put this whole issue to bed. Now committed. Agreed with the above; once chunking of proxy works as expected, handles invalid data properly, does not generate invalid responses, I'll be happy to see 2.2.8 put to rest as well. Indeed mod_perl is working in the mentioned cases, But, in console, it breaks the control over the Dos-box. It is cleared and had to kill httpd.exe's manually when I want to stop Apache. Steffen
Re: Pre-release test tarballs of httpd 1.3.40, 2.0.62 and 2.2.7 available
Steffen wrote:
- Original Message - From: William A. Rowe, Jr.
[EMAIL PROTECTED]
To: dev@httpd.apache.org
Sent: Monday, 07 January, 2008 19:52
Subject: Re: Pre-release test tarballs of httpd 1.3.40, 2.0.62 and 2.2.7
available
William A. Rowe, Jr. wrote:
Tom Donovan's confirmed the state of mpm_winnt as again working
with mod perl across service, console, and -X modes (and some
other slightly more obscure models).
I'll backport the correction to 2.0.63 and 2.2.8 and put this
whole issue to bed.
Now committed.
Indeed mod_perl is working in the mentioned cases,
But, in console, it breaks the control over the Dos-box. It is cleared and
had to kill httpd.exe's manually when I want to stop Apache.
Steffen
Arrrgh! I can't believe I missed that! You're right Steffen.
FWIW - I'm in the habit of shutting Apache down by running a program which sets the
ap{pid}_shutdown event, and I didn't even think to try clicking the [X] in the upper-right corner
of the Apache window.
With the current code, closing the child window doesn't stop Apache, it just removes the window.
With the previous patch this wasn't a problem - Apache shut down OK. I don't really know why, but
I'll try to find out.
-tom-
Re: Pre-release test tarballs of httpd 1.3.40, 2.0.62 and 2.2.7 available
- Original Message -
From: Tom Donovan [EMAIL PROTECTED]
To: dev@httpd.apache.org
Sent: Monday, 07 January, 2008 20:38
Subject: Re: Pre-release test tarballs of httpd 1.3.40, 2.0.62 and 2.2.7
available
Steffen wrote:
- Original Message - From: William A. Rowe, Jr.
[EMAIL PROTECTED]
To: dev@httpd.apache.org
Sent: Monday, 07 January, 2008 19:52
Subject: Re: Pre-release test tarballs of httpd 1.3.40, 2.0.62 and 2.2.7
available
William A. Rowe, Jr. wrote:
Tom Donovan's confirmed the state of mpm_winnt as again working
with mod perl across service, console, and -X modes (and some
other slightly more obscure models).
I'll backport the correction to 2.0.63 and 2.2.8 and put this
whole issue to bed.
Now committed.
Indeed mod_perl is working in the mentioned cases,
But, in console, it breaks the control over the Dos-box. It is cleared
and
had to kill httpd.exe's manually when I want to stop Apache.
Steffen
Arrrgh! I can't believe I missed that! You're right Steffen.
FWIW - I'm in the habit of shutting Apache down by running a program which
sets the ap{pid}_shutdown event, and I didn't even think to try clicking
the [X] in the upper-right corner of the Apache window.
With the current code, closing the child window doesn't stop Apache, it
just removes the window. With the previous patch this wasn't a problem -
Apache shut down OK. I don't really know why, but I'll try to find out.
-tom-
Also with this patch it is not outputting to the Dos-box.
Tom, it does not happens with your patch which included in 2.2.7 download at
the Apache Lounge. Only the latest patch from Bill has the issue.
Steffen
Re: Pre-release test tarballs of httpd 1.3.40, 2.0.62 and 2.2.7 available
Tom Donovan wrote:
Steffen wrote:
- Original Message - From: William A. Rowe, Jr.
[EMAIL PROTECTED]
To: dev@httpd.apache.org
Sent: Monday, 07 January, 2008 19:52
Subject: Re: Pre-release test tarballs of httpd 1.3.40, 2.0.62 and 2.2.7
available
William A. Rowe, Jr. wrote:
Tom Donovan's confirmed the state of mpm_winnt as again working
with mod perl across service, console, and -X modes (and some
other slightly more obscure models).
I'll backport the correction to 2.0.63 and 2.2.8 and put this
whole issue to bed.
Now committed.
Indeed mod_perl is working in the mentioned cases,
But, in console, it breaks the control over the Dos-box. It is cleared
and
had to kill httpd.exe's manually when I want to stop Apache.
Steffen
Arrrgh! I can't believe I missed that! You're right Steffen.
FWIW - I'm in the habit of shutting Apache down by running a program
which sets the ap{pid}_shutdown event, and I didn't even think to try
clicking the [X] in the upper-right corner of the Apache window.
With the current code, closing the child window doesn't stop Apache, it
just removes the window. With the previous patch this wasn't a problem -
Apache shut down OK. I don't really know why, but I'll try to find out.
I am going to hazard a guess. As of pre_config hook, we no longer have
a single handle to the console window; the have all been entirely
detached (stdin/stdout/stderr). In effect, I think win32 is treating
this as being daemonized and will no longer pass console events to the
child.
This should not be true for -X mode, perhaps it is also?
The real answer may just be handling -k stop for a pid in a process,
but that gets just a little tricky with respect to console vs service.
Bill
Re: Pre-release test tarballs of httpd 1.3.40, 2.0.62 and 2.2.7 available
Steffen wrote: Also with this patch it is not outputting to the Dos-box. Tom, it does not happens with your patch which included in 2.2.7 download at the Apache Lounge. Only the latest patch from Bill has the issue. Of course not, Tom's proposed patch and the final patch adopted both stopped all such output to fix perl, as you had asked for. Either have a cake for decoration, or eat it ;-) Bill
Re: Pre-release test tarballs of httpd 1.3.40, 2.0.62 and 2.2.7 available
On 01/06/2008 02:20 AM, Nick Kew wrote: On Sat, 05 Jan 2008 20:28:33 +0100 Ruediger Pluem [EMAIL PROTECTED] wrote: On 01/05/2008 07:04 PM, Nick Kew wrote: On Sat, 05 Jan 2008 12:38:58 +0100 Ruediger Pluem [EMAIL PROTECTED] wrote: Ok. Can you setup a tcpdump between proxy and server and between client and proxy? I guess the network traces would be very helpful in finding out where things are starting to get wrong. One testcase with its tcpdump at http://people.apache.org/~niq/2.2.7/ Thanks for this, but I think this is not sufficient: 1. It seems the dump is incomplete as I cannot see a 0 chunk at the end. 2. I would prefer the binary dump as it offers more possibilities to analyse it with wireshark. Sorry for being that demanding :-) Do you mean as in tcpdump -x? I've uploaded a pair of dumps (one of client-proxy, the other of proxy-server) at the same location. Thanks for that. I think I know what happens: 1. Have a look at the data send to the client. It ends with nesyp\r (see packets 7 and 8 of client.dump) 2. If we have a look at packet 7 of server.dump it ends on 1\r\n n \r\n 1\r\n e \r\n 1\r\n s \r\n 1\r\n y \r\n 1\r\n p\r\n 1 Note that the last byte of this packet is no complete chunk size line. The next packet from the backend is packet 9 which arrives 200 milliseconds later. The data payload starts with \r\n t \r\n What happens in the code? In line 333 of http_filters.c we read the '1' from packet 7. We read this in non blocking mode as we were able to read all previous bytes from this packet non blocking. Keep in mind that we call ap_get_brigade in line 1623 of mod_proxy_http.c for every single character of the response from the backend as we read one complete chunk at most in one single ap_get_brigade call. As we are in non blocking mode and the \r\n only arrives with next packet 200 milliseconds later ap_get_brigade does not return a complete line to us but only 1 and APR_SUCCESS. But we think we have read the full chunk size line and continue our operation accordingly. It doesn't matter if we have a failed (APR_EAGAIN) non blocking read or not in between, our next successful read of *1 byte chunk data* is *\r* that was originally part of the chunk size line. After that we try to get the linefeed after the chunk. And it is there. It is the \n of the chunk size line. Next we expect a new chunk size line so we read byte 3 till 5 of packet 9: t\r\n t is no valid hex character, but get_chunk_size silently ignores this and returns *0* which means that we are complete. So my patch should address this as it insists to read the complete line before we process it. So these kinds of splits between TCP packets does not harm the code any longer in non blocking mode. Regards Rüdiger
Re: Pre-release test tarballs of httpd 1.3.40, 2.0.62 and 2.2.7 available
William A. Rowe, Jr. wrote: Steffen wrote: mod_perl on Windows 2.2.7 Using http://theoryx5.uwinnipeg.ca/ppms/ with ActivePerl 5.8.8.822 FAILS I'd be happy to see a fix; yes I consider 'as a console' to be a test environment, but I also consider it to be very useful and worth fixing. Even the hack to stop a console httpd by-pid is still in status waiting for a patch, as an Enhancement bug. So I won't say no to fixing. I posted an updated patch to bug 43534 for 2.2.7 rc. Currently the parent creates a handle to NUL which gets passed to the child and dup'd to stdin after the parent-pipe is closed. This works fine - but it is only done when Apache is started as a service. Since a parent's console can't be inherited by a child which is started as a detached process - this NUL stdout is needed for command-line startups too. * Apache 2.2.7 started as single process from command-line httpd.exe -X WORKS OK Now that's a little nutty. Would expect -X case to mirror the other command line case. Good clues. In single-process (-X) there is no child process creation, no handle inheritance (or non-inheritance), and the original stdout is a valid console handle. mod_perl is happy with this. One puzzling thing when trying to follow inheritance. Since change 570303 on the APR 1.2 branch (change 569882 on APR trunk), the functions apr_file_inherit_set() and apr_file_inherit_unset() are commented out and become no-ops for WINNT and higher (i.e. when IF_WIN_OS_IS_UNICODE is true). See apr/include/arch/win32/apr_arch_inherit.h near lines 32 and 55 These function are used a lot in threadproc/win32/proc.c - and also used in Apache's mod_file_cache mod_mem_cache. I'm not sure if this change is really intentional or a bug. -tom-
Re: Pre-release test tarballs of httpd 1.3.40, 2.0.62 and 2.2.7 available
Tom Donovan wrote: William A. Rowe, Jr. wrote: Steffen wrote: mod_perl on Windows 2.2.7 Using http://theoryx5.uwinnipeg.ca/ppms/ with ActivePerl 5.8.8.822 FAILS I posted an updated patch to bug 43534 for 2.2.7 rc. Thanks Tom, saw it, reviewing it now. Currently the parent creates a handle to NUL which gets passed to the child and dup'd to stdin after the parent-pipe is closed. This works fine - but it is only done when Apache is started as a service. Since a parent's console can't be inherited by a child which is started as a detached process - this NUL stdout is needed for command-line startups too. Gotcha, made sense. * Apache 2.2.7 started as single process from command-line httpd.exe -X WORKS OK Now that's a little nutty. Would expect -X case to mirror the other command line case. Good clues. In single-process (-X) there is no child process creation, no handle inheritance (or non-inheritance), and the original stdout is a valid console handle. mod_perl is happy with this. One puzzling thing when trying to follow inheritance. Since change 570303 on the APR 1.2 branch (change 569882 on APR trunk), the functions apr_file_inherit_set() and apr_file_inherit_unset() are commented out and become no-ops for WINNT and higher (i.e. when IF_WIN_OS_IS_UNICODE is true). See apr/include/arch/win32/apr_arch_inherit.h near lines 32 and 55 These function are used a lot in threadproc/win32/proc.c - and also used in Apache's mod_file_cache mod_mem_cache. I'm not sure if this change is really intentional or a bug. Extremely intentional. HTTPD is a multithreaded app. Multiple processes are in the process of being spawned at the same time for different purposes. It's especially critical that the usual 'inherited' pipe or file handle of one thread is not inherited on another thread, this was the cause of the pipe leakage. Only three handles should be inherited 'by default' without extra effort. STDIN, STDOUT, and STDERR. And 'flip' them into an non-inherited state when a non-default handle is desired. None of this works on win9x, we can't simply flip this bit. That's why the arch_inherit still does the 'old thing' with 9x builds, we need to let that pipe leakage continue if someone actually uses this junk. So where on earth are files inherited? The answer happens to be the bane of our existence, _dup2(fd, 2); There are a host of side-effects in letting MSVCR into our handles support, one of them is that the stdio dup'ed handles are always set inheritable. It's worth noting if you ever try to implement anything similar. The reason everything works is that even in file_cache and mem_cache, the child is repeating all the steps the parent did. So inheritance is not really used anyways. There's no copy-on-write shared heap through fork() as there is on Unix. It's possible to implement; and it breaks many win32 loadable dll libraries (principal of unexpected consequences). We'll need to modify the whole API of httpd before we can start passing other useful things down to the child process. Using inheritance turns out to be kludgy in a multithreaded environment; explicitly copying the additional handles into the child process space turns out to be cleaner. Back to your patch; as I mentioned I'm reviewing and will commit ASAP. Bill
Re: Pre-release test tarballs of httpd 1.3.40, 2.0.62 and 2.2.7 available
On 01/06/2008 03:20 AM, Takashi Sato wrote: On Fri, 4 Jan 2008 15:00:46 -0500 Jim Jagielski [EMAIL PROTECTED] wrote: Apache HTTP Server fans, The latest versions of all 3 variants of Apache HTTP Server (1.3.40, 2.0.62 and 2.2.7) have been tagged. These are not updated in 2.2: manual/mod/quickreference.html.ko.euc-kr manual/mod/directives.html.de manual/mod/directives.html.es manual/mod/directives.html.ru.koi8-r manual/mod/quickreference.html.ru.koi8-r manual/mod/quickreference.html.de manual/mod/quickreference.html.es manual/mod/directives.html.ko.euc-kr manual/convenience.map and in 2.0: manual/mod/quickreference.html.ko.euc-kr manual/mod/quickreference.html.ru.koi8-r manual/mod/directives.html.ja.euc-jp manual/mod/quickreference.html.ja.euc-jp manual/mod/quickreference.html.de manual/mod/quickreference.html.es manual/mod/directives.html.de manual/mod/directives.html.es manual/mod/directives.html.ko.euc-kr manual/mod/directives.html.ru.koi8-r ./build.sh is not enough. ./build.sh all is needed for 2.0, and ./build.sh all convmap for 2.2. Thanks for the hint. Done in r609341 and r609342. Regards Rüdiger
Re: Pre-release test tarballs of httpd 1.3.40, 2.0.62 and 2.2.7 available
On Jan 4, 2008, at 12:00 PM, Jim Jagielski wrote: The latest versions of all 3 variants of Apache HTTP Server (1.3.40, 2.0.62 and 2.2.7) have been tagged. While it seems to me that we're looking at a re-roll with several patches, please find my test results from the past couple of days. Perhaps this experience finally motivates me to script this exercise since it gets extremely tedious and repetitive, and hence error prone. Compiled with a bunch of modules (see config.nice and config.status at the end) as well as php-5.2.5. Mac OS X 10.5 (Leopard) on PowerPC: [-1] 1.3.40 (CVE-2007-6388 not fixed) [+1] 2.0.62 (with SSL toolkit detection patch, and sendfile disabled) [+1] 2.2.7 Ubuntu 7.10 (Gutsy Gibbon) 64 bits on an Intel Core 2 Mumble: [+0] 1.3.40 (does not build on platform) [+1] 2.0.62 [+1] 2.2.7 FreeBSD 4.11-STABLE i386 running on a single cpu VMWare instance on a dual amd64: [-1] 1.3.40 (CVE-2007-6388 not fixed) [+1] 2.0.62 (with SSL toolkit detection patch) [-0] 2.2.7 (Server doesn't start FreeBSD 4 seems to be completely abandoned by the FreeBSD developers, so I'm going to reinstall this VM with 5-STABLE for the next round. S. Details: Darwin Graymalkin.local 9.1.0 Darwin Kernel Version 9.1.0: Wed Oct 31 17:48:21 PDT 2007; root:xnu-1228.0.2~1/RELEASE_PPC Power Macintosh 2.2.6 Prefork: Failed TestStat Wstat Total Fail List of Failed --- t/php/dirname.t 11 1 t/security/CVE-2007-5000.t21 2 t/security/CVE-2007-6388.t21 2 t/ssl/v2.t11 1 13 tests and 2 subtests skipped. Failed 4/138 test scripts. 4/3003 subtests failed. Files=138, Tests=3003, 687 wallclock secs (132.37 cusr + 30.68 csys = 163.05 CPU) Failed 4/138 test programs. 4/3003 subtests failed. 2.2.7 Prefork: Failed Test Stat Wstat Total Fail List of Failed --- t/php/dirname.t11 1 t/ssl/v2.t 11 1 12 tests and 2 subtests skipped. Failed 2/138 test scripts. 2/3007 subtests failed. Files=138, Tests=3007, 700 wallclock secs (132.38 cusr + 30.72 csys = 163.10 CPU) Failed 2/138 test programs. 2/3007 subtests failed. No regressions. 2.2.6 Worker: Failed TestStat Wstat Total Fail List of Failed --- t/php/dirname.t 11 1 t/security/CVE-2007-5000.t21 2 t/security/CVE-2007-6388.t21 2 t/ssl/v2.t11 1 13 tests and 2 subtests skipped. Failed 4/138 test scripts. 4/3001 subtests failed. Files=138, Tests=3001, 647 wallclock secs (130.19 cusr + 29.92 csys = 160.11 CPU) Failed 4/138 test programs. 4/3001 subtests failed. 2.2.7 Worker: Failed Test Stat Wstat Total Fail List of Failed --- t/php/dirname.t11 1 t/ssl/v2.t 11 1 12 tests and 2 subtests skipped. Failed 2/138 test scripts. 2/3005 subtests failed. Files=138, Tests=3005, 321 wallclock secs (125.97 cusr + 28.59 csys = 154.56 CPU) Failed 2/138 test programs. 2/3005 subtests failed. No regressions. 2.2.6 Event: [Fri Jan 04 22:30:17 2008] [crit] (70023)This function has not been implemented on this platform: Couldn't create a Thread Safe Pollset. Is it supported on your platform? Pre-configuration failed 2.2.7 Event: [Fri Jan 04 22:30:17 2008] [crit] (70023)This function has not been implemented on this platform: Couldn't create a Thread Safe Pollset. Is it supported on your platform? Pre-configuration failed 2.0.61 Prefork: Configured --without-sendfile Failed TestStat Wstat Total Fail List of Failed --- t/php/dirname.t 11 1 t/security/CVE-2007-5000.t21 2 t/security/CVE-2007-6388.t21 2 t/ssl/v2.t11 1 (1 subtest UNEXPECTEDLY SUCCEEDED), 19 tests and 12 subtests skipped. Failed 4/138 test scripts. 4/2987 subtests failed. Files=138, Tests=2987, 860 wallclock secs (128.58 cusr + 28.24 csys = 156.82 CPU) Failed 4/138 test programs. 4/2987 subtests failed. 2.0.62 Prefork: With the SSL Toolkit detection patch Had to configure --without-sendfile Failed Test Stat Wstat Total Fail List of Failed --- t/php/dirname.t11 1 t/ssl/v2.t 11 1 (1 subtest UNEXPECTEDLY SUCCEEDED), 19 tests and 12 subtests skipped. Failed 2/138 test scripts. 2/2987 subtests failed. Files=138, Tests
Re: Pre-release test tarballs of httpd 1.3.40, 2.0.62 and 2.2.7 available
On 01/06/2008 11:39 AM, Ruediger Pluem wrote:
On 01/06/2008 02:20 AM, Nick Kew wrote:
On Sat, 05 Jan 2008 20:28:33 +0100
Ruediger Pluem [EMAIL PROTECTED] wrote:
On 01/05/2008 07:04 PM, Nick Kew wrote:
On Sat, 05 Jan 2008 12:38:58 +0100
Ruediger Pluem [EMAIL PROTECTED] wrote:
Ok. Can you setup a tcpdump between proxy and server and between
client and proxy? I guess the network traces would be very helpful
in finding out where things are starting to get wrong.
One testcase with its tcpdump at
http://people.apache.org/~niq/2.2.7/
Thanks for this, but I think this is not sufficient:
1. It seems the dump is incomplete as I cannot see a 0 chunk at the
end. 2. I would prefer the binary dump as it offers more
possibilities to analyse it with wireshark.
Sorry for being that demanding :-)
Do you mean as in tcpdump -x? I've uploaded a pair of dumps
(one of client-proxy, the other of proxy-server) at the same
location.
Ok, next one. I missed to set the correct state in some situations.
Can you please give it a try again?
Regards
Rüdiger
Index: modules/http/http_filters.c
===
--- modules/http/http_filters.c (Revision 609355)
+++ modules/http/http_filters.c (Arbeitskopie)
@@ -68,8 +68,43 @@
BODY_CHUNK_PART
} state;
int eos_sent;
+char chunk_ln[30];
+char *pos;
} http_ctx_t;
+static apr_status_t get_chunk_line(http_ctx_t *ctx, int len)
+{
+/*
+ * Check if we do not overflow our chunksize / empty line buffer
+ * (ctx-chunk_ln). If we do the chunksize / empty line is bogus anyway so
+ * bail out in this case.
+ * XXX: Currently we are very limited in accepting chunk-extensions. If
+ * this is needed the chunk_ln buffer must be much larger or we must
+ * find a different way to discard them as we do not process them anyway.
+ */
+if ((ctx-pos - ctx-chunk_ln) + len sizeof(ctx-chunk_ln)) {
+ctx-pos += len;
+*(ctx-pos) = '\0';
+/*
+ * Check if we really got a full line. If yes the
+ * last char in the just read buffer must be LF.
+ * If not advance the buffer and return APR_EAGAIN.
+ * We do not start processing until we have the
+ * full line.
+ */
+if (ctx-pos[-1] != APR_ASCII_LF) {
+return APR_EAGAIN;
+}
+/*
+ * Line is complete. So reset ctx-pos for next round.
+ */
+ctx-pos = ctx-chunk_ln;
+return APR_SUCCESS;
+}
+return APR_ENOSPC;
+}
+
+
/* This is the HTTP_INPUT filter for HTTP requests and responses from
* proxied servers (mod_proxy). It handles chunked and content-length
* bodies. This can only be inserted/used after the headers
@@ -96,6 +131,7 @@
ctx-remaining = 0;
ctx-limit_used = 0;
ctx-eos_sent = 0;
+ctx-pos = ctx-chunk_ln;
/* LimitRequestBody does not apply to proxied responses.
* Consider implementing this check in its own filter.
@@ -227,9 +263,8 @@
/* We can't read the chunk until after sending 100 if required. */
if (ctx-state == BODY_CHUNK) {
-char line[30];
apr_bucket_brigade *bb;
-apr_size_t len = 30;
+apr_size_t len = sizeof(ctx-chunk_ln) - (ctx-pos - ctx-chunk_ln);
apr_off_t brigade_length;
bb = apr_brigade_create(f-r-pool, f-c-bucket_alloc);
@@ -256,9 +291,17 @@
rv = APR_ENOSPC;
}
if (rv == APR_SUCCESS) {
-rv = apr_brigade_flatten(bb, line, len);
+rv = apr_brigade_flatten(bb, ctx-pos, len);
if (rv == APR_SUCCESS) {
-ctx-remaining = get_chunk_size(line);
+rv = get_chunk_line(ctx, len);
+if (APR_STATUS_IS_EAGAIN(rv)) {
+apr_brigade_cleanup(bb);
+ctx-state = BODY_CHUNK_PART;
+return rv;
+}
+if (rv == APR_SUCCESS) {
+ctx-remaining = get_chunk_size(ctx-chunk_ln);
+}
}
}
}
@@ -308,9 +351,9 @@
case BODY_CHUNK:
case BODY_CHUNK_PART:
{
-char line[30];
apr_bucket_brigade *bb;
-apr_size_t len = 30;
+apr_size_t len = sizeof(ctx-chunk_ln)
+ - (ctx-pos - ctx-chunk_ln);
apr_status_t http_error = HTTP_REQUEST_ENTITY_TOO_LARGE;
bb = apr_brigade_create(f-r-pool, f-c-bucket_alloc);
@@ -319,11 +362,21 @@
if (ctx-state == BODY_CHUNK) {
rv = ap_get_brigade(f-next, bb, AP_MODE_GETLINE,
block, 0
Re: Pre-release test tarballs of httpd 1.3.40, 2.0.62 and 2.2.7 available
William A. Rowe, Jr. wrote: Tom Donovan wrote: William A. Rowe, Jr. wrote: Steffen wrote: mod_perl on Windows 2.2.7 Using http://theoryx5.uwinnipeg.ca/ppms/ with ActivePerl 5.8.8.822 FAILS I posted an updated patch to bug 43534 for 2.2.7 rc. Thanks Tom, saw it, reviewing it now. There's much more history on this in PR 43534, but in short; Can't adopt your patch literally since it regresses the server code (and leaves no stdout at all for a dangerous period of time). But I derived a patch from your observations and the unix MPMs' behavior. In two parts (because I'm a goof who thinks he can hack at Win32 on linux) the cumulative patch to open stdout for a console to /Device/Nul, in exactly the same sequence as unix, is here; http://svn.apache.org/viewvc/httpd/httpd/trunk/server/mpm/winnt/mpm_winnt.c?r1=607677r2=609366
Re: Pre-release test tarballs of httpd 1.3.40, 2.0.62 and 2.2.7 available
On 01/06/2008 07:13 PM, Sander Temme wrote:
On Jan 4, 2008, at 12:00 PM, Jim Jagielski wrote:
The latest versions of all 3 variants of Apache HTTP Server (1.3.40,
2.0.62 and 2.2.7) have been tagged.
While it seems to me that we're looking at a re-roll with several
patches, please find my test results from the past couple of days.
Perhaps this experience finally motivates me to script this exercise
since it gets extremely tedious and repetitive, and hence error prone.
Compiled with a bunch of modules (see config.nice and config.status at
the end) as well as php-5.2.5.
Mac OS X 10.5 (Leopard) on PowerPC:
[-1] 1.3.40 (CVE-2007-6388 not fixed)
There is a patch available from Mark J Cox for 1.3 which I attach.
Regards
Rüdiger
Index: src/CHANGES
===
--- src/CHANGES (revision 606689)
+++ src/CHANGES (working copy)
@@ -1,5 +1,10 @@
Changes with Apache 1.3.40
+ *) SECURITY: CVE-2007-6388 (cve.mitre.org)
+ mod_status: Ensure refresh parameter is numeric to prevent
+ a possible XSS attack caused by redirecting to other URLs.
+ Reported by SecurityReason. [Mark Cox]
+
*) SECURITY: CVE-2007-5000 (cve.mitre.org)
mod_imap: Fix cross-site scripting issue. Reported by JPCERT.
[Joe Orton]
Index: src/modules/standard/mod_status.c
===
--- src/modules/standard/mod_status.c (revision 604646)
+++ src/modules/standard/mod_status.c (working copy)
@@ -232,17 +232,15 @@
while (status_options[i].id != STAT_OPT_END) {
if ((loc = strstr(r-args, status_options[i].form_data_str)) != NULL) {
switch (status_options[i].id) {
- case STAT_OPT_REFRESH:
- if (*(loc + strlen(status_options[i].form_data_str)) == '='
- atol(loc + strlen(status_options[i].form_data_str)
-+ 1) 0)
- ap_table_set(r-headers_out,
- status_options[i].hdr_out_str,
- loc + strlen(status_options[i].hdr_out_str) + 1);
- else
- ap_table_set(r-headers_out,
- status_options[i].hdr_out_str, 1);
- break;
+case STAT_OPT_REFRESH: {
+long refreshtime = 0;
+if (*(loc + strlen(status_options[i].form_data_str)) == '=')
+refreshtime = atol(loc + strlen(status_options[i].form_data_str)+1);
+ap_table_set(r-headers_out,
+ status_options[i].hdr_out_str,
+ ap_psprintf(r-pool,%ld,(refreshtime1)?1:refreshtime));
+break;
+}
case STAT_OPT_NOTABLE:
no_table_report = 1;
break;
Re: Pre-release test tarballs of httpd 1.3.40, 2.0.62 and 2.2.7 available
On Sat, 5 Jan 2008 00:07:42 + Nick Kew [EMAIL PROTECTED] wrote: A quick heads-up: Regression: fails to proxy massively chunked responses. r609394 fixes this, but introduces (or unmasks) new issues with chunked data edge-cases. Specifically, two testcases in which the termination of the chunked data involves extra zeros (65 in total): [valid chunk] 000\r\n \r\n Silly, but technically we should accept it. 1. With that in the Request, httpd rejects it with 413. Seems fair to me. 2. With that in the Response, httpd breaks more seriously: it fails to forward *any* termination, and the client is left in limbo expecting more data. This one we need to fix. The response trace is: HTTP/1.1 200 OK\r\n Transfer-Encoding: chunked\r\n Date: Sun, 06 Jan 2008 22:47:28 GMT\r\n Connection: close\r\n \r\n 64\r\n [data]\r\n 0\r\n \r\n which the proxy turns into: HTTP/1.1 200 OK\r\n Date: Sun, 06 Jan 2008 22:47:28 GMT\r\n Via: 1.1 grimnir.webthing.com\r\n Connection: close\r\n Transfer-Encoding: chunked\r\n \r\n 64\r\n [data]\r\n nothing more! -- Nick Kew Application Development with Apache - the Apache Modules Book http://www.apachetutor.org/
Test suite on Darwin was Re: Pre-release test tarballs of httpd 1.3.40, 2.0.62 and 2.2.7 available
On Jan 6, 2008 10:13 AM, Sander Temme [EMAIL PROTECTED] wrote: Mac OS X 10.5 (Leopard) on PowerPC: [-1] 1.3.40 (CVE-2007-6388 not fixed) [+1] 2.0.62 (with SSL toolkit detection patch, and sendfile disabled) [+1] 2.2.7 Darwin Graymalkin.local 9.1.0 Darwin Kernel Version 9.1.0: Wed Oct 31 17:48:21 PDT 2007; root:xnu-1228.0.2~1/RELEASE_PPC Power Macintosh 2.2.7 Prefork: Failed Test Stat Wstat Total Fail List of Failed --- t/php/dirname.t11 1 t/ssl/v2.t 11 1 12 tests and 2 subtests skipped. Failed 2/138 test scripts. 2/3007 subtests failed. Files=138, Tests=3007, 700 wallclock secs (132.38 cusr + 30.72 csys = 163.10 CPU) Failed 2/138 test programs. 2/3007 subtests failed. No regressions. Interesting in that this differs from my tests on 10.5.1/Intel (see my earlier post). What perl / LWP were you using? I'm kind of concerned if we diverge on Intel vs. PowerPC... -- justin
Re: Test suite on Darwin was Re: Pre-release test tarballs of httpd 1.3.40, 2.0.62 and 2.2.7 available
On Jan 6, 2008, at 11:18 PM, Justin Erenkrantz wrote: Interesting in that this differs from my tests on 10.5.1/Intel (see my earlier post). What perl / LWP were you using? I actually built my own perl 5.10.0, put its bin in front of my PATH and installed all the requisite modules. I did this mainly because I don't want to mess with the system installation, but prefer to hose one I can easily replace. (: Perl 5.10.0 Crypt::SSLeay 0.57 LWP 5.808 MIME::Base64 3.07_01 Digest::MD5 2.36_01 I'm kind of concerned if we diverge on Intel vs. PowerPC... -- justin Your failure pattern actually smacks of broken Crypt::SSLeay, Digest::MD5 or even MIME::Base64 fu: try forcing those modules to (re)install. S. -- Sander Temme [EMAIL PROTECTED] PGP FP: 51B4 8727 466A 0BC3 69F4 B7B8 B2BE BC40 1529 24AF
Re: Pre-release test tarballs of httpd 1.3.40, 2.0.62 and 2.2.7 available
On 01/05/2008 02:02 AM, Nick Kew wrote: On Sat, 5 Jan 2008 00:07:42 + Nick Kew [EMAIL PROTECTED] wrote: Regression: fails to proxy massively chunked responses. OK, it works correctly if I revert r602679 (no other changes). Investigating further. It would be helpful if you could provide us with more details what exactly fails and if possible with a test case. Regards Rüdiger
Re: Pre-release test tarballs of httpd 1.3.40, 2.0.62 and 2.2.7 available
On Sat, 05 Jan 2008 10:37:53 +0100 Ruediger Pluem [EMAIL PROTECTED] wrote: On 01/05/2008 02:02 AM, Nick Kew wrote: On Sat, 5 Jan 2008 00:07:42 + Nick Kew [EMAIL PROTECTED] wrote: Regression: fails to proxy massively chunked responses. OK, it works correctly if I revert r602679 (no other changes). Investigating further. It would be helpful if you could provide us with more details what exactly fails and if possible with a test case. http://people.apache.org/~niq/TestLogWebViewer.html (note: s/100Byte/1Byte in the test case description, as is clear from the trace). -- Nick Kew Application Development with Apache - the Apache Modules Book http://www.apachetutor.org/
Re: Pre-release test tarballs of httpd 1.3.40, 2.0.62 and 2.2.7 available
Building fine with GUI on VS 2005 out of the box.
With the shipped httpd.conf It works!
It crashes when apr_bucket_alloc() is called by modules
and also when eg. EnableMMAP off is set:
\srclib\apr-util\buckets\apr_buckets_alloc.c
+ list 0x00b71f10 {pool=0x00b6ff08 allocator=0x freelist=0x
...} apr_bucket_alloc_t *
libaprutil-1.dll!apr_bucket_alloc(unsigned int size=40, apr_bucket_alloc_t
* list=0x00b71f10) Line 135 C
Steffen
- Original Message -
From: Jim Jagielski [EMAIL PROTECTED]
To: [EMAIL PROTECTED]; dev@httpd.apache.org
Sent: Friday, 04 January, 2008 21:00
Subject: Pre-release test tarballs of httpd 1.3.40, 2.0.62 and 2.2.7
available
Apache HTTP Server fans,
The latest versions of all 3 variants of Apache HTTP Server (1.3.40,
2.0.62 and 2.2.7) have been tagged. The test tarballs are available
for testing and feedback at the below location. Everyone is reminded
that this does not constitute an official release of these
tarballs yet; assuming these pass muster, the hope and intent is
to release and announce early next week.
All files in:
http://httpd.apache.org/dev/dist/
Re: Pre-release test tarballs of httpd 1.3.40, 2.0.62 and 2.2.7 available
On 01/05/2008 11:02 AM, Nick Kew wrote:
On Sat, 05 Jan 2008 10:37:53 +0100
Ruediger Pluem [EMAIL PROTECTED] wrote:
On 01/05/2008 02:02 AM, Nick Kew wrote:
On Sat, 5 Jan 2008 00:07:42 +
Nick Kew [EMAIL PROTECTED] wrote:
Regression: fails to proxy massively chunked responses.
OK, it works correctly if I revert r602679 (no other changes).
Investigating further.
It would be helpful if you could provide us with more details what
exactly fails and if possible with a test case.
http://people.apache.org/~niq/TestLogWebViewer.html
(note: s/100Byte/1Byte in the test case description, as is clear
from the trace).
Can you please try if the following patch against the vanilla tar ball
fixes the problem?
Index: modules/http/http_filters.c
===
--- modules/http/http_filters.c (Revision 609114)
+++ modules/http/http_filters.c (Arbeitskopie)
@@ -321,7 +321,8 @@
block, 0);
apr_brigade_cleanup(bb);
if (block == APR_NONBLOCK_READ
-(APR_STATUS_IS_EAGAIN(rv))) {
+( (rv == APR_SUCCESS APR_BRIGADE_EMPTY(bb)) ||
+ (APR_STATUS_IS_EAGAIN(rv)) )) {
return APR_EAGAIN;
}
} else {
Regards
Rüdiger
Re: Pre-release test tarballs of httpd 1.3.40, 2.0.62 and 2.2.7 available
On Sat, 05 Jan 2008 11:47:40 +0100 Ruediger Pluem [EMAIL PROTECTED] wrote: Can you please try if the following patch against the vanilla tar ball fixes the problem? Nope. Causes both test cases to give just one byte of response. -- Nick Kew Application Development with Apache - the Apache Modules Book http://www.apachetutor.org/
Re: Pre-release test tarballs of httpd 1.3.40, 2.0.62 and 2.2.7 available
On 01/05/2008 11:56 AM, Nick Kew wrote:
On Sat, 05 Jan 2008 11:47:40 +0100
Ruediger Pluem [EMAIL PROTECTED] wrote:
Can you please try if the following patch against the vanilla tar ball
fixes the problem?
Nope. Causes both test cases to give just one byte of response.
Sorry my first patch was bogus of course :-(. Please try the following:
Index: modules/http/http_filters.c
===
--- modules/http/http_filters.c (Revision 609114)
+++ modules/http/http_filters.c (Arbeitskopie)
@@ -319,11 +319,12 @@
if (ctx-state == BODY_CHUNK) {
rv = ap_get_brigade(f-next, bb, AP_MODE_GETLINE,
block, 0);
-apr_brigade_cleanup(bb);
if (block == APR_NONBLOCK_READ
-(APR_STATUS_IS_EAGAIN(rv))) {
+( (rv == APR_SUCCESS APR_BRIGADE_EMPTY(bb)) ||
+ (APR_STATUS_IS_EAGAIN(rv)) )) {
return APR_EAGAIN;
}
+apr_brigade_cleanup(bb);
} else {
rv = APR_SUCCESS;
}
Regards
Rüdiger
Re: Pre-release test tarballs of httpd 1.3.40, 2.0.62 and 2.2.7 available
On 01/05/2008 11:36 AM, Steffen wrote:
Building fine with GUI on VS 2005 out of the box.
With the shipped httpd.conf It works!
It crashes when apr_bucket_alloc() is called by modules
and also when eg. EnableMMAP off is set:
\srclib\apr-util\buckets\apr_buckets_alloc.c
+ list 0x00b71f10 {pool=0x00b6ff08 allocator=0x
freelist=0x
...} apr_bucket_alloc_t *
With an allocator set to NULL
libaprutil-1.dll!apr_bucket_alloc(unsigned int size=40,
apr_bucket_alloc_t
* list=0x00b71f10) Line 135 C
A longer stack trace would be helpful here.
Regards
Rüdiger
Re: Pre-release test tarballs of httpd 1.3.40, 2.0.62 and 2.2.7 available
On Jan 5, 2008 11:36 AM, Steffen [EMAIL PROTECTED] wrote:
It crashes when apr_bucket_alloc() is called by modules
and also when eg. EnableMMAP off is set:
\srclib\apr-util\buckets\apr_buckets_alloc.c
+ list 0x00b71f10 {pool=0x00b6ff08 allocator=0x freelist=0x
...} apr_bucket_alloc_t *
libaprutil-1.dll!apr_bucket_alloc(unsigned int size=40, apr_bucket_alloc_t
* list=0x00b71f10) Line 135 C
Any pointers on reproducing it... everything on my development config
seems fine and I'm not getting errors.
--
~Jorge
Re: Pre-release test tarballs of httpd 1.3.40, 2.0.62 and 2.2.7 available
On Sat, 05 Jan 2008 12:11:07 +0100 Ruediger Pluem [EMAIL PROTECTED] wrote: Can you please try if the following patch against the vanilla tar ball fixes the problem? Nope. Causes both test cases to give just one byte of response. Sorry my first patch was bogus of course :-(. Please try the following: Back to square one, with 433 bytes of response. (FWIW, I already tried moving the cleanup last night). -- Nick Kew Application Development with Apache - the Apache Modules Book http://www.apachetutor.org/
Re: Pre-release test tarballs of httpd 1.3.40, 2.0.62 and 2.2.7 available
On 01/05/2008 12:27 PM, Nick Kew wrote: On Sat, 05 Jan 2008 12:11:07 +0100 Ruediger Pluem [EMAIL PROTECTED] wrote: Can you please try if the following patch against the vanilla tar ball fixes the problem? Nope. Causes both test cases to give just one byte of response. Sorry my first patch was bogus of course :-(. Please try the following: Back to square one, with 433 bytes of response. (FWIW, I already tried moving the cleanup last night). Ok. Can you setup a tcpdump between proxy and server and between client and proxy? I guess the network traces would be very helpful in finding out where things are starting to get wrong. Regards Rüdiger
Re: Pre-release test tarballs of httpd 1.3.40, 2.0.62 and 2.2.7 available
Looks like that it happens only when add Win32DisableAcceptEx to the conf.
Steffen
- Original Message -
From: Ruediger Pluem [EMAIL PROTECTED]
To: dev@httpd.apache.org
Sent: Saturday, 05 January, 2008 12:12
Subject: Re: Pre-release test tarballs of httpd 1.3.40, 2.0.62 and 2.2.7
available
On 01/05/2008 11:36 AM, Steffen wrote:
Building fine with GUI on VS 2005 out of the box.
With the shipped httpd.conf It works!
It crashes when apr_bucket_alloc() is called by modules
and also when eg. EnableMMAP off is set:
\srclib\apr-util\buckets\apr_buckets_alloc.c
+ list 0x00b71f10 {pool=0x00b6ff08 allocator=0x
freelist=0x
...} apr_bucket_alloc_t *
With an allocator set to NULL
libaprutil-1.dll!apr_bucket_alloc(unsigned int size=40,
apr_bucket_alloc_t
* list=0x00b71f10) Line 135 C
A longer stack trace would be helpful here.
Regards
Rüdiger
Re: Pre-release test tarballs of httpd 1.3.40, 2.0.62 and 2.2.7 available
That could explain why I'm not seeing it... I don't have
Win32DisableAcceptEx in there.
I'll report back later once I add it.
On Jan 5, 2008 1:08 PM, Steffen [EMAIL PROTECTED] wrote:
Looks like that it happens only when add Win32DisableAcceptEx to the conf.
Steffen
- Original Message -
From: Ruediger Pluem [EMAIL PROTECTED]
To: dev@httpd.apache.org
Sent: Saturday, 05 January, 2008 12:12
Subject: Re: Pre-release test tarballs of httpd 1.3.40, 2.0.62 and 2.2.7
available
On 01/05/2008 11:36 AM, Steffen wrote:
Building fine with GUI on VS 2005 out of the box.
With the shipped httpd.conf It works!
It crashes when apr_bucket_alloc() is called by modules
and also when eg. EnableMMAP off is set:
\srclib\apr-util\buckets\apr_buckets_alloc.c
+ list 0x00b71f10 {pool=0x00b6ff08 allocator=0x
freelist=0x
...} apr_bucket_alloc_t *
With an allocator set to NULL
libaprutil-1.dll!apr_bucket_alloc(unsigned int size=40,
apr_bucket_alloc_t
* list=0x00b71f10) Line 135 C
A longer stack trace would be helpful here.
Regards
Rüdiger
--
~Jorge
Re: Pre-release test tarballs of httpd 1.3.40, 2.0.62 and 2.2.7 available
Indeed with Win32DisableAcceptEx in there is bombs out :(
Same location as Steffen
On Jan 5, 2008 1:08 PM, Steffen [EMAIL PROTECTED] wrote:
Looks like that it happens only when add Win32DisableAcceptEx to the conf.
Steffen
- Original Message -
From: Ruediger Pluem [EMAIL PROTECTED]
To: dev@httpd.apache.org
Sent: Saturday, 05 January, 2008 12:12
Subject: Re: Pre-release test tarballs of httpd 1.3.40, 2.0.62 and 2.2.7
available
On 01/05/2008 11:36 AM, Steffen wrote:
Building fine with GUI on VS 2005 out of the box.
With the shipped httpd.conf It works!
It crashes when apr_bucket_alloc() is called by modules
and also when eg. EnableMMAP off is set:
\srclib\apr-util\buckets\apr_buckets_alloc.c
+ list 0x00b71f10 {pool=0x00b6ff08 allocator=0x
freelist=0x
...} apr_bucket_alloc_t *
With an allocator set to NULL
libaprutil-1.dll!apr_bucket_alloc(unsigned int size=40,
apr_bucket_alloc_t
* list=0x00b71f10) Line 135 C
A longer stack trace would be helpful here.
Regards
Rüdiger
--
~Jorge
Re: Pre-release test tarballs of httpd 1.3.40, 2.0.62 and 2.2.7 available
On 01/05/2008 11:02 AM, Nick Kew wrote: On Sat, 05 Jan 2008 10:37:53 +0100 Ruediger Pluem [EMAIL PROTECTED] wrote: On 01/05/2008 02:02 AM, Nick Kew wrote: On Sat, 5 Jan 2008 00:07:42 + Nick Kew [EMAIL PROTECTED] wrote: Regression: fails to proxy massively chunked responses. OK, it works correctly if I revert r602679 (no other changes). Investigating further. It would be helpful if you could provide us with more details what exactly fails and if possible with a test case. http://people.apache.org/~niq/TestLogWebViewer.html Some observations: 1. I tried to reproduce it with a backend that as well send 1 byte chunks: Everything works fin. 2. Excerpt from first test results: 1\r\n \r\r\n e\r\n 1\r\n z\r\n 1\r\n m\r\n 1\r\r\n 0\r\n \r\n This an invalid chunked encoding (\r is already the one byte that was announced for this chunk. e\r\n would need to have 1\r\n in front). This is very strange as the ap_http_filter dechunks the results from backend and ap_http_chunk_filter creates a new chunked encoding. 3. Both seem to see stray \r characters which I suppose to be not part of the content. As said for this reason the network sniffs would be really interesting. Regards Rüdiger
Re: Pre-release test tarballs of httpd 1.3.40, 2.0.62 and 2.2.7 available
Agreed... trying to recreate here... On Jan 5, 2008, at 8:21 AM, Ruediger Pluem wrote: On 01/05/2008 11:02 AM, Nick Kew wrote: On Sat, 05 Jan 2008 10:37:53 +0100 Ruediger Pluem [EMAIL PROTECTED] wrote: On 01/05/2008 02:02 AM, Nick Kew wrote: On Sat, 5 Jan 2008 00:07:42 + Nick Kew [EMAIL PROTECTED] wrote: Regression: fails to proxy massively chunked responses. OK, it works correctly if I revert r602679 (no other changes). Investigating further. It would be helpful if you could provide us with more details what exactly fails and if possible with a test case. http://people.apache.org/~niq/TestLogWebViewer.html Some observations: 1. I tried to reproduce it with a backend that as well send 1 byte chunks: Everything works fin. 2. Excerpt from first test results: 1\r\n \r\r\n e\r\n 1\r\n z\r\n 1\r\n m\r\n 1\r\r\n 0\r\n \r\n This an invalid chunked encoding (\r is already the one byte that was announced for this chunk. e\r\n would need to have 1\r\n in front). This is very strange as the ap_http_filter dechunks the results from backend and ap_http_chunk_filter creates a new chunked encoding. 3. Both seem to see stray \r characters which I suppose to be not part of the content. As said for this reason the network sniffs would be really interesting. Regards Rüdiger
Re: Pre-release test tarballs of httpd 1.3.40, 2.0.62 and 2.2.7 available
On Jan 4, 2008, at 7:07 PM, Nick Kew wrote: On Fri, 4 Jan 2008 15:00:46 -0500 Jim Jagielski [EMAIL PROTECTED] wrote: Apache HTTP Server fans, The latest versions of all 3 variants of Apache HTTP Server (1.3.40, 2.0.62 and 2.2.7) have been tagged. Regression: fails to proxy massively chunked responses. Just to be clear, is this a regression from 2.2.6 or from just 2.2.6+ ?
Re: Pre-release test tarballs of httpd 1.3.40, 2.0.62 and 2.2.7 available
On Sat, 5 Jan 2008 10:06:04 -0500 Jim Jagielski [EMAIL PROTECTED] wrote: Regression: fails to proxy massively chunked responses. Just to be clear, is this a regression from 2.2.6 or from just 2.2.6+ ? Both. And almost certainly from earlier versions. p.s. I'm just back at my desk; will produce a tcpdump soon. -- Nick Kew Application Development with Apache - the Apache Modules Book http://www.apachetutor.org/
Re: Pre-release test tarballs of httpd 1.3.40, 2.0.62 and 2.2.7 available
Steffen wrote:
Looks like that it happens only when add Win32DisableAcceptEx to the conf.
Steffen
On 01/05/2008 11:36 AM, Steffen wrote:
It crashes when apr_bucket_alloc() is called by modules
...
\srclib\apr-util\buckets\apr_buckets_alloc.c
+ list 0x00b71f10 {pool=0x00b6ff08 allocator=0x
freelist=0x
...} apr_bucket_alloc_t *
With an allocator set to NULL
This appears to be caused by change 607394 for bug 11427.
Fix winnt bucket_alloc to borrow memory from the transaction pool
I added a note and additional patch to bug 11427.
-tom-
Re: Pre-release test tarballs of httpd 1.3.40, 2.0.62 and 2.2.7 available
On 01/05/2008 05:00 PM, Tom Donovan wrote:
Steffen wrote:
Looks like that it happens only when add Win32DisableAcceptEx to the
conf.
Steffen
On 01/05/2008 11:36 AM, Steffen wrote:
It crashes when apr_bucket_alloc() is called by modules
...
\srclib\apr-util\buckets\apr_buckets_alloc.c
+ list 0x00b71f10 {pool=0x00b6ff08 allocator=0x
freelist=0x
...} apr_bucket_alloc_t *
With an allocator set to NULL
This appears to be caused by change 607394 for bug 11427.
Fix winnt bucket_alloc to borrow memory from the transaction pool
I added a note and additional patch to bug 11427.
Although I have limited knowledge in the Windows MPM the patch looks reasonable.
I assume you have already tested that the crash now disappears with your patch
added. Thanks for investigating.
Regards
Rüdiger
Re: Pre-release test tarballs of httpd 1.3.40, 2.0.62 and 2.2.7 available
With 2.2.7 on windows mod_perl is still not working, 2.2.4 was the latest version where mod_perl was working. mod_perl with Apache as service crashes when starting Apache. mod_perl with Apache cmd-line Apache starts but does not dipslay a page, no signs in the logs. Rather as with 2.2.6 we prefer not to make again a patch for the Apachelounge community. Btw. mod_fcgid looks now ok. Steffen - Original Message - From: Jim Jagielski [EMAIL PROTECTED] To: [EMAIL PROTECTED]; dev@httpd.apache.org Sent: Friday, 04 January, 2008 21:00 Subject: Pre-release test tarballs of httpd 1.3.40, 2.0.62 and 2.2.7 available Apache HTTP Server fans, The latest versions of all 3 variants of Apache HTTP Server (1.3.40, 2.0.62 and 2.2.7) have been tagged. The test tarballs are available for testing and feedback at the below location. Everyone is reminded that this does not constitute an official release of these tarballs yet; assuming these pass muster, the hope and intent is to release and announce early next week. All files in: http://httpd.apache.org/dev/dist/
Re: Pre-release test tarballs of httpd 1.3.40, 2.0.62 and 2.2.7 available
On Jan 5, 2008 5:26 PM, Steffen [EMAIL PROTECTED] wrote: With 2.2.7 on windows mod_perl is still not working, 2.2.4 was the latest version where mod_perl was working. mod_perl with Apache as service crashes when starting Apache. mod_perl with Apache cmd-line Apache starts but does not dipslay a page, no signs in the logs. mod_perl compiled fine over here! and is loaded... I don't have an extensive config though to test. I'm using an older perl compiled vs.net 2003. -- # Perl Configuration IfModule mpm_winnt.c LoadFile /perl/bin/perl58.dll /IfModule LoadModule perl_module modules/mod_perl.so IfModule mod_perl.c #perl startup modules PerlModule ModPerl::Util; PerlModule Apache2::RequestRec; PerlModule Apache2::RequestIO; PerlModule Apache2::RequestUtil; PerlModule Apache2::ServerRec; PerlModule Apache2::ServerUtil; PerlModule Apache2::Connection; PerlModule Apache2::Log; PerlModule Apache2::Const:common; PerlModule APR::Const:common; PerlModule APR::Table; PerlModule Apache2::compat; #PerlModule CGI; PerlResponseHandler ModPerl::Registry; /IfModule -- with that config it seems to work fine over here if you want I can send you my binary + perl binary. Rather as with 2.2.6 we prefer not to make again a patch for the Apachelounge community. Btw. mod_fcgid looks now ok. Yep working over here aswel! Steffen - Original Message - From: Jim Jagielski [EMAIL PROTECTED] To: [EMAIL PROTECTED]; dev@httpd.apache.org Sent: Friday, 04 January, 2008 21:00 Subject: Pre-release test tarballs of httpd 1.3.40, 2.0.62 and 2.2.7 available Apache HTTP Server fans, The latest versions of all 3 variants of Apache HTTP Server (1.3.40, 2.0.62 and 2.2.7) have been tagged. The test tarballs are available for testing and feedback at the below location. Everyone is reminded that this does not constitute an official release of these tarballs yet; assuming these pass muster, the hope and intent is to release and announce early next week. All files in: http://httpd.apache.org/dev/dist/ -- ~Jorge
Re: Pre-release test tarballs of httpd 1.3.40, 2.0.62 and 2.2.7 available
On 01/05/2008 03:54 PM, Jim Jagielski wrote: 2. Excerpt from first test results: 1\r\n \r\r\n e\r\n 1\r\n z\r\n 1\r\n m\r\n 1\r\r\n 0\r\n \r\n This an invalid chunked encoding (\r is already the one byte that was announced for this chunk. e\r\n would need to have 1\r\n in front). This is very strange as the ap_http_filter dechunks the results from backend and ap_http_chunk_filter creates a new chunked encoding. I have to correct myself a little bit. I read this from the beginning which indicates wrong chunked encoding. In fact it has to read from the back so we end up with 1\r\n \r\r\n e\r\n 1\r\n z\r\n 1\r\n m\r\n 1\r\r\n 0\r\n \r\n Formating this chunklength\r\n content \r\n results in 1\r\n \r \r\n e\r\n 1\r\nz\r\n1\r\nm\r\n1\r \r\n 0\r\n \r\n which would be correct. Regards Rüdiger
Re: Pre-release test tarballs of httpd 1.3.40, 2.0.62 and 2.2.7 available
I just recompiled with that patch. The crashes with are now indeed gone! So all is good it seems :) On Jan 5, 2008 5:09 PM, Ruediger Pluem [EMAIL PROTECTED] wrote: Although I have limited knowledge in the Windows MPM the patch looks reasonable. I assume you have already tested that the crash now disappears with your patch added. Thanks for investigating. Regards Rüdiger -- ~Jorge
Re: Pre-release test tarballs of httpd 1.3.40, 2.0.62 and 2.2.7 available
Yes, the crash dissappears. I built with MS Visual Studio 8 on win2k and tested on win2k, winxp, and vista. Also tried it with: ab -n 10 -c 100 http://localhost/large_file.html Where large_file.html is 200kb. No continued memory growth observed (after the first few seconds), so I don't think it is leaking allocators. -tom- Ruediger Pluem wrote: I added a note and additional patch to bug 11427. Although I have limited knowledge in the Windows MPM the patch looks reasonable. I assume you have already tested that the crash now disappears with your patch added. Thanks for investigating. Regards Rüdiger
Re: Pre-release test tarballs of httpd 1.3.40, 2.0.62 and 2.2.7 available
On Sat, 05 Jan 2008 12:38:58 +0100 Ruediger Pluem [EMAIL PROTECTED] wrote: Ok. Can you setup a tcpdump between proxy and server and between client and proxy? I guess the network traces would be very helpful in finding out where things are starting to get wrong. One testcase with its tcpdump at http://people.apache.org/~niq/2.2.7/ Sorry it took so long to get around tuit. -- Nick Kew Application Development with Apache - the Apache Modules Book http://www.apachetutor.org/
Re: Pre-release test tarballs of httpd 1.3.40, 2.0.62 and 2.2.7 available
Tom Donovan wrote: Yes, the crash dissappears. I built with MS Visual Studio 8 on win2k and tested on win2k, winxp, and vista. ab -n 10 -c 100 http://localhost/large_file.html Where large_file.html is 200kb. No continued memory growth observed (after the first few seconds), so I don't think it is leaking allocators. Fantastic. Code drift between the Win9x case (now pretty much irrelevant) and WinNT disabling acceptex really is unacceptable now, but I don't want to touch the 2.0/2.2 code again if we can avoid it. Best solution is a refactoring which I might find a weekend for in the next month or so. I'm going to propose we dump DisableWin32AcceptEx syntax entirely in 2.4, and instead use our new friendly syntax; AcceptFilter http ex-data (current acceptex, plus some data) AcceptFilter https ex (current acceptex, but no data) AcceptFilter http none(vanilla accept) Does this sound like the right approach before I start hacking anything? Bill
Re: Pre-release test tarballs of httpd 1.3.40, 2.0.62 and 2.2.7 available
Steffen wrote: Building fine with GUI on VS 2005 out of the box. It crashes when apr_bucket_alloc() is called by modules and also when eg. EnableMMAP off is set: This was actually the win9x transaction pump, which is actually used by Win32DisableAcceptEx. EnableMMAP was something of a red herring. Tom's patch to PR 11427 nailed it. Thanks for the report!
Re: Pre-release test tarballs of httpd 1.3.40, 2.0.62 and 2.2.7 available
On Jan 5, 2008 7:45 PM, William A. Rowe, Jr. [EMAIL PROTECTED] wrote: Tom Donovan wrote: Yes, the crash dissappears. I built with MS Visual Studio 8 on win2k and tested on win2k, winxp, and vista. ab -n 10 -c 100 http://localhost/large_file.html Where large_file.html is 200kb. No continued memory growth observed (after the first few seconds), so I don't think it is leaking allocators. Fantastic. Code drift between the Win9x case (now pretty much irrelevant) and WinNT disabling acceptex really is unacceptable now, but I don't want to touch the 2.0/2.2 code again if we can avoid it. Best solution is a refactoring which I might find a weekend for in the next month or so. I'm going to propose we dump DisableWin32AcceptEx syntax entirely in 2.4, and instead use our new friendly syntax; AcceptFilter http ex-data (current acceptex, plus some data) AcceptFilter https ex (current acceptex, but no data) AcceptFilter http none(vanilla accept) Isn't AcceptFilter http ex the default now? Wouldn't : AcceptFilter http none (current acceptex, no data) AcceptFilter http data (current acceptex + data) AcceptFilter http no-ex (vanilla accept) be better? Just my 2 cents Does this sound like the right approach before I start hacking anything? Bill -- ~Jorge
Re: Pre-release test tarballs of httpd 1.3.40, 2.0.62 and 2.2.7 available
mod_perl on Windows 2.2.7 Using http://theoryx5.uwinnipeg.ca/ppms/ with ActivePerl 5.8.8.822 FAILS Rebuilding mod_perl with latest SVN snapshot 2.0.4-dev against 2.2.7 and use *only* the new generated mod_perl.so, it is working except from command line. Since this problem (bug 43534) is very sensitive to how Apache is started I don't know which is best: make a new patch for it, or just tell everyone they need to run Apache as a service if they want to use mod_perl. Test results: * Apache 2.2.7 started as a Windows Service WORKS OK * Apache 2.2.7 started from command-line httpd.exe FAILS - error.log has [Sat Jan 05 12:08:42 2008] [notice] Parent: child process exited with status 9 -- Restarting. * Apache 2.2.7 started from command-line START Apache 227 httpd.exe FAILS - error.log has [Sat Jan 05 12:09:03 2008] [notice] Parent: child process exited with status 9 -- Restarting. * Apache 2.2.7 started as single process from command-line httpd.exe -X WORKS OK Steffen http://www.apachelounge.com
Re: Pre-release test tarballs of httpd 1.3.40, 2.0.62 and 2.2.7 available
On 01/05/2008 07:04 PM, Nick Kew wrote: On Sat, 05 Jan 2008 12:38:58 +0100 Ruediger Pluem [EMAIL PROTECTED] wrote: Ok. Can you setup a tcpdump between proxy and server and between client and proxy? I guess the network traces would be very helpful in finding out where things are starting to get wrong. One testcase with its tcpdump at http://people.apache.org/~niq/2.2.7/ Thanks for this, but I think this is not sufficient: 1. It seems the dump is incomplete as I cannot see a 0 chunk at the end. 2. I would prefer the binary dump as it offers more possibilities to analyse it with wireshark. Sorry for being that demanding :-) Regards Rüdiger
Re: Pre-release test tarballs of httpd 1.3.40, 2.0.62 and 2.2.7 available
Den Friday 04 January 2008 21.00.46 skrev Jim Jagielski: Apache HTTP Server fans, The latest versions of all 3 variants of Apache HTTP Server (1.3.40, 2.0.62 and 2.2.7) have been tagged. The test tarballs are available for testing and feedback at the below location. Everyone is reminded that this does not constitute an official release of these tarballs yet; assuming these pass muster, the hope and intent is to release and announce early next week. All files in: http://httpd.apache.org/dev/dist/ 2.2.7 works fine for me and passes all tests in perl-framework (r609180) on Mandriva Linux Corporate Server 4.0, 2008.0 and Cooker. -- Regards // Oden Eriksson
Re: Pre-release test tarballs of httpd 1.3.40, 2.0.62 and 2.2.7 available
Steffen wrote: mod_perl on Windows 2.2.7 Using http://theoryx5.uwinnipeg.ca/ppms/ with ActivePerl 5.8.8.822 FAILS Rebuilding mod_perl with latest SVN snapshot 2.0.4-dev against 2.2.7 and use *only* the new generated mod_perl.so, it is working except from command line. Since this problem (bug 43534) is very sensitive to how Apache is started I don't know which is best: make a new patch for it, or just tell everyone they need to run Apache as a service if they want to use mod_perl. I'd be happy to see a fix; yes I consider 'as a console' to be a test environment, but I also consider it to be very useful and worth fixing. Even the hack to stop a console httpd by-pid is still in status waiting for a patch, as an Enhancement bug. So I won't say no to fixing. Test results: * Apache 2.2.7 started as a Windows Service WORKS OK Whew, cool. * Apache 2.2.7 started from command-line httpd.exe FAILS - error.log has [Sat Jan 05 12:08:42 2008] [notice] Parent: child process exited with status 9 -- Restarting. So we are looking why we arrived an exit(9) - it corresponds to none of the APEXIT_* codes. Certainly not APEXIT_CHILDINIT nor APEXIT_INIT which we would expect in the mpm. I can't find a single example in servers/ or modules/ which would lead to this result, which tells me is must be modperl or perl. * Apache 2.2.7 started as single process from command-line httpd.exe -X WORKS OK Now that's a little nutty. Would expect -X case to mirror the other command line case. Good clues. Bill
Re: Pre-release test tarballs of httpd 1.3.40, 2.0.62 and 2.2.7 available
On 01/05/2008 12:27 PM, Nick Kew wrote:
On Sat, 05 Jan 2008 12:11:07 +0100
Ruediger Pluem [EMAIL PROTECTED] wrote:
Can you please try if the following patch against the vanilla tar
ball fixes the problem?
Nope. Causes both test cases to give just one byte of response.
Sorry my first patch was bogus of course :-(. Please try the
following:
Back to square one, with 433 bytes of response.
(FWIW, I already tried moving the cleanup last night).
Ok, next round. I think that I ironed out various edge cases. One remains
(see XXX in get_chunk_line) but I guess this one could be addressed later.
So can you please test 2.2.7 vanilla + attached patch?
Regards
Rüdiger
Index: modules/http/http_filters.c
===
--- modules/http/http_filters.c (Revision 609114)
+++ modules/http/http_filters.c (Arbeitskopie)
@@ -68,8 +68,43 @@
BODY_CHUNK_PART
} state;
int eos_sent;
+char chunk_ln[30];
+char *pos;
} http_ctx_t;
+static apr_status_t get_chunk_line(http_ctx_t *ctx, int len)
+{
+/*
+ * Check if we do not overflow our chunksize / empty line buffer
+ * (ctx-chunk_ln). If we do the chunksize / empty line is bogus anyway so
+ * bail out in this case.
+ * XXX: Currently we are very limited in accepting chunk-extensions. If
+ * this is needed the chunk_ln buffer must be much larger or we must
+ * find a different way to discard them as we do not process them anyway.
+ */
+if ((ctx-pos - ctx-chunk_ln) + len sizeof(ctx-chunk_ln)) {
+ctx-pos += len;
+*(ctx-pos) = '\0';
+/*
+ * Check if we really got a full line. If yes the
+ * last char in the just read buffer must be LF.
+ * If not advance the buffer and return APR_EAGAIN.
+ * We do not start processing until we have the
+ * full line.
+ */
+if (ctx-pos[-1] != APR_ASCII_LF) {
+return APR_EAGAIN;
+}
+/*
+ * Line is complete. So reset ctx-pos for next round.
+ */
+ctx-pos = ctx-chunk_ln;
+return APR_SUCCESS;
+}
+return APR_ENOSPC;
+}
+
+
/* This is the HTTP_INPUT filter for HTTP requests and responses from
* proxied servers (mod_proxy). It handles chunked and content-length
* bodies. This can only be inserted/used after the headers
@@ -96,6 +131,7 @@
ctx-remaining = 0;
ctx-limit_used = 0;
ctx-eos_sent = 0;
+ctx-pos = ctx-chunk_ln;
/* LimitRequestBody does not apply to proxied responses.
* Consider implementing this check in its own filter.
@@ -227,9 +263,8 @@
/* We can't read the chunk until after sending 100 if required. */
if (ctx-state == BODY_CHUNK) {
-char line[30];
apr_bucket_brigade *bb;
-apr_size_t len = 30;
+apr_size_t len = sizeof(ctx-chunk_ln) - (ctx-pos - ctx-chunk_ln);
apr_off_t brigade_length;
bb = apr_brigade_create(f-r-pool, f-c-bucket_alloc);
@@ -256,9 +291,16 @@
rv = APR_ENOSPC;
}
if (rv == APR_SUCCESS) {
-rv = apr_brigade_flatten(bb, line, len);
+rv = apr_brigade_flatten(bb, ctx-pos, len);
if (rv == APR_SUCCESS) {
-ctx-remaining = get_chunk_size(line);
+rv = get_chunk_line(ctx, len);
+if (APR_STATUS_IS_EAGAIN(rv)) {
+apr_brigade_cleanup(bb);
+return rv;
+}
+if (rv == APR_SUCCESS) {
+ctx-remaining = get_chunk_size(ctx-chunk_ln);
+}
}
}
}
@@ -308,9 +350,9 @@
case BODY_CHUNK:
case BODY_CHUNK_PART:
{
-char line[30];
apr_bucket_brigade *bb;
-apr_size_t len = 30;
+apr_size_t len = sizeof(ctx-chunk_ln)
+ - (ctx-pos - ctx-chunk_ln);
apr_status_t http_error = HTTP_REQUEST_ENTITY_TOO_LARGE;
bb = apr_brigade_create(f-r-pool, f-c-bucket_alloc);
@@ -319,11 +361,21 @@
if (ctx-state == BODY_CHUNK) {
rv = ap_get_brigade(f-next, bb, AP_MODE_GETLINE,
block, 0);
-apr_brigade_cleanup(bb);
if (block == APR_NONBLOCK_READ
-(APR_STATUS_IS_EAGAIN(rv))) {
+( (rv == APR_SUCCESS APR_BRIGADE_EMPTY(bb)) ||
+ (APR_STATUS_IS_EAGAIN(rv)) )) {
return APR_EAGAIN;
}
+rv = apr_brigade_flatten(bb, ctx-pos, len
Re: Pre-release test tarballs of httpd 1.3.40, 2.0.62 and 2.2.7 available
On Sat, 05 Jan 2008 20:28:33 +0100 Ruediger Pluem [EMAIL PROTECTED] wrote: On 01/05/2008 07:04 PM, Nick Kew wrote: On Sat, 05 Jan 2008 12:38:58 +0100 Ruediger Pluem [EMAIL PROTECTED] wrote: Ok. Can you setup a tcpdump between proxy and server and between client and proxy? I guess the network traces would be very helpful in finding out where things are starting to get wrong. One testcase with its tcpdump at http://people.apache.org/~niq/2.2.7/ Thanks for this, but I think this is not sufficient: 1. It seems the dump is incomplete as I cannot see a 0 chunk at the end. 2. I would prefer the binary dump as it offers more possibilities to analyse it with wireshark. Sorry for being that demanding :-) Do you mean as in tcpdump -x? I've uploaded a pair of dumps (one of client-proxy, the other of proxy-server) at the same location. The first dump looked to me like it stopped sending to the client after a chunk: 1\r\n 1\r\n where the second (data value) 1 was the last byte read in a bucket (the \r\n being the start of another bucket). Neither the 1 nor anything later was sent to the client. If I can reproduce that in gdb, it should be simple to diagnose; otherwise we have to figure it out. -- Nick Kew Application Development with Apache - the Apache Modules Book http://www.apachetutor.org/
Re: Pre-release test tarballs of httpd 1.3.40, 2.0.62 and 2.2.7 available
On sön, 2008-01-06 at 01:20 +, Nick Kew wrote: Do you mean as in tcpdump -x? I've uploaded a pair of dumps (one of client-proxy, the other of proxy-server) at the same location. tcpdump -p -i any -s 1600 -w traffic.pcap port 80 Regards Henrik
Re: Pre-release test tarballs of httpd 1.3.40, 2.0.62 and 2.2.7 available
On Jan 5, 2008, at 5:20 PM, Nick Kew wrote: Do you mean as in tcpdump -x? I've uploaded a pair of dumps (one of client-proxy, the other of proxy-server) at the same location. The best way to get a tcpdump file for analysing in Wireshark, do: tcpdump -i lo0 (or whatever) -s 0 -w your.output.file.dump The -s 0 causes tcpdump to capture the entire packets and not cut them off. Older versions don't know about the 0 value, just use a value larger than the MTU on the interface you're capturing like Henrik suggests. This does not dump anything to your stdout, everything goes to the file specified in -w. If your network is quiet, don't worry about filtering since Wireshark does that quite well. S. -- Sander Temme [EMAIL PROTECTED] PGP FP: 51B4 8727 466A 0BC3 69F4 B7B8 B2BE BC40 1529 24AF
Re: Pre-release test tarballs of httpd 1.3.40, 2.0.62 and 2.2.7 available
On Sat, 5 Jan 2008 00:07:42 + Nick Kew [EMAIL PROTECTED] wrote: The latest versions of all 3 variants of Apache HTTP Server (1.3.40, 2.0.62 and 2.2.7) have been tagged. Regression: fails to proxy massively chunked responses. Since wrowe asked me in IRC, I tested 2.0.62. It doesn't have the chunked response bug. -- Nick Kew Application Development with Apache - the Apache Modules Book http://www.apachetutor.org/
Re: Pre-release test tarballs of httpd 1.3.40, 2.0.62 and 2.2.7 available
On Fri, 4 Jan 2008 15:00:46 -0500 Jim Jagielski [EMAIL PROTECTED] wrote: Apache HTTP Server fans, The latest versions of all 3 variants of Apache HTTP Server (1.3.40, 2.0.62 and 2.2.7) have been tagged. These are not updated in 2.2: manual/mod/quickreference.html.ko.euc-kr manual/mod/directives.html.de manual/mod/directives.html.es manual/mod/directives.html.ru.koi8-r manual/mod/quickreference.html.ru.koi8-r manual/mod/quickreference.html.de manual/mod/quickreference.html.es manual/mod/directives.html.ko.euc-kr manual/convenience.map and in 2.0: manual/mod/quickreference.html.ko.euc-kr manual/mod/quickreference.html.ru.koi8-r manual/mod/directives.html.ja.euc-jp manual/mod/quickreference.html.ja.euc-jp manual/mod/quickreference.html.de manual/mod/quickreference.html.es manual/mod/directives.html.de manual/mod/directives.html.es manual/mod/directives.html.ko.euc-kr manual/mod/directives.html.ru.koi8-r ./build.sh is not enough. ./build.sh all is needed for 2.0, and ./build.sh all convmap for 2.2.
Re: Pre-release test tarballs of httpd 1.3.40, 2.0.62 and 2.2.7 available
Takashi Sato wrote: On Fri, 4 Jan 2008 15:00:46 -0500 Jim Jagielski [EMAIL PROTECTED] wrote: Apache HTTP Server fans, The latest versions of all 3 variants of Apache HTTP Server (1.3.40, 2.0.62 and 2.2.7) have been tagged. ./build.sh is not enough. ./build.sh all is needed for 2.0, and ./build.sh all convmap for 2.2. Sounds like a good thing to add to the RM process document, since it's pretty clear that isn't happening on regular xml commit-regen-commit.
Re: Pre-release test tarballs of httpd 1.3.40, 2.0.62 and 2.2.7 available
On Jan 4, 2008 12:00 PM, Jim Jagielski [EMAIL PROTECTED] wrote: http://httpd.apache.org/dev/dist/ +1 for 2.2.7. Tested on Mac OS 10.5.1 (aka 9.1.0) with APR/APR-util 1.2.12. Some caveats though on Mac OS - I have a hunch they are more about the test suite than anything else. Configure options: ./configure --enable-modules=most --enable-ssl --enable-cache --enable-proxy --enable-disk-cache With httpd-test, the built-in Perl distro yields these failures: Failed TestStat Wstat Total Fail Failed List of Failed --- t/security/CVE-2005-2700.t21 50.00% 1 t/ssl/basicauth.t 32 66.67% 2-3 t/ssl/env.t 30 23 76.67% 1-8 16-30 t/ssl/extlookup.t 22 100.00% 1-2 t/ssl/fakeauth.t 32 66.67% 2-3 t/ssl/headers.t 33 100.00% 1-3 t/ssl/pr12355.t 108 80.00% 1-8 t/ssl/pr43738.t 44 100.00% 1-4 t/ssl/proxy.t 172 113 65.70% 60-172 t/ssl/require.t 52 40.00% 2 5 t/ssl/v2.t11 100.00% 1 t/ssl/varlookup.t72 72 100.00% 1-72 t/ssl/verify.t31 33.33% 2 8 tests and 18 subtests skipped. Failed 13/80 test scripts, 83.75% okay. 234/2824 subtests failed, 91.71% okay. [ error] error running tests (please examine t/logs/error_log) Looking deeper, I replaced Perl with current MacPort perl install and I now get: (The key bit seems it upgrades libwww-perl/5.805 to libwww-perl/5.808.) Failed Test Stat Wstat Total Fail Failed List of Failed --- t/ssl/basicauth.t32 66.67% 2-3 t/ssl/env.t 30 15 50.00% 16-30 t/ssl/extlookup.t22 100.00% 1-2 t/ssl/fakeauth.t 32 66.67% 2-3 t/ssl/pr12355.t 108 80.00% 1-8 t/ssl/pr43738.t 44 100.00% 1-4 t/ssl/require.t 52 40.00% 2 5 t/ssl/varlookup.t 72 72 100.00% 1-72 t/ssl/verify.t 31 33.33% 2 8 tests and 18 subtests skipped. Failed 9/80 test scripts, 88.75% okay. 108/2824 subtests failed, 96.18% okay. [ error] error running tests (please examine t/logs/error_log) Looking at the error and access logs, httpd is returning success and failures where appropriate, but LWP is somehow dying. So, I'll cast my +1 even with these SSL failures as merely changing the LWP version made some of these go away. If someone wants to dig more and see what's up, that'd be appreciated too...but I wouldn't block the release on this. -- justin
Re: Pre-release test tarballs of httpd 1.3.40, 2.0.62 and 2.2.7 available
Jorge Schrauwen wrote: I'm getting a whole lot of errors with vs 2008 and 2005 on windows: Apr seems to be to blame: --- Error 1 error C2079: 'mip' uses undefined struct 'group_source_req' s:\source\x86\httpd-2.2\srclib\apr\network_io\unix\multicast.c 140 apr Next time, try out the MS SDK beta and give them a bug report before it's too late :) Not APR to blame, it's the MS SDK headers. http://issues.apache.org/bugzilla/show_bug.cgi?id=40398 is the trivial fix for their bogosity. Bill
Re: Pre-release test tarballs of httpd 1.3.40, 2.0.62 and 2.2.7 available
I'm getting a whole lot of errors with vs 2008 and 2005 on windows: Apr seems to be to blame: --- Error 1 error C2079: 'mip' uses undefined struct 'group_source_req' s:\source\x86\httpd-2.2\srclib\apr\network_io\unix\multicast.c 140 apr Error 2 error C2224: left of '.gsr_interface' must have struct/union types:\source\x86\httpd-2.2\srclib\apr\network_io\unix\multicast.c 171 apr Error 3 error C2224: left of '.gsr_group' must have struct/union types:\source\x86\httpd-2.2\srclib\apr\network_io\unix\multicast.c 172 apr Error 4 error C2224: left of '.gsr_group' must have struct/union types:\source\x86\httpd-2.2\srclib\apr\network_io\unix\multicast.c 172 apr Error 5 error C2168: 'memcpy' : too few actual parameters for intrinsic function s:\source\x86\httpd-2.2\srclib\apr\network_io\unix\multicast.c 172 apr Error 6 error C2224: left of '.gsr_source' must have struct/union types:\source\x86\httpd-2.2\srclib\apr\network_io\unix\multicast.c 173 apr Error 7 error C2224: left of '.gsr_source' must have struct/union types:\source\x86\httpd-2.2\srclib\apr\network_io\unix\multicast.c 173 apr --- Anybody else seeing this? wrowe? On Jan 4, 2008 11:03 PM, Justin Erenkrantz [EMAIL PROTECTED] wrote: On Jan 4, 2008 12:00 PM, Jim Jagielski [EMAIL PROTECTED] wrote: http://httpd.apache.org/dev/dist/ +1 for 2.2.7. Tested on Mac OS 10.5.1 (aka 9.1.0) with APR/APR-util 1.2.12. Some caveats though on Mac OS - I have a hunch they are more about the test suite than anything else. Configure options: ./configure --enable-modules=most --enable-ssl --enable-cache --enable-proxy --enable-disk-cache With httpd-test, the built-in Perl distro yields these failures: Failed TestStat Wstat Total Fail Failed List of Failed --- t/security/CVE-2005-2700.t21 50.00% 1 t/ssl/basicauth.t 32 66.67% 2-3 t/ssl/env.t 30 23 76.67% 1-8 16-30 t/ssl/extlookup.t 22 100.00% 1-2 t/ssl/fakeauth.t 32 66.67% 2-3 t/ssl/headers.t 33 100.00% 1-3 t/ssl/pr12355.t 108 80.00% 1-8 t/ssl/pr43738.t 44 100.00% 1-4 t/ssl/proxy.t 172 113 65.70% 60-172 t/ssl/require.t 52 40.00% 2 5 t/ssl/v2.t11 100.00% 1 t/ssl/varlookup.t72 72 100.00% 1-72 t/ssl/verify.t31 33.33% 2 8 tests and 18 subtests skipped. Failed 13/80 test scripts, 83.75% okay. 234/2824 subtests failed, 91.71% okay. [ error] error running tests (please examine t/logs/error_log) Looking deeper, I replaced Perl with current MacPort perl install and I now get: (The key bit seems it upgrades libwww-perl/5.805 to libwww-perl/5.808.) Failed Test Stat Wstat Total Fail Failed List of Failed --- t/ssl/basicauth.t32 66.67% 2-3 t/ssl/env.t 30 15 50.00% 16-30 t/ssl/extlookup.t22 100.00% 1-2 t/ssl/fakeauth.t 32 66.67% 2-3 t/ssl/pr12355.t 108 80.00% 1-8 t/ssl/pr43738.t 44 100.00% 1-4 t/ssl/require.t 52 40.00% 2 5 t/ssl/varlookup.t 72 72 100.00% 1-72 t/ssl/verify.t 31 33.33% 2 8 tests and 18 subtests skipped. Failed 9/80 test scripts, 88.75% okay. 108/2824 subtests failed, 96.18% okay. [ error] error running tests (please examine t/logs/error_log) Looking at the error and access logs, httpd is returning success and failures where appropriate, but LWP is somehow dying. So, I'll cast my +1 even with these SSL failures as merely changing the LWP version made some of these go away. If someone wants to dig more and see what's up, that'd be appreciated too...but I wouldn't block the release on this. -- justin -- ~Jorge
Re: Pre-release test tarballs of httpd 1.3.40, 2.0.62 and 2.2.7 available
On 1/4/2008 at 1:00 PM, in message [EMAIL PROTECTED], Jim Jagielski [EMAIL PROTECTED] wrote: Apache HTTP Server fans, The latest versions of all 3 variants of Apache HTTP Server (1.3.40, 2.0.62 and 2.2.7) have been tagged. The test tarballs are available for testing and feedback at the below location. Everyone is reminded that this does not constitute an official release of these tarballs yet; assuming these pass muster, the hope and intent is to release and announce early next week. All files in: http://httpd.apache.org/dev/dist/ All 3 are looking good on NetWare Brad
Re: Pre-release test tarballs of httpd 1.3.40, 2.0.62 and 2.2.7 available
Phew whit some help I got it all sorted out. Everything seems to be running and functioning at first sight. Atleast my config because I couln't get the test framework to run. Although compiling from a converted source was a pain +1 on this if the final win32-src.zip compiles file after extraction. Jorge On Jan 4, 2008 11:55 PM, William A. Rowe, Jr. [EMAIL PROTECTED] wrote: Jorge Schrauwen wrote: I'm getting a whole lot of errors with vs 2008 and 2005 on windows: Apr seems to be to blame: --- Error 1 error C2079: 'mip' uses undefined struct 'group_source_req' s:\source\x86\httpd-2.2\srclib\apr\network_io\unix\multicast.c 140 apr Next time, try out the MS SDK beta and give them a bug report before it's too late :) Not APR to blame, it's the MS SDK headers. http://issues.apache.org/bugzilla/show_bug.cgi?id=40398 is the trivial fix for their bogosity. Bill -- ~Jorge
Re: Pre-release test tarballs of httpd 1.3.40, 2.0.62 and 2.2.7 available
On Fri, 4 Jan 2008 15:00:46 -0500 Jim Jagielski [EMAIL PROTECTED] wrote: Apache HTTP Server fans, The latest versions of all 3 variants of Apache HTTP Server (1.3.40, 2.0.62 and 2.2.7) have been tagged. Regression: fails to proxy massively chunked responses. I've just run it on a matrix of two versions: 2.2.7 - clean build 2.2.6+ - 2.2.6 with my proxy fixes I tried httpd from each with modules from each, and got: bin/ modules/ outcome 2.2.6+2.2.6+ success 2.2.6+2.2.7success 2.2.7 2.2.6+ failure 2.2.7 2.2.7failure So it looks like something in core. More detail as and when I figure it out. -- Nick Kew Application Development with Apache - the Apache Modules Book http://www.apachetutor.org/
Re: Pre-release test tarballs of httpd 1.3.40, 2.0.62 and 2.2.7 available
On Sat, 5 Jan 2008 00:07:42 + Nick Kew [EMAIL PROTECTED] wrote: Regression: fails to proxy massively chunked responses. OK, it works correctly if I revert r602679 (no other changes). Investigating further. -- Nick Kew Application Development with Apache - the Apache Modules Book http://www.apachetutor.org/
Re: Pre-release test tarballs of httpd 1.3.40, 2.0.62 and 2.2.7 available
On Fri, Jan 04, 2008 at 03:00:46PM -0500, Jim Jagielski wrote: Apache HTTP Server fans, The latest versions of all 3 variants of Apache HTTP Server (1.3.40, 2.0.62 and 2.2.7) have been tagged. The test tarballs are available for testing and feedback at the below location. Everyone is reminded that this does not constitute an official release of these tarballs yet; assuming these pass muster, the hope and intent is to release and announce early next week. All files in: http://httpd.apache.org/dev/dist/ FAILURE!! FAILURE!! FAILURE!! Making all in support /usr/source/httpd-2.0.62/srclib/apr/libtool --silent --mode=link /usr/bin/gcc -Wmissing-prototypes -Wstrict-prototypes -Wmissing-declarations -Wall -DDEBUG -g -O9 -march=i686 -DAP_DEBUG -DAP_HAVE_DESIGNATED_INITIALIZER -I/usr/source/httpd-2.0.62/srclib/apr/include -I/usr/source/httpd-2.0.62/srclib/apr-util/include -I/usr/source/httpd-2.0.62/srclib/apr-util/xml/expat/lib -I. -I/usr/source/httpd-2.0.62/os/unix -I/usr/source/httpd-2.0.62/server/mpm/prefork -I/usr/source/httpd-2.0.62/modules/http -I/usr/source/httpd-2.0.62/modules/filters -I/usr/source/httpd-2.0.62/modules/proxy -I/usr/source/httpd-2.0.62/include -I/usr/source/httpd-2.0.62/modules/generators -I/usr/source/httpd-2.0.62/server -I/usr/contrib/include/openssl -I/usr/contrib/include -I/usr/source/httpd-2.0.62/modules/dav/main -export-dynamic -L/usr/source/httpd-2.0.62/srclib/apr-util/xml/expat/lib -L/usr/contrib/lib -o ab -static ab.lo -lz /usr/source/httpd-2.0.62/srclib/pcre/libpcre.la /usr/source/httpd-2.0.62/srclib/apr-util/libaprutil-0.la /usr/source/httpd-2.0.62/srclib/apr-util/xml/expat/lib/libexpat.la -liconv /usr/source/httpd-2.0.62/srclib/apr/libapr-0.la -lm -ldl -lsslc ld: cannot find -lsslc libsslc ??? What the heck? libsslc.a is a proprietary code which very few OSes uses. Please fix. Also, someone is overloading mu 2.0.61 server with bogus requests. -- Member - Liberal International This is [EMAIL PROTECTED] Ici [EMAIL PROTECTED] God, Queen and country! Beware Anti-Christ rising! Born 29 Jan 1969 Redhill Surrey England -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Re: Pre-release test tarballs of httpd 1.3.40, 2.0.62 and 2.2.7 available
The Doctor wrote: libsslc ??? What the heck? libsslc.a is a proprietary code which very few OSes uses. Yup - and those that do, httpd will pick up --with-sslc. Your config.log might be revealing.
Re: Pre-release test tarballs of httpd 1.3.40, 2.0.62 and 2.2.7 available
William A. Rowe, Jr. wrote: The Doctor wrote: libsslc ??? What the heck? libsslc.a is a proprietary code which very few OSes uses. Yup - and those that do, httpd will pick up --with-sslc. Your config.log might be revealing. Don't bother with your config.log; $ap_ssltk_type of openssl wasn't introduced until rev 2.2.0, apparently in my last patch-merge I missed the ./buildconf to my ./configure, and never caught this locally. In fact, it appears all the 6 year old sslc work didn't land in the tree until the 2.1-dev branch and was never backported. Very sorry about this, the patch is at http://people.apache.org/~wrowe/fix-no-sslc-2.0.patch
Re: time for 1.3.40 and 2.2.7 ?
On 01/03/2008 12:21 AM, Ruediger Pluem wrote: But there was a problem with the _default_ setting for a virtual host. I am not sure so far if this is my config or if there is something else going wrong on Solaris 10. I will investigate tomorrow. This is a bug in Solaris 10. See also http://mail.opensolaris.org/pipermail/networking-discuss/2007-September/017120.html http://bugs.opensolaris.org/view_bug.do?bug_id=4944187 There might be even a patch for it, but I do not have sunsolve credentials at hand: http://sunsolve.sun.com/search/document.do?assetkey=1-1-4944187-1 Regards Rüdiger
Re: time for 1.3.40 and 2.2.7 ?
Ruediger Pluem schrieb: On 01/03/2008 12:21 AM, Ruediger Pluem wrote: But there was a problem with the _default_ setting for a virtual host. I am not sure so far if this is my config or if there is something else going wrong on Solaris 10. I will investigate tomorrow. This is a bug in Solaris 10. See also http://mail.opensolaris.org/pipermail/networking-discuss/2007-September/017120.html http://bugs.opensolaris.org/view_bug.do?bug_id=4944187 There might be even a patch for it, but I do not have sunsolve credentials at hand: http://sunsolve.sun.com/search/document.do?assetkey=1-1-4944187-1 Not there's no other info in this patch description document and sunsolve doesn't find a patch for it even with credentials. The bug has been last updated on December 18 this year, although it goes back to 2003. It looks like they are now producing a patch. The other links above already include the Sun suggested workarounds, either disable nscd (bad) or include DNS in /etc/nsswitch.conf. Regards Rüdiger Gutes Neues! Rainer
Re: time for 1.3.40 and 2.2.7 ?
Rainer Jung schrieb: been last updated on December 18 this year, although it goes back to this - last (it's already next year) :)
Re: time for 1.3.40 and 2.2.7 ?
Now that I am really back, I'd like to reboot the intent to TR all three. 2.2 has a current show-stopper however, with a veto upon the patch by Nick.
