Sounds good, glad I was able to help. I'll keep an eye on this in a
future httpd release.
On Sat, Sep 20, 2008 at 6:42 AM, Ruediger Pluem [EMAIL PROTECTED] wrote:
On 09/20/2008 12:21 PM, Nick Kew wrote:
On 19 Sep 2008, at 23:08, Ruediger Pluem wrote:
On 09/19/2008 11:24 PM, Adam
On 09/20/2008 12:21 PM, Nick Kew wrote:
On 19 Sep 2008, at 23:08, Ruediger Pluem wrote:
On 09/19/2008 11:24 PM, Adam Woodworth wrote:
The problem with this is that it will also do this for connections to
the backend that timed out. For our application, we want actual
timeouts to be
On 09/19/2008 11:24 PM, Adam Woodworth wrote:
Now that we're using 2.2.9 in the field, I've noticed a problem with
r657443, or at least it's a problem for our application.
r657443 added code to shutdown the connection w/o any response with an
EOC in the case that a second (or later) request
On 05/17/2008 09:24 PM, Ruediger Pluem wrote:
In conjunction with the last patch attached to 37770 the following patch
should finally prevent this problem at the cost of a performance penalty:
Index: modules/proxy/proxy_util.c
From a usage standpoint I have no real preference other than I need to
be able to configure it from httpd.conf on a per-host basis. :)
What is a worker specific property?
I would like to fold the approach of the patch into trunk to reduce PR37770
to become (hopefully) an RTFM bug. The
On 06/02/2008 10:11 PM, Adam Woodworth wrote:
From a usage standpoint I have no real preference other than I need to
be able to configure it from httpd.conf on a per-host basis. :)
What is a worker specific property?
All the properties you put behind ProxyPass / balancermember or via
Can you please test the attached patch in addition to my other patches, but
without removing mod_deflate from the chain as you did in your application?
Thanks.
This patch works for us, we don't have to remove the deflate filter
ourselves anymore. Thanks!
Will this also make it into 2.2.9?
On 05/27/2008 09:20 PM, Adam Woodworth wrote:
Can you please test the attached patch in addition to my other patches, but
without removing mod_deflate from the chain as you did in your application?
Thanks.
This patch works for us, we don't have to remove the deflate filter
ourselves anymore.
On 05/24/2008 12:10 AM, Adam Woodworth wrote:
Thanks Ruediger. Keep us posted.
Is this mod_proxy patch going to get into 2.2.9, or wait until another
2.2.x release when the deflate issue can be resolved?
Cheers,
Adam
Can you please test the attached patch in addition to my other patches,
I think that the deflate filter might need to be fixed in order to
work with this patch, I think the EOC bucket is causing the deflate
filter to cause apache to return a 200 OK to the client with a blank
page. I had to make our mod_perl application remove the deflate
filter from the chain when we
And FWIW, when the EOC bucket is sent down, our mod_perl filter sees
an ERROR bucket, i.e. the bucket type is ERROR not EOC, if that
matters.
On Fri, May 23, 2008 at 1:19 PM, Adam Woodworth [EMAIL PROTECTED] wrote:
I think that the deflate filter might need to be fixed in order to
work with
Err, sorry, we do see the EOC bucket, it's just after the ERROR and
EOS buckets (duh). :)
On Fri, May 23, 2008 at 1:31 PM, Adam Woodworth [EMAIL PROTECTED] wrote:
And FWIW, when the EOC bucket is sent down, our mod_perl filter sees
an ERROR bucket, i.e. the bucket type is ERROR not EOC, if
On 05/23/2008 07:55 PM, Adam Woodworth wrote:
Err, sorry, we do see the EOC bucket, it's just after the ERROR and
EOS buckets (duh). :)
This is what I expect. I have checked and I think I know what's going wrong,
but I have no solution yet how to fix it. The solution I am looking for should
Thanks Ruediger. Keep us posted.
Is this mod_proxy patch going to get into 2.2.9, or wait until another
2.2.x release when the deflate issue can be resolved?
Cheers,
Adam
On Fri, May 23, 2008 at 5:51 PM, Ruediger Pluem [EMAIL PROTECTED] wrote:
On 05/23/2008 07:55 PM, Adam Woodworth wrote:
On 05/24/2008 12:10 AM, Adam Woodworth wrote:
Thanks Ruediger. Keep us posted.
Is this mod_proxy patch going to get into 2.2.9, or wait until another
2.2.x release when the deflate issue can be resolved?
As it looks currently it will be in 2.2.9, which doesn't mean that I do not find
a fix
On 05/21/2008 10:34 PM, Adam Woodworth wrote:
I think there is a problem with r657443 (and thus I assume r645813):
I applied the r657443 patch to my copy of the 2.2.8 official release
source and it doesn't work right. The problem is that the change to
mod_proxy_http.c checks c-keepalives for
Ok my mistake, the setup I was using turned out to be the problem.
I'm now able to see the patch working.
Sorry about that.
Thanks again Ruediger.
Now I just have to modify our mod_perl application to behave correctly
when mod_proxy sends EOC.
Adam
On Thu, May 22, 2008 at 4:28 AM, Ruediger
I think there is a problem with r657443 (and thus I assume r645813):
I applied the r657443 patch to my copy of the 2.2.8 official release
source and it doesn't work right. The problem is that the change to
mod_proxy_http.c checks c-keepalives for a value, but c-keepalives
is filled out by
I tried using the SetEnv proxy-nokeepalive 1 option in httpd.conf,
and it cleared up the proxy errors that I was having with an IIS
backend server, and it may have decreased the proxy errors with Apache
backend servers as well.
I tried again without the proxy-nokeepalive option, and the
And FWIW the backends also seem to have keepalives disabled.
On Mon, May 19, 2008 at 12:36 PM, Adam Woodworth [EMAIL PROTECTED] wrote:
I tried using the SetEnv proxy-nokeepalive 1 option in httpd.conf,
and it cleared up the proxy errors that I was having with an IIS
backend server, and it may
On 05/19/2008 06:09 PM, Adam Woodworth wrote:
Index: modules/proxy/proxy_util.c
+/* Close a possible existing socket if we are told to do so */
+if (conn-close) {
+socket_cleanup(conn);
+conn-close = 0;
+}
Does this mean that sockets that should have been closed
So let's consider the case of a web browser that uses keepalives. If
the web browser has a keepalive connection, and the connection closes
behind it's back so that the next time the browser tries to use the
connection it fails (like this problem we're having with mod_proxy),
what should the web
On May 19, 2008, at 3:36 PM, Adam Woodworth wrote:
So let's consider the case of a web browser that uses keepalives. If
the web browser has a keepalive connection, and the connection closes
behind it's back so that the next time the browser tries to use the
connection it fails (like this
On 05/19/2008 09:36 PM, Adam Woodworth wrote:
So let's consider the case of a web browser that uses keepalives. If
the web browser has a keepalive connection, and the connection closes
behind it's back so that the next time the browser tries to use the
connection it fails (like this problem
#include sys/types.h
#include sys/socket.h
#include netinet/ip.h
#include string.h
#include unistd.h
#include stdio.h
int main(int argc, char *argv[])
{
int listen_fd;
int fd;
struct sockaddr_storage addr;
socklen_t addrlen = sizeof(addr);
struct sockaddr_in addr_in;
Can anyone explain why turning on proxy-nokeepalive would cause proxy
errors to an IIS server to stop happening?
We would see proxy errors to IIS backends regularly with
proxy-nokeepalive OFF (mod_proxy sends Connection: Keep-Alive).
When we use proxy-nokeepalive ON (set to 1, mod_proxy sends
Forgot an important detail:
In both cases, the backend always responds with Connection: Close
(it's setup to do that).
On Mon, May 19, 2008 at 4:51 PM, Adam Woodworth [EMAIL PROTECTED] wrote:
Can anyone explain why turning on proxy-nokeepalive would cause proxy
errors to an IIS server to stop
On 05/16/2008 11:21 PM, Adam Woodworth wrote:
So I have some more information about this, but this time related to
having keepalives OFF in mod_proxy.
I tried using the SetEnv proxy-nokeepalive 1 option in httpd.conf,
and it cleared up the proxy errors that I was having with an IIS
backend
So I have some more information about this, but this time related to
having keepalives OFF in mod_proxy.
I tried using the SetEnv proxy-nokeepalive 1 option in httpd.conf,
and it cleared up the proxy errors that I was having with an IIS
backend server, and it may have decreased the proxy errors
Hi,
I was wondering if anyone might have some more information on bug
#37770. I've added a comment there recently, at the end of the bug
report, #83.
https://issues.apache.org/bugzilla/show_bug.cgi?id=37770
I think this bug is a serious issue for our application so I'm trying
to see if anyone
Reading over the bug I'm still curious about the actual
race condition aspect of it... Even doing an 'OPTIONS *'
right before sending the request does not ensure that
the race condition goes away because there is still that
period of time where the backend could go away right after
that (in fact,
On Mon, 12 May 2008 13:52:18 -0400
Adam Woodworth [EMAIL PROTECTED] wrote:
Hi,
I was wondering if anyone might have some more information on bug
#37770. I've added a comment there recently, at the end of the bug
report, #83.
https://issues.apache.org/bugzilla/show_bug.cgi?id=37770
If
I haven't looked at the code in mod_proxy to see how it handles the
Keep-Alive header returned by the backend server, but what I'm seeing
in this tcpdump I have that shows the proxy error happening is that
the backend webserver is IIS, and it is not sending any Connection or
Keep-Alive headers
33 matches
Mail list logo
