On 02/20/2006 02:51 PM, Joe Orton wrote:
That's not what I meant. This is a bit tricky. Here's a restatement of
the problem, just to make sure we're talking about the same thing:
If a client reuses a connection to an HTTP server which has been held
open persistently, there is a risk
-Ursprüngliche Nachricht-
Von:
Serf's mailing list is at:
http://mailman.webdav.org/mailman/listinfo/serf-dev/
(You'll find some familiar faces posting there. *duck*)
Thanks for the hints. I see it is a low traffic mailing list :-).
I hope to find time to have a look into
-Ursprüngliche Nachricht-
Von: Joe Orton
The regression test runs last night had between zero and
three failures
in t/ssl/proxy.t in various builds (timing dependent, I guess); the
build which had three failures was:
So that seems to be related to the other issue we
On Wed, Feb 15, 2006 at 04:44:43PM -, Jim Jagielski wrote:
Author: jim
Date: Wed Feb 15 08:44:42 2006
New Revision: 378032
URL: http://svn.apache.org/viewcvs?rev=378032view=rev
Log:
*) mod_proxy: Fix KeepAlives not being allowed and set to
backend servers. PR38602. [Ruediger
-Ursprüngliche Nachricht-
Von: Joe Orton
New Revision: 378032
URL: http://svn.apache.org/viewcvs?rev=378032view=rev
Log:
*) mod_proxy: Fix KeepAlives not being allowed and set to
backend servers. PR38602. [Ruediger Pluem, Jim Jagielski]
Also, document previous
On Mon, Feb 20, 2006 at 10:53:27AM +0100, Plüm, Rüdiger, VIS wrote:
Von: Joe Orton
New Revision: 378032
URL: http://svn.apache.org/viewcvs?rev=378032view=rev
Log:
*) mod_proxy: Fix KeepAlives not being allowed and set to
backend servers. PR38602. [Ruediger Pluem, Jim
-Ursprüngliche Nachricht-
Von: Joe Orton
http://mail-archives.apache.org/mod_mbox/httpd-dev/200602.mbox
/ajax/[EMAIL PROTECTED]
this is really weird. Maybe another change that happened after r378032?
Maybe Jim's build didn't include mod_ssl? r378032 is the most recent
change
On Mon, Feb 20, 2006 at 11:30:02AM +0100, Plüm, Rüdiger, VIS wrote:
-Ursprüngliche Nachricht-
Von: Joe Orton
http://mail-archives.apache.org/mod_mbox/httpd-dev/200602.mbox
/ajax/[EMAIL PROTECTED]
this is really weird. Maybe another change that happened after r378032?
-Ursprüngliche Nachricht-
Von: Joe Orton
Could you please give the following patch a try?
That fixed most of the failures, there are still two left:
OK. That gives a better idea what possibly goes wrong.
t/ssl/proxyok 61/172# Failed test 62 in t/ssl/proxy.t at line 112
On Mon, Feb 20, 2006 at 12:52:31PM +0100, Plüm, Rüdiger, VIS wrote:
I found only one pertinent error message in the log:
[Mon Feb 20 10:40:08 2006] [debug] proxy_util.c(2118): proxy: HTTP:
connection complete to 127.0.0.1:8529 (localhost.localdomain)
But this is HTTP to the backend
Hmmm... Possibly SSL requires close_on_recycle. Or, at
least, using that flag as required for SSL.
Small idea: should we adjust
ap_proxy_http_cleanup() to accept a status value,
and thus make that logic internal to it? That
is, have an OK/NOK conditional aspect to
ap_proxy_http_cleanup()? I think it would be
useful at the other places were we use it...
PS: I'm planning to be offline for the
Jim Jagielski wrote:
Hmmm... Possibly SSL requires close_on_recycle. Or, at
least, using that flag as required for SSL.
I don't have time to explain in more detail, but the more
I look over the old way, it was to maintain some sort
of local state-of-health on the socket pre-and-post
each
-Ursprüngliche Nachricht-
Von: Jim Jagielski
Jim Jagielski wrote:
Hmmm... Possibly SSL requires close_on_recycle. Or, at
least, using that flag as required for SSL.
I don't have time to explain in more detail, but the more
I look over the old way, it was to maintain
Plüm wrote:
I think the SSL problem is caused by throwing away the conn_rec
entry for the backend and create a new one for each request.
That does not sound right, but I admit that keeping it must be
carefully examinated due to several possible issues. Two
that I can see immeditately are:
-Ursprüngliche Nachricht-
Von: Jim Jagielski
term. Might be easier if we have a http / https client
library as part
of httpd or apr-util.
This only helps http, not ajp/fcgi or other protocols.
True, but ajp already does not use the fake conn_rec / request_rec stuff.
Instead
=?iso-8859-1?Q?Pl=FCm=2C_R=FCdiger=2C_VIS?= wrote:
-Urspr=FCngliche Nachricht-
Von: Jim Jagielski=20
term. Might be easier if we have a http / https client=20
library as part=20
of httpd or apr-util.
=20
This only helps http, not ajp/fcgi or other protocols.
True,
On 02/20/2006 06:38 PM, Jim Jagielski wrote:
=20
This only helps http, not ajp/fcgi or other protocols.
True, but ajp already does not use the fake conn_rec / request_rec =
stuff.
Instead it works directly on the socket, or better the code in ajp* =
works
directly on the socket and
On 02/20/2006 05:17 PM, Plüm wrote:
For me that puts the question on the table if using fake request_rec
and conn_rec structures for the backend connections is really a good
idea. This misuse already leads to problems in other areas.
Of course I should point a reference :-):
On 02/20/2006 02:51 PM, Joe Orton wrote:
That's not what I meant. This is a bit tricky. Here's a restatement of
the problem, just to make sure we're talking about the same thing:
If a client reuses a connection to an HTTP server which has been held
open persistently, there is a risk
On 02/20/2006 11:50 AM, Joe Orton wrote:
Maybe. Got another idea in the meantime. Maybe it is because we use the same
socket to a backend, but we create a new conn_rec each time for this backend
and thus try to reinit the existing ssl connection. Could you please give the
following patch a
On 2/20/06, Sander Striker [EMAIL PROTECTED] wrote:
For me that puts the question on the table if using fake request_rec
and conn_rec structures for the backend connections is really a good
idea. This misuse already leads to problems in other areas.
But reworking this will take much time
22 matches
Mail list logo
