-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
-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
-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
-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
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 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
15 matches
Mail list logo
