On Mit 28.10.2009 17:12, Dirk Taggesell wrote:
On Wed, Oct 28, 2009 at 2:19 PM, Jeffrey 'jf' Lim <jfs.wo...@gmail.com>wrote:
what version of haproxy is this?
Ah sorry. It is 1.3.17
Is it possible to update to 1.3.22 yust to be on the save side ;-)
### http://haproxy.1wt.eu/
Let's put it short : those of you running 1.3.15.2, 1.3.16 or 1.3.17 are doomed
###
And one other thing to look at - what is the log line like for this
particular request?
Oct 28 13:50:57 127.0.0.1 haproxy[3282]:
88.217.248.214:42160[28/Oct/2009:13:50:57.690] cookietracker
cookietracker/cookietracker
1/0/0/-1/3 502 204 - - SL-- 2000/0/0/0/0 0/0 "GET /c HTTP/1.1"
S : the TCP session was unexpectedly aborted by the server, or the
server explicitly refused it.
L : the proxy was still transmitting LAST data to the client while the
server had already finished. This one is very rare as it can only
happen when the client dies while receiving the last packets.
Do you have any error messages in the Server logs?
followed after some seconds by about several dozen of these lines:
Oct 28 13:52:01 127.0.0.1 haproxy[3282]:
10.224.115.160:43562[28/Oct/2009:13:51:11.732] trackertest
trackertest/<NOSRV> -1/1/0/-1/50000 0
0 - - sL-- 1902/1902/1902/0/0 0/0 "<BADREQ>"
10.224.115.160 is the server's ip NATed address (Amazon EC2)
s : the server-side timeout expired while waiting for the server to send
or receive data.
L : the proxy was still transmitting LAST data to the client while the
server had already finished. This one is very rare as it can only
happen when the client dies while receiving the last packets.
As the previous poster have said haproxy wait for content of the
request.
As in rfc 2616 described:
###
10.2.5 204 No Content
The server has fulfilled the request but does not need to return an
entity-body, and might want to return updated metainformation. The
response MAY include new or updated metainformation in the form of
entity-headers, which if present SHOULD be associated with the
requested variant.
If the client is a user agent, it SHOULD NOT change its document view
from that which caused the request to be sent. This response is
primarily intended to allow input for actions to take place without
causing a change to the user agent's active document view, although
any new or updated metainformation SHOULD be applied to the document
currently in the user agent's active view.
The 204 response MUST NOT include a message-body, and thus is always
terminated by the first empty line after the header fields.
###
maybe haproxy should take care of this ;-)
Aleks
