mirror of
http://git.haproxy.org/git/haproxy.git/
synced 2025-03-09 12:58:07 +00:00
haproxy public development tree
5b15447672
Up to now, we only had a flag in the session indicating if it had to work in "connection: close" mode. This is not at all compatible with keep-alive. Now we ensure that both sides of a connection act independantly and only relative to the transaction. The HTTP version of the request and response is also correctly considered. The connection already knows several modes : - tunnel (CONNECT or no option in the config) - keep-alive (when permitted by configuration) - server-close (close the server side, not the client) - close (close both sides) This change carefully detects all situations to find whether a request can be fully processed in its mode according to the configuration. Then the response is also checked and tested to fix corner cases which can happen with different HTTP versions on both sides (eg: a 1.0 client asks for explicit keep-alive, and the server responds with 1.1 without a header). The mode is selected by a capability elimination algorithm which automatically focuses on the least capable agent between the client, the frontend, the backend and the server. This ensures we won't get undesired situtations where one of the 4 "agents" is not able to process a transaction. No "Connection: close" header will be added anymore to HTTP/1.0 requests or responses since they're already in close mode. The server-close mode is still not completely implemented. The response needs to be rewritten as keep-alive before being sent to the client if the connection was already in server-close (which implies the request was in keep-alive) and if the response has a content-length or a transfer-encoding (but only if client supports 1.1). A later improvement in server-close mode would probably be to detect some situations where it's interesting to close the response (eg: redirections with remote locations). But even then, the client might close by itself. It's also worth noting that in tunnel mode, no connection header is affected in either direction. A tunnelled connection should theorically be notified at the session level, but this is useless since by definition there will not be any more requests on it. Thus, we don't need to add a flag into the session right now. |
||
|---|---|---|
| contrib | ||
| doc | ||
| ebtree | ||
| examples | ||
| include | ||
| src | ||
| tests | ||
| .gitignore | ||
| CHANGELOG | ||
| CONTRIB | ||
| LICENSE | ||
| Makefile | ||
| Makefile.bsd | ||
| Makefile.osx | ||
| README | ||
| ROADMAP | ||
| SUBVERS | ||
| TODO | ||
| VERDATE | ||
| VERSION | ||
-------------------
H A - P r o x y
How to build it
-------------------
version 1.3.15
willy tarreau
2008/05/25
To build haproxy, you will need :
- GNU make. Neither Solaris nor OpenBSD's make work with this makefile.
However, specific Makefiles for BSD and OSX are provided.
- GCC between 2.91 and 4.3. Others may work, but not tested.
- GNU ld
Also, you might want to build with libpcre support, which will provide a very
efficient regex implementation and will also fix some badness on Solaris's one.
To build haproxy, you have to choose your target OS amongst the following ones
and assign it to the TARGET variable :
- linux22 for Linux 2.2
- linux24 for Linux 2.4 and above (default)
- linux24e for Linux 2.4 with support for a working epoll (> 0.21)
- linux26 for Linux 2.6 and above
- solaris for Solaris 8 or 10 (others untested)
- freebsd for FreeBSD 5 to 6.2 (others untested)
- openbsd for OpenBSD 3.1 to 3.7 (others untested)
- cygwin for Cygwin
- generic for any other OS.
- custom to manually adjust every setting
You may also choose your CPU to benefit from some optimizations. This is
particularly important on UltraSparc machines. For this, you can assign
one of the following choices to the CPU variable :
- i686 for intel PentiumPro, Pentium 2 and above, AMD Athlon
- i586 for intel Pentium, AMD K6, VIA C3.
- ultrasparc : Sun UltraSparc I/II/III/IV processor
- generic : any other processor or no specific optimization. (default)
Alternatively, you may just set the CPU_CFLAGS value to the optimal GCC options
for your platform.
You may want to build specific target binaries which do not match your native
compiler's target. This is particularly true on 64-bit systems when you want
to build a 32-bit binary. Use the ARCH variable for this purpose. Right now
it only knows about a few x86 variants (i386,i486,i586,i686,x86_64) and sets
-m32/-m64 as well as -march=<arch> accordingly.
If your system supports PCRE (Perl Compatible Regular Expressions), then you
really should build with libpcre which is between 2 and 10 times faster than
other libc implementations. Regex are used for header processing (deletion,
rewriting, allow, deny). The only inconvenient of libpcre is that it is not
yet widely spread, so if you build for other systems, you might get into
trouble if they don't have the dynamic library. In this situation, you should
statically link libpcre into haproxy so that it will not be necessary to
install it on target systems. Available build options for PCRE are :
- USE_PCRE=1 to use libpcre, in whatever form is available on your system
(shared or static)
- USE_STATIC_PCRE=1 to use a static version of libpcre even if the dynamic
one is available. This will enhance portability.
- with no option, use your OS libc's standard regex implemntation (default).
Warning! group references on Solaris seem broken. Use static-pcre whenever
possible.
By default, the DEBUG variable is set to '-g' to enable debug symbols. It is
not wise to disable it on uncommon systems, because it's often the only way to
get a complete core when you need one. Otherwise, you can set DEBUG to '-s' to
strip the binary.
For example, I use this to build for Solaris 8 :
$ make TARGET=solaris CPU=ultrasparc USE_STATIC_PCRE=1
And I build it this way on OpenBSD or FreeBSD :
$ make -f Makefile.bsd REGEX=pcre DEBUG= COPTS.generic="-Os -fomit-frame-pointer -mgnu"
In order to build a 32-bit binary on an x86_64 Linux system :
$ make TARGET=linux26 ARCH=i386
If you need to pass other defines, includes, libraries, etc... then please
check the Makefile to see which ones will be available in your case, and
use the USE_* variables in the GNU Makefile, or ADDINC, ADDLIB, and DEFINE
variables in the BSD makefiles.
-- end