One more thought on this thread; wouldn't it be nice to
communicate to mod_cache not to trust this flaky response
or request TE+CL combination? Unsetting the keep alive on
both the proxy and client adds some degree of saftey, but
marking this non-cachable would eliminate any likely hood
of cache
William A. Rowe, Jr. wrote:
++1 To Joe's comments.
Jeff's fix is technically right, but scares the nibbles out
of me. If, for example, an exploit is able to inject the
T-E on top of the legit C-L, I really suspect we should not
trust the origin server at all.
For origin servers (as opposed
At 02:34 AM 6/23/2005, jean-frederic clere wrote:
Once the patch applied we lose the information that the request was
incorrect.
That means we won't be able to choose in proxy between sending C-L (and
dechunk) and T-E.
s/request/response/
The point was, if one were to exploit the origin
On 6/23/05, jean-frederic clere [EMAIL PROTECTED] wrote:
William A. Rowe, Jr. wrote:
++1 To Joe's comments.
Jeff's fix is technically right, but scares the nibbles out
of me. If, for example, an exploit is able to inject the
T-E on top of the legit C-L, I really suspect we should not
Jeff Trawick wrote:
On 6/23/05, jean-frederic clere [EMAIL PROTECTED] wrote:
William A. Rowe, Jr. wrote:
++1 To Joe's comments.
Jeff's fix is technically right, but scares the nibbles out
of me. If, for example, an exploit is able to inject the
T-E on top of the legit C-L, I really suspect
On 6/23/05, jean-frederic clere [EMAIL PROTECTED] wrote:
Jeff Trawick wrote:
On 6/23/05, jean-frederic clere [EMAIL PROTECTED] wrote:
William A. Rowe, Jr. wrote:
++1 To Joe's comments.
Jeff's fix is technically right, but scares the nibbles out
of me. If, for example, an exploit is
At 05:45 AM 6/23/2005, Jeff Trawick wrote:
On 6/23/05, jean-frederic clere [EMAIL PROTECTED] wrote:
William A. Rowe, Jr. wrote:
++1 To Joe's comments.
Jeff's fix is technically right, but scares the nibbles out
of me. If, for example, an exploit is able to inject the
T-E on top of the
On 6/23/05, William A. Rowe, Jr. [EMAIL PROTECTED] wrote:
At 05:45 AM 6/23/2005, Jeff Trawick wrote:
On 6/23/05, jean-frederic clere [EMAIL PROTECTED] wrote:
William A. Rowe, Jr. wrote:
++1 To Joe's comments.
Jeff's fix is technically right, but scares the nibbles out
of me. If,
On 6/23/05, Jeff Trawick [EMAIL PROTECTED] wrote:
On 6/23/05, William A. Rowe, Jr. [EMAIL PROTECTED] wrote:
At 05:45 AM 6/23/2005, Jeff Trawick wrote:
On 6/23/05, jean-frederic clere [EMAIL PROTECTED] wrote:
William A. Rowe, Jr. wrote:
++1 To Joe's comments.
Jeff's fix is
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
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
At 01:57 AM 6/20/2005, jean-frederic clere wrote:
I still need some more time to check POST with 2 different content-lengths and
GET with content-length.
Well, GET with c-l is permitted. 2 C-L headers would be rejected
due to the '##, ##' format, where the ', ' is non-numeric.
After your
Joe Orton wrote:
On Wed, Jun 22, 2005 at 03:02:50PM -0500, William Rowe wrote:
Prior to either patch we totally mishandled such requests. So the
only question which remains is; which behavior do we prefer?
As the RFC states this is not acceptable, my gut says reject ANY
request with both
On 6/22/05, Paul Querna [EMAIL PROTECTED] wrote:
Joe Orton wrote:
On Wed, Jun 22, 2005 at 03:02:50PM -0500, William Rowe wrote:
Prior to either patch we totally mishandled such requests. So the
only question which remains is; which behavior do we prefer?
As the RFC states this is not
++1 To Joe's comments.
Jeff's fix is technically right, but scares the nibbles out
of me. If, for example, an exploit is able to inject the
T-E on top of the legit C-L, I really suspect we should not
trust the origin server at all.
For origin servers (as opposed to clients) make this choice
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
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
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
Not sure what is causing he protocol not to be set either, but I hit the same
thing when testing mod_ssl on NetWare.
Brad
[EMAIL PROTECTED] Monday, June 20, 2005 1:12:23 AM
William A. Rowe, Jr. wrote:
Also, possibly across platforms is a fault in ssl_engine_init,
where the host-protocol
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
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
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.
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
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
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
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
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) =
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
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
+1 netware
[EMAIL PROTECTED] Friday, June 17, 2005 1:40:50 AM
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) =
-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
31 matches
Mail list logo
