mirror of
http://git.haproxy.org/git/haproxy.git/
synced 2025-01-18 19:50:54 +00:00
haproxy public development tree
9198ab5e7c
I noticed that haproxy, with "cookie (...) nocache" option, always adds "Cache-control: private" at the end of a header list received from this server: Cache-Control: no-cache (...) Set-Cookie: SERVERID=s6; path=/ Cache-control: private or: Set-Cookie: ASPSESSIONIDCSRCTSSB=HCCBGGACGBHDHMMKIOILPHNG; path=/ Cache-control: private Set-Cookie: SERVERID=s5; path=/ Cache-control: private It may be just redundant (two "Cache-control: private"), but sometimes it may be quite confused as we may end with two different, more and less restricted directions (no-cache & private) and even quite conflicting directions (eg. public & private): So, I added and rearranged a code, so now haproxy adds a "Cache-control: private" header only when there is no the same (private) or more restrictive (no-cache) one. It was done in three steps: 1. Use check_response_for_cacheability to check if response is not cacheable. I simply moved this call before http_header_add_tail2. 2. Use TX_CACHEABLE (not TX_CACHE_COOK - apache <= 1.3.26) to check if we need to add a Cache-control header. If we add it, clear TX_CACHEABLE and TX_CACHE_COOK. 3. Check cacheability not only with PR_O_CHK_CACHE but also with PR_O_COOK_NOC, so: - unlikely(t->be->options & PR_O_CHK_CACHE)) + (t->be->options & (PR_O_CHK_CACHE|PR_O_COOK_NOC))) txn->flags |= TX_CACHEABLE | TX_CACHE_COOK; I removed this unlikely since I believe that now it is not so unlikely. The patch is definitely not perfect, proxy should probably also remove "Cache-control: public". Unfortunately, I do not know the code good enough to do in myself, yet. ;) Anyway, I think that even now, it should be very useful. |
||
---|---|---|
doc | ||
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.2.7 willy tarreau 2005/10/25 To build haproxy, you will need : - GNU make. Neither Solaris nor OpenBSD's make work with this makefile. - GCC between 2.91 and 3.4. 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 : - linux24 for Linux 2.4 and above (default) - linux24e for Linux 2.4 with support for epoll - linux26 for Linux 2.6 and above - linux22 for Linux 2.2 - solaris for Solaris 8 or 10 (others untested) - openbsd for OpenBSD 3.1 to 3.7 (others untested) - generic for any other OS. 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) 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 options for the REGEX variable are : - libc to use your OS libc's standard regex implemntation (default). Warning! group references on Solaris seem broken. Use static-pcre whenever possible. - pcre to use libpcre, in whatever form it is available on your system (shared or static) - static-pcre to use a static version of libpcre even if the dynamic one is available. This will enhance portability. 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 REGEX=static-pcre And I build it this way on OpenBSD : $ make -f Makefile.bsd REGEX=pcre DEBUG= COPTS.generic="-Os -fomit-frame-pointer -mgnu" 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 ADDINC, ADDLIB, and DEFINE variables for this. -- end