http-relay should be avoided due to CVE-2009-0801. It was implemented to
support ancient HTTP/1.0 clients that did not set `Host` header, so
upstream proxy had at least some way to determine request destination.
In modern post-SPDY world this method should not be used, you should
rather configure upstream proxy to accept CONNECT requests to any port
and use `http-connect` instead.
Great CVE-2009-0801 description can be found in squid-users on 2015-12-18
http://lists.squid-cache.org/pipermail/squid-users/2015-December/008392.html
It gives ~33% increase of throughput on CPU-bound box. E.g. following
machine single-connection throughput goes from ~30 Mbit/s to ~40 Mbit/s
system type: xRX200 rev 1.2
machine: TDW8980 - TP-LINK TD-W8980
cpu model: MIPS 34Kc V5.6
BogoMIPS: 332.54
This commit implements two more features:
* min_accept_backoff configuration option
* retry accept() after some close() calls
See also https://github.com/darkk/redsocks/issues/19
Libevent 2 deprecates evbuffer_readline() function, where any sequence
of any number of carriage return and linefeed characters is treated like
end of line, and introduces better evbuffer_readln(), where termination
format can be explicitly set to: \n, [\r]\n, \r\n or already mentioned
old behaviour.
Change past evbuffer_readline() calls to new
redsocks_evbuffer_readline() function. If libevent 2 is present, use
there evbuffer_readln() with eol_style set to an optional carriage
return, followed by a linefeed (EVBUFFER_EOL_CRLF) instead of obsolete
evbuffer_readln().
Important note:
Consuming all CR and LF characters in one go (behaviour of
evbuffer_readline(), nowadays aliasing to evbuffer_readln() with
eol_style set to EVBUFFER_EOL_ANY) hangs up parsing of HTTP request
header ending with "\r\n\r\n", because it misses the empty line.
Conflicts (resolved):
utils.c
utils.h
redsocks.c: In function 'redsocks_read_expected':
redsocks.c:407: warning: unused variable 'read'
http-relay.c: In function 'httpr_client_read_cb':
http-relay.c:520: warning: unused variable 'written_wo_null'
These variables are used in asserts and if asserts are not compiled,
e.g. by defining NDEBUG (usually in CFLAGS via -DNDEBUG), then we have
misleading warnings.
Add in utils.h UNUSED() macro for creating null statement with result
casted to void. Use it to fix above warnings.
