Hi all,
Le 19/02/2014 20:30, Lukas Tribus a écrit :
Hi,
the odd thing is, if I point the url to the varnish right behind the
haproxy - the issue goes away completely.
The dump I send you, was from over the internet (a few countries apart)
- so that's probably why the MSS is the size it is :)
I'll grab a dump on haproxy server tomorrow, while reproducing the
problem with a local client.
I think something is seriously wrong on the server side. I took the liberty
of accessing http://testkkms.kk.dk myself and and I see the issues as well [1].
But haproxy doesn't behave this way.
Can you tell us more about this server? What OS is running? Any firewalls
(software or hardware)? Any other "security" product in between?
The server is announcing 1380 Byte MSS to me here as well, so this was
not something on your client side, but this is server side and thats not
very common. There must be some 'interesting' detail about this server
that we don't know yet.
I really think there isn't any issue.
Remember that some browsers (such as chrome/chromium) preopen connection
in case there is a need to ask for more requests in parallel.
While hitting F5, the browser will ask to close those connections. As
there was no data, no valid request was received on the haproxy side and
haproxy logs a 408.
I'm pretty sure that adding "option dontlognull" [1] will solve the "issue".
Also, as a side note, your configuration is not optimal :
- you are using both "option httpclose" and "option http-server-close",
you should make a choice (or use "option http-keep-alive" in recent
haproxy 1.5 dev versions).
- the "balance" keyword is not valid in a frontend section.
- you should avoid the use of "stats enable" in the defaults section.
[1]
http://cbonte.github.io/haproxy-dconv/configuration-1.5.html#option%20dontlognull
--
Cyril Bonté
