You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Paul Querna <ch...@force-elite.com> on 2005/06/17 09:40:50 UTC
2.1.5 available for testing
Please test and vote on releasing 2.1.5 as -alpha.
Available at:
http://httpd.apache.org/dev/dist/
(might take up to 2 hours for the files to appear, due to the rsync delay)
MD5 (httpd-2.1.5-alpha.tar.Z) = f9dea893723fe7ddb8e9c5a4225a276b
MD5 (httpd-2.1.5-alpha.tar.bz2) = 8ec926f27c2768c7cbd24f42fa22108a
MD5 (httpd-2.1.5-alpha.tar.gz) = 7fdc3d61deb72b3815e137bdae282f0e
Thanks,
Paul
Re: 2.1.5 available for testing
Posted by Rici Lake <ri...@ricilake.net>.
On 20-Jun-05, at 8:55 AM, jean-frederic clere wrote:
>> and GET with content-length.
>
> I think that is not forbidden in the rfc...
> But what about returning HTTP_BAD_REQUEST if Content-Length is not 0?
I don't believe rfc2616 forbids GET requests to have entity-bodies, so
it could be argued that rejecting such a request a priori is
non-conformant. Obviously, if the handler for the request does not
expect an entity-body, which would be the case in all the handlers I've
seen, the request ought to be rejected.
On the other hand, from a pragmatic point of view, proxying GETs with
entity-bodies to unknown downstream servers may cause them to
misbehave. So there is a good argument for mod_proxy to reject such
requests unless specifically instructed otherwise.
Re: 2.1.5 available for testing
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 11:13 AM 6/20/2005, jean-frederic clere wrote:
>William A. Rowe, Jr. wrote:
>>At 08:55 AM 6/20/2005, jean-frederic clere wrote:
>>
>>>jean-frederic clere wrote:
>>
>>>>and GET with content-length.
>>>
>>>I think that is not forbidden in the rfc...
>>>But what about returning HTTP_BAD_REQUEST if Content-Length is not 0?
>>
>>See section 4.3 of RFC 2616.
>>Content-Length: 0 signals a message body of 0 bytes, not the
>>absence of a message body. It shouldn't be treated differently
>>from Content-Length: n.
>
>OK, HTTP_BAD_REQUEST if C-L is present in GET?
I don't think so; 9.3 does not exclude it. Any extended XML
resource description could require it.
The only method which prohibits message bodies is TRACE. I believe
this is one case where we need to absolutely follow the letter of
RFC2616, and expect the backend to do the same.
I would not object to some additional flag in the <Proxy > block
which restricts message bodies in various ways, as an optional
feature as opposed to being 'stricter than the RFC'.
The changes to T-E and C-L will undoubtedly break some home brew
request submission code. At least when things break, let's have
the RFC to fall back on, that we 'did the right thing' with respect
to request bodies.
Bill
Re: 2.1.5 available for testing
Posted by jean-frederic clere <jf...@fujitsu-siemens.com>.
William A. Rowe, Jr. wrote:
> At 08:55 AM 6/20/2005, jean-frederic clere wrote:
>
>>jean-frederic clere wrote:
>
>
>>>and GET with content-length.
>>
>>I think that is not forbidden in the rfc...
>>But what about returning HTTP_BAD_REQUEST if Content-Length is not 0?
>
>
> See section 4.3 of RFC 2616.
>
> Content-Length: 0 signals a message body of 0 bytes, not the
> absence of a message body. It shouldn't be treated differently
> from Content-Length: n.
OK, HTTP_BAD_REQUEST if C-L is present in GET?
>
> Bill
>
>
Re: 2.1.5 available for testing
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 08:55 AM 6/20/2005, jean-frederic clere wrote:
>jean-frederic clere wrote:
>>and GET with content-length.
>
>I think that is not forbidden in the rfc...
>But what about returning HTTP_BAD_REQUEST if Content-Length is not 0?
See section 4.3 of RFC 2616.
Content-Length: 0 signals a message body of 0 bytes, not the
absence of a message body. It shouldn't be treated differently
from Content-Length: n.
Bill
Re: 2.1.5 available for testing
Posted by jean-frederic clere <jf...@fujitsu-siemens.com>.
jean-frederic clere wrote:
> William A. Rowe, Jr. wrote:
>
>> At 03:07 PM 6/17/2005, William A. Rowe, Jr. wrote:
>>
>>> -1 on Win32, caddr_t isn't sufficiently portable (fix committed).
>>
>>
>>
>> Correction, -1 on all platforms.
>>
>> jfclere just committed a significant patch to the T-E override
>> of the C-L passed to us, as part of the Watchfire vulnerability
>> fixes. It seems very irresponsible to release any flavor (alpha,
>> beta, nadda) with a known vuln, when we've committed a fix already.
>
>
> I still need some more time to check POST with 2 different
> content-lengths
HTTP_BAD_REQUEST for this one.
> and GET with content-length.
I think that is not forbidden in the rfc...
But what about returning HTTP_BAD_REQUEST if Content-Length is not 0?
>
>>
>> Also, possibly across platforms is a fault in ssl_engine_init,
>> where the host->protocol is still NULL, and we are trying to
>> strcmp it to 'https'. I spent part of my weekend trying to
>> grok what change has broken this, but strcmp to NULL is popping
>> a segfault. Not worthy of rejecting 2.1.5 on it's own, this is
>> still a minor irritation. FYI - mod_ssl was loaded without SSL
>> being defined, so no ssl host actually exists.
>>
>> Bill
>>
>>
>
>
Re: 2.1.5 available for testing
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 11:18 AM 6/20/2005, jean-frederic clere wrote:
>>>Correct, I have a new additional patch that prevent multiples C-L headers.
>>
>>It isn't needed for reasons I pointed out on the dev list.
>>Content-Encoding: x followed by Content-Encoding: y becomes
>>Content-Encoding: x, y - this is rejected later in the process
>>due to the non-numeric text ", ".
>
>But the patch stops the processing of the bad request earlier.
from RFC 2616 4.2 Message Headers
Multiple message-header fields with the same field-name MAY be
present in a message if and only if the entire field-value for that
header field is defined as a comma-separated list [i.e., #(values)].
It MUST be possible to combine the multiple header fields into one
"field-name: field-value" pair, without changing the semantics of the
message, by appending each subsequent field-value to the first, each
separated by a comma. The order in which header fields with the same
field-name are received is therefore significant to the
interpretation of the combined field value, and thus a proxy MUST NOT
change the order of these field values when a message is forwarded.
E.g.
Accept[-*]:
Allow:
Cache-Control:
Connection: Content-Encoding:
Content-Language:
Expect:
If[-None]-Match:
Pragma:
Proxy-Authenticate:
Range: (?the bytes=1#() target so I'm uncertain)
TE: (literal TE, meaning acceptable response T-E choices)
Trailer:
Transfer-Encoding:
Upgrade:
Vary: Via:
Warning:
WWW-Authenticate:
Every other header is equally guilty if we send multiples.
Obviously some extension headers not defined in RFC2616 also follow
some #() grammer. Cookies come to mind.
Bill
Re: 2.1.5 available for testing
Posted by jean-frederic clere <jf...@fujitsu-siemens.com>.
William A. Rowe, Jr. wrote:
> At 03:07 PM 6/17/2005, William A. Rowe, Jr. wrote:
>
>>-1 on Win32, caddr_t isn't sufficiently portable (fix committed).
>
>
> Correction, -1 on all platforms.
>
> jfclere just committed a significant patch to the T-E override
> of the C-L passed to us, as part of the Watchfire vulnerability
> fixes. It seems very irresponsible to release any flavor (alpha,
> beta, nadda) with a known vuln, when we've committed a fix already.
I still need some more time to check POST with 2 different content-lengths and
GET with content-length.
>
> Also, possibly across platforms is a fault in ssl_engine_init,
> where the host->protocol is still NULL, and we are trying to
> strcmp it to 'https'. I spent part of my weekend trying to
> grok what change has broken this, but strcmp to NULL is popping
> a segfault. Not worthy of rejecting 2.1.5 on it's own, this is
> still a minor irritation. FYI - mod_ssl was loaded without SSL
> being defined, so no ssl host actually exists.
>
> Bill
>
>
Re: 2.1.5 available for testing
Posted by Paul Querna <ch...@force-elite.com>.
William A. Rowe, Jr. wrote:
>At 02:12 AM 6/20/2005, Paul Querna wrote:
>
>
>>William A. Rowe, Jr. wrote:
>>
>>
>>
>>>Also, possibly across platforms is a fault in ssl_engine_init,
>>>where the host->protocol is still NULL, and we are trying to
>>>strcmp it to 'https'. I spent part of my weekend trying to
>>>grok what change has broken this, but strcmp to NULL is popping
>>>a segfault. Not worthy of rejecting 2.1.5 on it's own, this is
>>>still a minor irritation. FYI - mod_ssl was loaded without SSL
>>>being defined, so no ssl host actually exists.
>>>
>>>
>>In all cases the protocol should be set, and never be null. Look at
>>ap_setup_listeners() in server/listen.c.
>>
>>
>
>All linux cases as usual :-?
>
>
>
Ugh. FreeBSD actually, and all the *nix MPMs do this correctly :-P
>ap_setup_listeners is only called in the parent. On mpm_winnt,
>this happens in the open_logs hook of the parent.
>
>
I wish we had more 'rules' for MPMs. Right now its hit and miss. In
this case, I missed mpm_winnt...
>get_listeners_from_parent in the mpm_winnt creates those per-child
>listen records. Memory is not inherited between parent and child
>so the patch to modify this broke win32.
>
>
Okay, I will look at breaking this out to a separate function, and then
calling it from the correct places in mpm_winnt.
>This code seems a bit too convoluted for me to delve into right
>now, and I'm not quite clear what problem the patch was ment to
>solve in the first place (?)
>
>
The point is to inherit a Protocol in a Virtual Host from the Listening
Socket, if one wasn't explicitly set.
-Paul
Re: 2.1.5 available for testing
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 02:12 AM 6/20/2005, Paul Querna wrote:
>William A. Rowe, Jr. wrote:
>
>>Also, possibly across platforms is a fault in ssl_engine_init,
>>where the host->protocol is still NULL, and we are trying to
>>strcmp it to 'https'. I spent part of my weekend trying to
>>grok what change has broken this, but strcmp to NULL is popping
>>a segfault. Not worthy of rejecting 2.1.5 on it's own, this is
>>still a minor irritation. FYI - mod_ssl was loaded without SSL
>>being defined, so no ssl host actually exists.
>
>In all cases the protocol should be set, and never be null. Look at
>ap_setup_listeners() in server/listen.c.
All linux cases as usual :-?
ap_setup_listeners is only called in the parent. On mpm_winnt,
this happens in the open_logs hook of the parent.
get_listeners_from_parent in the mpm_winnt creates those per-child
listen records. Memory is not inherited between parent and child
so the patch to modify this broke win32.
This code seems a bit too convoluted for me to delve into right
now, and I'm not quite clear what problem the patch was ment to
solve in the first place (?)
Bill
Re: 2.1.5 available for testing
Posted by Paul Querna <ch...@force-elite.com>.
William A. Rowe, Jr. wrote:
>Also, possibly across platforms is a fault in ssl_engine_init,
>where the host->protocol is still NULL, and we are trying to
>strcmp it to 'https'. I spent part of my weekend trying to
>grok what change has broken this, but strcmp to NULL is popping
>a segfault. Not worthy of rejecting 2.1.5 on it's own, this is
>still a minor irritation. FYI - mod_ssl was loaded without SSL
>being defined, so no ssl host actually exists.
>
>
In all cases the protocol should be set, and never be null. Look at
ap_setup_listeners() in server/listen.c.
What configuration are you using that causes it to be NULL in cases?
Thanks,
-Paul
Re: 2.1.5 available for testing
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 03:07 PM 6/17/2005, William A. Rowe, Jr. wrote:
>-1 on Win32, caddr_t isn't sufficiently portable (fix committed).
Correction, -1 on all platforms.
jfclere just committed a significant patch to the T-E override
of the C-L passed to us, as part of the Watchfire vulnerability
fixes. It seems very irresponsible to release any flavor (alpha,
beta, nadda) with a known vuln, when we've committed a fix already.
Also, possibly across platforms is a fault in ssl_engine_init,
where the host->protocol is still NULL, and we are trying to
strcmp it to 'https'. I spent part of my weekend trying to
grok what change has broken this, but strcmp to NULL is popping
a segfault. Not worthy of rejecting 2.1.5 on it's own, this is
still a minor irritation. FYI - mod_ssl was loaded without SSL
being defined, so no ssl host actually exists.
Bill
Re: 2.1.5 available for testing
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
-1 on Win32, caddr_t isn't sufficiently portable (fix committed).
Also, LDAP TLS is altogether broken, my gut says disable it, but
this may not be an issue in the previous flavor of apr-util.
I'm testing HEAD - which is why my apr-util result might vary.
And stumbled across an old install of apache.exe which might have
tripped me up (instead of using httpd.exe). So I'll have to unwind
exactly what's going on with apr_ldap.
I'm in the process of a broad range of 1.3 / 2.0 / 2.1 proxy
header introspection, so I'll have a conclusive +/-1 on RFC2616
misbehavior shortly. In light of the Watchfire analysis, it's
irresponsible of us to release anything until such issues are
fully addressed, and I don't care if you call it beta, alpha,
or nadda. At the very least, jfclere just fixed a major snafu
in the T-E/C-L tests, which renders 2.1.5 borked, in my mind.
Bill
At 02:40 AM 6/17/2005, Paul Querna wrote:
>Please test and vote on releasing 2.1.5 as -alpha.
>
>Available at:
>http://httpd.apache.org/dev/dist/
>
>(might take up to 2 hours for the files to appear, due to the rsync delay)
>
>MD5 (httpd-2.1.5-alpha.tar.Z) = f9dea893723fe7ddb8e9c5a4225a276b
>MD5 (httpd-2.1.5-alpha.tar.bz2) = 8ec926f27c2768c7cbd24f42fa22108a
>MD5 (httpd-2.1.5-alpha.tar.gz) = 7fdc3d61deb72b3815e137bdae282f0e
>
>Thanks,
>
>Paul
Re: 2.1.5 available for testing
Posted by Paul Querna <ch...@force-elite.com>.
Paul Querna wrote:
> Please test and vote on releasing 2.1.5 as -alpha.
>
+1 from me, Tested on FreeBSD 6.0-CURRENT and NetBSD 2.0.
-Paul
Re: 2.1.5 available for testing
Posted by Oden Eriksson <oe...@mandriva.com>.
fredag 17 juni 2005 09.40 skrev Paul Querna:
> Please test and vote on releasing 2.1.5 as -alpha.
>
> Available at:
> http://httpd.apache.org/dev/dist/
>
> (might take up to 2 hours for the files to appear, due to the rsync delay)
>
> MD5 (httpd-2.1.5-alpha.tar.Z) = f9dea893723fe7ddb8e9c5a4225a276b
> MD5 (httpd-2.1.5-alpha.tar.bz2) = 8ec926f27c2768c7cbd24f42fa22108a
> MD5 (httpd-2.1.5-alpha.tar.gz) = 7fdc3d61deb72b3815e137bdae282f0e
>
> Thanks,
>
> Paul
+1 on Mandriva LE2005
--
Regards // Oden Eriksson
Mandriva: http://www.mandriva.com
NUX: http://nux.se
Re: 2.1.5 available for testing
Posted by Joe Orton <jo...@redhat.com>.
On Fri, Jun 17, 2005 at 12:40:50AM -0700, Paul Querna wrote:
> Please test and vote on releasing 2.1.5 as -alpha.
+1 for alpha, httpd-test'ed on a bunch of Linuxes here, looks good.
Thanks Paul! Also +1 on basing the 2.1.x/2.2.x stabilisation branch on
this per previous discussion.
The C-L vs T-E thing is not very critical and the handling of that in
this release is not really much worse than all previous 2.0.x releases.
joe
Re: 2.1.5 available for testing
Posted by Sander Temme <sa...@temme.net>.
On Jun 17, 2005, at 12:40 AM, Paul Querna wrote:
> Please test and vote on releasing 2.1.5 as -alpha.
I know it's already been vetoed, but here's my run:
Darwin MonaLisa 8.1.0 Darwin Kernel Version 8.1.0: Tue May 10
18:16:08 PDT 2005; root:xnu-792.1.5.obj~4/RELEASE_PPC Power Macintosh
powerpc
2.1.4:
Failed Test Stat Wstat Total Fail Failed List of Failed
------------------------------------------------------------------------
-------
t/apache/passbrigade.t 114 7 6.14% 55-57 111-114
t/apache/rwrite.t 114 7 6.14% 54-57 112-114
t/http11/chunked.t 30 3 10.00% 9 14 19
t/modules/include.t 86 1 1.16% 51
t/modules/info.t 1 1 100.00% 1
t/protocol/echo.t 255 65280 8 16 200.00% 1-8
t/ssl/proxy.t 172 3 1.74% 59 61 115
3 tests and 1 subtest skipped.
Failed 7/63 test scripts, 88.89% okay. 30/2790 subtests failed,
98.92% okay.
2.1.5:
Failed Test Stat Wstat Total Fail Failed List of Failed
------------------------------------------------------------------------
-------
t/apache/passbrigade.t 114 8 7.02% 54-57 111-114
t/apache/rwrite.t 114 8 7.02% 54-57 111-114
t/http11/chunked.t 30 3 10.00% 9 14 19
t/modules/info.t 1 1 100.00% 1
t/protocol/echo.t 255 65280 8 16 200.00% 1-8
3 tests and 1 subtest skipped.
Failed 5/63 test scripts, 92.06% okay. 28/2790 subtests failed,
99.00% okay.
So, we're doing a little better with the new drop.
I have done no analysis on the failures but may do so as time permits.
S.
--
sander@temme.net http://www.temme.net/sander/
PGP FP: 51B4 8727 466A 0BC3 69F4 B7B8 B2BE BC40 1529 24AF