please check

2014-05-01 Thread Rachel Chavez
Could someone please tell me if what I did is right?
I posted this fix a while ago and I didn't get a response.

http://marc.info/?l=haproxym=139506908430417w=2

Thank you in advance,

-- 
Rachel Chavez


Re: please check

2014-05-01 Thread Rachel Chavez
The problem is:

when client sends a request with incomplete body (it has content-length but
no body) then haproxy returns a 5XX error when it should be a client issue.

In the session.c file starting in 2404 i make sure that if I haven't
received the entire body of the request I continue to wait for it by
keeping AN_REQ_WAIT_HTTP as part of the request analyzers list as long as
the client read timeout hasn't fired yet.
In the proto_http.c file what I tried to do is avoid getting a server
timeout when the client had timed-out already.

Thank you for your prompt answer,
Rachel

On Thu, May 1, 2014 at 3:27 PM, Willy Tarreau w...@1wt.eu wrote:

 Hi,

 On Thu, May 01, 2014 at 09:56:01AM -0400, Rachel Chavez wrote:
  Could someone please tell me if what I did is right?
  I posted this fix a while ago and I didn't get a response.
 
  http://marc.info/?l=haproxym=139506908430417w=2
 
  Thank you in advance,

 Could you please first describe the problem you encountered ?

 It's very hard to say if some code does the right thing in front
 of no known problem. Moreover, your mailer has totally mangled
 the patch, making it harder to understand. But at first glance
 I'm seeing thing that don't look normal, such as returning 0
 from the analyser in case of timeout without even setting any
 error.

 Thanks,
 Willy




-- 
Rachel Chavez


Fix for 5XX server error with incomplete client request

2014-03-17 Thread Rachel Chavez
This patch should get rid of 5XX server errors when receiving an incomplete
client request:

diff -rupNwBb /Users/rachel/Downloads/haproxy-408_spec/src/proto_http.c
src/proto_http.c
--- /Users/rachel/Downloads/haproxy-408_spec/src/proto_http.c 2014-03-07
14:07:04.0 -0500
+++ src/proto_http.c 2014-03-07 17:22:46.0 -0500
@@ -5316,6 +5316,11 @@ int http_wait_for_response(struct sessio

  /* client abort with an abortonclose */
  else if ((rep-flags  CF_SHUTR)  ((s-req-flags 
(CF_SHUTR|CF_SHUTW)) == (CF_SHUTR|CF_SHUTW))) {
+ if(s-req-flags  CF_READ_TIMEOUT)
+ {
+ rep-analysers = 0;
+ return 0;
+ }
  s-fe-fe_counters.cli_aborts++;
  s-be-be_counters.cli_aborts++;
  if (objt_server(s-target))
diff -rupNwBb /Users/rachel/Downloads/haproxy-408_spec/src/session.c
src/session.c
--- /Users/rachel/Downloads/haproxy-408_spec/src/session.c 2014-03-07
14:07:04.0 -0500
+++ src/session.c 2014-03-10 11:13:18.0 -0400
@@ -2401,9 +2401,21 @@ struct task *process_session(struct task

  if ((s-rep-flags  (CF_AUTO_CLOSE|CF_SHUTR)) == 0 
 (tick_isset(s-req-wex) || tick_isset(s-rep-rex))) {
+ if((s-txn.req.body_len + s-txn.req.eoh)  s-req-total) {
  s-req-flags |= CF_READ_NOEXP;
  s-req-rex = TICK_ETERNITY;
  }
+ else
+ {
+ if(!(s-req-flags  CF_READ_TIMEOUT))
+ {
+ s-req-analysers |= AN_REQ_WAIT_HTTP;
+ if(s-txn.req.msg_state = HTTP_MSG_BODY) {
+ s-txn.req.msg_state = HTTP_MSG_LAST_LF;
+ }
+ }
+ }
+ }

  /* When any of the stream interfaces is attached to an applet,
  * we have to call it here. Note that this one may wake the

-- 
Rachel Chavez
diff -rupNwBb /Users/rachel/Downloads/haproxy-408_spec/src/proto_http.c 
src/proto_http.c
--- /Users/rachel/Downloads/haproxy-408_spec/src/proto_http.c   2014-03-07 
14:07:04.0 -0500
+++ src/proto_http.c2014-03-07 17:22:46.0 -0500
@@ -5316,6 +5316,11 @@ int http_wait_for_response(struct sessio
 
/* client abort with an abortonclose */
else if ((rep-flags  CF_SHUTR)  ((s-req-flags  
(CF_SHUTR|CF_SHUTW)) == (CF_SHUTR|CF_SHUTW))) {
+   if(s-req-flags  CF_READ_TIMEOUT)
+   {
+   rep-analysers = 0;
+   return 0;
+   }
s-fe-fe_counters.cli_aborts++;
s-be-be_counters.cli_aborts++;
if (objt_server(s-target))
diff -rupNwBb /Users/rachel/Downloads/haproxy-408_spec/src/session.c 
src/session.c
--- /Users/rachel/Downloads/haproxy-408_spec/src/session.c  2014-03-07 
14:07:04.0 -0500
+++ src/session.c   2014-03-10 11:13:18.0 -0400
@@ -2401,9 +2401,21 @@ struct task *process_session(struct task
 
if ((s-rep-flags  (CF_AUTO_CLOSE|CF_SHUTR)) == 0 
(tick_isset(s-req-wex) || tick_isset(s-rep-rex))) {
+   if((s-txn.req.body_len + s-txn.req.eoh)  
s-req-total) {
s-req-flags |= CF_READ_NOEXP;
s-req-rex = TICK_ETERNITY;
}
+   else
+   {
+   if(!(s-req-flags  CF_READ_TIMEOUT))
+   {
+   s-req-analysers |= AN_REQ_WAIT_HTTP;
+   if(s-txn.req.msg_state = 
HTTP_MSG_BODY) {
+   s-txn.req.msg_state = 
HTTP_MSG_LAST_LF;
+   }
+   }
+   }
+   }
 
/* When any of the stream interfaces is attached to an applet,
 * we have to call it here. Note that this one may wake the


haproxy 5XX server error (should be 408)

2014-02-12 Thread Rachel Chavez
it seems that the client timeout is not expiring when a incomplete request
is sent. Where (in the code) is checked if the client time-out is expired?

thanks in advance for your help.