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: svn commit: r609549 - /httpd/httpd/trunk/modules/http/http_filters.c
Type of HTTP error code is int, isn't it?
r609549:
+static apr_status_t bail_out_on_error(http_ctx_t *ctx,
+ ap_filter_t *f,
+ apr_status_t http_error)
+{
r609550:
+apr_status_t http_error = HTTP_REQUEST_ENTITY_TOO_LARGE;
Re: httpd trunk - How to get info that ap_requires used to return
My immediate aim is to test Isaac's UDP support patch with mod_perl - I
want to make a case for apache as a viable alternative for our service
platform and udp support is essential. If I can get the mod_perl test suite
to pass I increase the credibility of my proposal.
The mod_perl tests that use ap_requires are quite simple - the Require
lines are retrieved via ap_requires and then the values compared against
data in the current request. Example:
In the conf:
Require user goo bar
Require group bar tar
In the test code:
# extract just the requirement entries
my %require =
map { my ($k, $v) = split /\s+/, $_-{requirement}, 2; ($k, $v||'') }
@{ $r-requires };
debug \%require;
return Apache2::Const::SERVER_ERROR unless $require{user} eq $users;
return Apache2::Const::SERVER_ERROR unless $require{group} eq $groups;
$require{user} should be 'goo bar'
$require{group} should be 'bar tar'
I don't yet have much detailed knowledge of the httpd code - my naive
interpretation is that ap_requires returned a list of require_line structs
where the 'requirement' field is
everything after the 'Require' in the config line. If there was some
way to get a list of the Require statements in the conf file it would
be an easy matter to re-jig the test code.
I suppose I could parse the config file directly (e.g. with Config::General )
to get the Require lines - but I would prefer to use any in-built httpd
support if possible.
From my naive perspective I'd offer that per-directory queries for
configuration
information such as all Require statements are useful things to have.
I intend no criticism of the re-design.
Regards,
Rolf
Re: svn commit: r609549 - /httpd/httpd/trunk/modules/http/http_filters.c
On 01/07/2008 12:41 PM, Takashi Sato wrote: Type of HTTP error code is int, isn't it? Nice catch. Fixed in r609609. Regards Rüdiger
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: httpd trunk - How to get info that ap_requires used to return
On 1/7/2008 at 4:56 AM, in message
[EMAIL PROTECTED], Rolf Banting
[EMAIL PROTECTED] wrote:
My immediate aim is to test Isaac's UDP support patch with mod_perl - I
want to make a case for apache as a viable alternative for our service
platform and udp support is essential. If I can get the mod_perl test suite
to pass I increase the credibility of my proposal.
The mod_perl tests that use ap_requires are quite simple - the Require
lines are retrieved via ap_requires and then the values compared against
data in the current request. Example:
In the conf:
Require user goo bar
Require group bar tar
In the test code:
# extract just the requirement entries
my %require =
map { my ($k, $v) = split /\s+/, $_-{requirement}, 2; ($k, $v||'') }
@{ $r-requires };
debug \%require;
return Apache2::Const::SERVER_ERROR unless $require{user} eq $users;
return Apache2::Const::SERVER_ERROR unless $require{group} eq $groups;
$require{user} should be 'goo bar'
$require{group} should be 'bar tar'
I don't yet have much detailed knowledge of the httpd code - my naive
interpretation is that ap_requires returned a list of require_line structs
where the 'requirement' field is
everything after the 'Require' in the config line. If there was some
way to get a list of the Require statements in the conf file it would
be an easy matter to re-jig the test code.
I suppose I could parse the config file directly (e.g. with Config::General
)
to get the Require lines - but I would prefer to use any in-built httpd
support if possible.
From my naive perspective I'd offer that per-directory queries for
configuration
information such as all Require statements are useful things to have.
The problem is that the Require statements are no longer stored as a list of
require_line structs so retrieving them as such isn't possible. The Require
statements are added to a logic tree as they are read from the configuration
and then whenever authorization is done for that Directory, the logic tree is
traversed and a result is returned. Obviously if there is only a single
Require statement in the Directory, the logic tree would be very simple, but
this isn't something that you can count on. The authorization logic could be
anything. As far as the configuration file is concerned, it could look like
anything from
Require User goo bar
Require Group bar tar
which would be interpreted as:
if (User == 'goo') || (User == 'bar') || (Group == 'bar') || (Group == 'tar')
then
allow
else
deny
to:
Require User goo
SatisfyAll
Require Group foo
SatisfyOne
Require User bar
Require Group tar
/SatisfyOne
/SatisfyAll
which is interpreted as:
If (user == 'goo') || (group == 'foo' (User == 'bar' || Group == 'tar'))
then
Allow
else
Deny
It appears that your test script doesn't really care about the authorization
result but rather if a Require statement simply exists with a given value. At
this point there isn't a way to get that information through an API. I guess
an API could be added that given a specific value would traverse the logic tree
to validate that a matching Require statement exists. But outside of the Perl
test, I'm not sure what usefulness an API like that would have.
Brad
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
Output filters in subrequests created by mod_actions (httpd 2.2.x)
Hi! I hope this wasn't already discussed previously (I didn't find anything in the archives, but maybe I overlooked something), if so, sorry for the noise. I recently stumbled upon the following behaviour of Apache (2.2.x, though it will probably apply to the developement branch as well) which I found to be quite odd at first. In order to explain better, I created a very simple test case: /demo/ contains the following files: .htaccess: - Options +ExecCGI +Includes AddOutputFilter INCLUDES .demo AddHandler cgi-script .pl AddHandler demo .demo Action demo /demo/test.pl Files test2.pl SetOutputFilter INCLUDES /Files - test.pl and test2.pl (both executable): - #!/usr/bin/perl use strict; use warnings; print Content-Type: text/plain\n\n; print '!--#include virtual=/demo/test.txt--'; - test.txt: - This is a test! - test.demo: - Empty - If I call /demo/test.pl, my browser will display the text !--#include virtual=/demo/test.txt-- - which is fine, because there are no output filters defined for test.pl. If I call /demo/test2.pl, my browser will display the text This is a test! - which is fine too, because there's an explicit output filter for test2.pl. If I call /demo/test.demo, my browser will display the text !--#include virtual=/demo/test.txt-- - which - er - is not exactly what I intended. If I change the .htaccess to Action demo /demo/test2.pl and call /demo/test.demo, my browser will display the text This is a test! - which is fine. My basic problem is that the output filters set for the original file that was called are not copied when mod_actions does an internal subrequest to execute the action. The culprit is the function internal_internal_redirect in server/http_request.c which only copies the protocol filters but not all the input filters: new-proto_output_filters = r-proto_output_filters; new-proto_input_filters = r-proto_input_filters; new-output_filters = new-proto_output_filters; new-input_filters = new-proto_input_filters; Which of course is fine by itself because otherwise this could cause quite some headaches in all of the other use cases of internal redirects (think, for example, mod_rewrite). Ok, a CGI script generating a SSI directive is not the best example for a useful use case. But take a mod_deflate, i.e. replace INCLUDES with DEFLATE in the above example. That's an extremly useful output filter. The problem is that it won't work if an internal redirect via Action occurs if it's set only on the file types that are assigned to action. To provide a useful example, have a look at PHP installations: You can either install it as an Apache Module (mod_php) or as CGI/FastCGI in which case you'd use Action. If you install it as a module, AddOutputFilter DEFLATE .php works just as expected - but if you install it as CGI/FastCGI, it won't. Of course, you could make sure that the filter is added to the CGI wrapper of PHP itself (i.e. the target of the Action line) but this is a) counter-intuitive and b) won't account for configurations where you only want to activate it for certain subdirectories or similar. Of course, this is all work-aroundable by defining multiple actions with the same target but that makes the configuration unecessarily complicated and well - counter-intuitive. This applies to any other case where you'd use Action as well, PHP is just an example (albeit probably a very prominent one). This could be addressed by altering the ap_internal_redirect_handler function to add the normal output filters after calling internal_internal_redirect. I grepped the httpd source and found 4 occurrences where the function is called: In mod_actions which is the case I described and in mod_asis, mod_cgi and mod_cgid which is used to do an internal redirect if a Location: /... header was set by the CGI script. I haven't looked at third-party modules so I don't know how it's used there. But in all four cases where this occurs inside httpd I don't see a problem in performing this change. Any thoughts on this? Regards, Christian
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
