Willy Tarreau 96e312139a [MEDIUM] http: add support for "http-no-delay" ... There are some very rare server-to-server applications that abuse the HTTP protocol and expect the payload phase to be highly interactive, with many interleaved data chunks in both directions within a single request. This is absolutely not supported by the HTTP specification and will not work across most proxies or servers. When such applications attempt to do this through haproxy, it works but they will experience high delays due to the network optimizations which favor performance by instructing the system to wait for enough data to be available in order to only send full packets. Typical delays are around 200 ms per round trip. Note that this only happens with abnormal uses. Normal uses such as CONNECT requests nor WebSockets are not affected. When "option http-no-delay" is present in either the frontend or the backend used by a connection, all such optimizations will be disabled in order to make the exchanges as fast as possible. Of course this offers no guarantee on the functionality, as it may break at any other place. But if it works via HAProxy, it will work as fast as possible. This option should never be used by default, and should never be used at all unless such a buggy application is discovered. The impact of using this option is an increase of bandwidth usage and CPU usage, which may significantly lower performance in high latency environments. This change should be backported to 1.4 since the first report of such a misuse was in 1.4. Next patch will also be needed.		2011-05-30 18:42:41 +02:00
..
common	[BUG] stream_sock: use get_addr_len() instead of sizeof() on sockaddr_storage	2011-04-05 16:56:50 +02:00
import	[MAJOR] replace ultree with ebtree in wait-queues	2008-06-24 08:17:16 +02:00
proto	[REORG] http: move HTTP error codes back to proto_http.h	2011-05-11 16:31:43 +02:00
types	[MEDIUM] http: add support for "http-no-delay"	2011-05-30 18:42:41 +02:00