Projects
Kolab:16:Enterprise
haproxy
Log In
Username
Password
We truncated the diff of some files because they were too big. If you want to see the full diff for every file,
click here
.
Overview
Repositories
Revisions
Requests
Users
Attributes
Meta
Expand all
Collapse all
Changes of Revision 2
View file
haproxy.spec
Changed
@@ -15,7 +15,7 @@ %global _hardened_build 1 Name: haproxy -Version: 1.5.14 +Version: 1.5.15 Release: 1%{?dist} Summary: HAProxy reverse proxy for high availability environments
View file
haproxy-1.5.14.tar.gz/.gitignore -> haproxy-1.5.15.tar.gz/.gitignore
Changed
@@ -18,3 +18,52 @@ dlmalloc.c 00*.patch *.service +*.bak +contrib/base64/base64rev +contrib/halog/halog +contrib/ip6range/ip6range +contrib/iprange/iprange +tests/test_hashes +/*.cfg +/*.conf +/*.diff +/*.patch +/*.c +/*.o +/*.so +/*.txt +/*.TXT +/*.txt.* +/*.prof +/*.gprof +/*.prof.* +/*.gprof.* +/*.tar +/*.tar.gz +/*.tgz +/*.mbox +/*.sh +/bug* +/TAGS +# Below we forbid everything and only allow what we know, that's much easier +# than blocking about 500 different test files and bug report outputs. +/.* +/* +!/.gitignore +!/CHANGELOG +!/LICENSE +!/Makefile +!/README +!/CONTRIBUTING +!/ROADMAP +!/SUBVERS +!/VERDATE +!/VERSION +!/contrib +!/doc +!/ebtree +!/examples +!/include +!/src +!/tests +!/debian
View file
haproxy-1.5.14.tar.gz/CHANGELOG -> haproxy-1.5.15.tar.gz/CHANGELOG
Changed
@@ -1,6 +1,40 @@ ChangeLog : =========== +2015/11/01 : 1.5.15 + - BUG/MINOR: log: missing some ARGC_* entries in fmt_directives() + - DOC: usesrc root privileges requirements + - BUILD: ssl: Allow building against libssl without SSLv3. + - DOC/MINOR: fix OpenBSD versions where haproxy works + - BUG/MINOR: http/sample: gmtime/localtime can fail + - DOC: typo in 'redirect', 302 code meaning + - DOC: mention that %ms is left-padded with zeroes. + - CLEANUP: .gitignore: ignore more test files + - CLEANUP: .gitignore: finally ignore everything but what is known. + - MEDIUM: config: emit a warning on a frontend without listener + - BUG/MEDIUM: counters: ensure that src_{inc,clr}_gpc0 creates a missing entry + - DOC: ssl: missing LF + - DOC: fix example of http-request using ssl_fc_session_id + - BUG/MINOR: http: remove stupid HTTP_METH_NONE entry + - BUG/MAJOR: http: don't call http_send_name_header() after an error + - BUG/MINOR: tools: make str2sa_range() report unresolvable addresses + - BUG/MEDIUM: acl: always accept match "found" + - DOC: clarify how to make use of abstract sockets in socat + - CLEANUP: config: make the errorloc/errorfile messages less confusing + - BUG/MINOR: config: check that tune.bufsize is always positive + - BUG/MEDIUM: proxy: ignore stopped peers + - BUG/MEDIUM: proxy: do not wake stopped proxies' tasks during soft_stop() + - BUG/MINOR: http: Add OPTIONS in supported http methods (found by find_http_meth) + - BUILD: enable build on Linux/s390x + - DOC: backend section missing parameters + - DOC: stats paramaters available in frontend + - BUG/MINOR: config: make the stats socket pass the correct proxy to the parsers + - BUG/MEDIUM: pattern: fixup use_after_free in the pat_ref_delete_by_id + - CLEANUP: don't ignore debian/ directory if present + - FIX: small typo in an example using the "Referer" header + - BUG/MEDIUM: config: count memory limits on 64 bits, not 32 + - DOC: add a CONTRIBUTING file + 2015/07/03 : 1.5.14 - BUILD/MINOR: tools: rename popcount to my_popcountl - BUG/MAJOR: buffers: make the buffer_slow_realign() function respect output data
View file
haproxy-1.5.15.tar.gz/CONTRIBUTING
Added
@@ -0,0 +1,654 @@ + HOW TO GET YOUR CODE ACCEPTED IN HAPROXY + READ THIS CAREFULLY BEFORE SUBMITTING CODE + +THIS DOCUMENT PROVIDES SOME RULES TO FOLLOW WHEN SENDING CONTRIBUTIONS. PATCHES +NOT FOLLOWING THESE RULES WILL SIMPLY BE REJECTED IN ORDER TO PROTECT ALL OTHER +RESPECTFUL CONTRIBUTORS' VALUABLE TIME. + + +Background +---------- + +During the development cycle of version 1.6, much more time was spent reviewing +poor quality submissions, fixing them and troubleshooting the bugs they +introduced than doing any development work. This is not acceptable as it ends +up with people actually slowing down the project for the features they're the +only ones interested in. On the other end of the scale, there are people who +make the effort of polishing their work to contribute excellent quality work +which doesn't even require a review. Contrary to what newcomers may think, it's +very easy to reach that level of quality and get your changes accepted quickly, +even late in the development cycle. It only requires that you make your homework +and not rely on others to do it for you. The most important point is that +HAProxy is a community-driven project, all involved participants must respect +all other ones' time and work. + + +Preparation +----------- + +It is possible that you'll want to add a specific feature to satisfy your needs +or one of your customers'. Contributions are welcome, however maintainers are +often very picky about changes. Patches that change massive parts of the code, +or that touch the core parts without any good reason will generally be rejected +if those changes have not been discussed first. + +The proper place to discuss your changes is the HAProxy Mailing List. There are +enough skilled readers to catch hazardous mistakes and to suggest improvements. +There is no other place where you'll find as many skilled people on the project, +and these people can help you get your code integrated quickly. You can +subscribe to it by sending an empty e-mail at the following address : + + haproxy+subscribe@formilux.org + +If you have an idea about something to implement, *please* discuss it on the +list first. It has already happened several times that two persons did the same +thing simultaneously. This is a waste of time for both of them. It's also very +common to see some changes rejected because they're done in a way that will +conflict with future evolutions, or that does not leave a good feeling. It's +always unpleasant for the person who did the work, and it is unpleasant in +general because value people's time and efforts are valuable and would be better +spent working on something else. That would not happen if these were discussed +first. There is no problem posting work in progress to the list, it happens +quite often in fact. Also, don't waste your time with the doc when submitting +patches for review, only add the doc with the patch you consider ready to merge. + +Another important point concerns code portability. Haproxy requires gcc as the +C compiler, and may or may not work with other compilers. However it's known to +build using gcc 2.95 or any later version. As such, it is important to keep in +mind that certain facilities offered by recent versions must not be used in the +code : + + - declarations mixed in the code (requires gcc >= 3.x and is a bad practice) + - GCC builtins without checking for their availability based on version and + architecture ; + - assembly code without any alternate portable form for other platforms + - use of stdbool.h, "bool", "false", "true" : simply use "int", "0", "1" + - in general, anything which requires C99 (such as declaring variables in + "for" statements) + +Since most of these restrictions are just a matter of coding style, it is +normally not a problem to comply. + +If your work is very confidential and you can't publicly discuss it, you can +also mail willy@haproxy.org directly about it, but your mail may be waiting +several days in the queue before you get a response. Retransmit if you don't +get a response by one week. + +If you'd like a feature to be added but you think you don't have the skills to +implement it yourself, you should follow these steps : + + 1. discuss the feature on the mailing list. It is possible that someone + else has already implemented it, or that someone will tell you how to + proceed without it, or even why not to do it. It is also possible that + in fact it's quite easy to implement and people will guide you through + the process. That way you'll finally have YOUR patch merged, providing + the feature YOU need. + + 2. if you really can't code it yourself after discussing it, then you may + consider contacting someone to do the job for you. Some people on the + list might sometimes be OK with trying to do it. + + +Rules : the 12 laws of patch contribution +----------------------------------------- + +People contributing patches must apply the following rules. That may sound heavy +at the beginning but it's common sense more than anything else and contributors +do not think about them anymore after a few patches. + +1) Before modifying some code, you have read the LICENSE file ("main license") + coming with the sources, and all the files this file references. Certain + files may be covered by different licenses, in which case it will be + indicated in the files themselves. In any case, you agree to respect these + licenses and to contribute your changes under the same licenses. If you want + to create new files, they will be under the main license, or any license of + your choice that you have verified to be compatible with the main license, + and that will be explicitly mentionned in the affected files. The project's + maintainers are free to reject contributions proposing license changes they + feel are not appropriate or could cause future trouble. + +2) Your work may only be based on the latest development version. No development + is made on a stable branch. If your work needs to be applied to a stable + branch, it will first be applied to the development branch and only then will + be backported to the stable branch. You are responsible for ensuring that + your work correctly applies to the development version. If at any moment you + are going to work on restructuring something important which may impact other + contributors, the rule that applies is that the first sent is the first + served. However it is considered good practice and politeness to warn others + in advance if you know you're going to make changes that may force them to + re-adapt their code, because they did probably not expect to have to spend + more time discovering your changes and rebasing their work. + +3) You have read and understood "doc/codingstyle.txt", and you're actively + determined to respect it and to enforce it on your coworkers if you're going + to submit a team's work. We don't care what text editor you use, whether it's + an hex editor, cat, vi, emacs, Notepad, Word, or even Eclipse. The editor is + only the interface between you and the text file. What matters is what is in + the text file in the end. The editor is not an excuse for submitting poorly + indented code, which only proves that the person has no consideration for + quality and/or has done it in a hurry (probably worse). Please note that most + bugs were found in low-quality code. Reviewers know this and tend to be much + more reluctant to accept poorly formated code because by experience they + won't trust their author's ability to write correct code. It is also worth + noting that poor quality code is painful to read and may result in nobody + willing to waste their time even reviewing your work. + +4) The time it takes for you to polish your code is always much smaller than the + time it takes others to do it for you, because they always have to wonder if + what they see is intended (meaning they didn't understand something) or if it + is a mistake that needs to be fixed. And since there are less reviewers than + submitters, it is vital to spread the effort closer to where the code is + written and not closer to where it gets merged. For example if you have to + write a report for a customer that your boss wants to review before you send + it to the customer, will you throw on his desk a pile of paper with stains, + typos and copy-pastes everywhere ? Will you say "come on, OK I made a mistake + in the company's name but they will find it by themselves, it's obvious it + comes from us" ? No. When in doubt, simply ask for help on the mailing list. + +5) There are four levels of importance of quality in the project : + + - The most important one, and by far, is the quality of the user-facing + documentation. This is the first contact for most users and it immediately + gives them an accurate idea of how the project is maintained. Dirty docs + necessarily belong to a dirty project. Be careful to the way the text you + add is presented and indented. Be very careful about typos, usual mistakes + such as double consonants when only one is needed or "it's" instead of + "its", don't mix US english and UK english in the same paragraph, etc. + When in doubt, check in a dictionary. Fixes for existing typos in the doc + are always welcome and chasing them is a good way to become familiar with + the project and to get other participants' respect and consideration. + + - The second most important level is user-facing messages emitted by the + code. You must try to see all the messages your code produces to ensure + they are understandable outside of the context where you wrote them, + because the user often doesn't expect them. That's true for warnings, and + that's even more important for errors which prevent the program from + working and which require an immediate and well understood fix in the + configuration. It's much better to say "line 35: compression level must be + an integer between 1 and 9" than "invalid argument at line 35". In HAProxy, + error handling roughly represents half of the code, and that's about 3/4 of + the configuration parser. Take the time to do something you're proud of. A + good rule of thumb is to keep in mind that your code talks to a human and + tries to teach him/her how to proceed. It must then speak like a human. + + - The third most important level is the code and its accompanying comments, + including the commit message which is a complement to your code and + comments. It's important for all other contributors that the code is + readable, fluid, understandable and that the commit message describes what + was done, the choices made, the possible alternatives you thought about, + the reason for picking this one and its limits if any. Comments should be + written where it's easy to have a doubt or after some error cases have been + wiped out and you want to explain what possibilities remain. All functions + must have a comment indicating what they take on input and what they + provide on output. Please adjust the comments when you copy-paste a + function or change its prototype, this type of lazy mistake is too common + and very confusing when reading code later to debug an issue. Do not forget + that others will feel really angry at you when they have to dig into your + code for a bug that your code caused and they feel like this code is dirty + or confusing, that the commit message doesn't explain anything useful and + that the patch should never have been accepted in the first place. That + will strongly impact your reputation and will definitely affect your + chances to contribute again! + + - The fourth level of importance is in the technical documentation that you + may want to add with your code. Technical documentation is always welcome + as it helps others make the best use of your work and to go exactly in the + direction you thought about during the design. This is also what reduces + the risk that your design gets changed in the near future due to a misuse + and/or a poor understanding. All such documentation is actually considered + as a bonus. It is more important that this documentation exists than that
View file
haproxy-1.5.14.tar.gz/README -> haproxy-1.5.15.tar.gz/README
Changed
@@ -1,9 +1,9 @@ ---------------------- HAProxy how-to ---------------------- - version 1.5.14 + version 1.5.15 willy tarreau - 2015/07/02 + 2015/11/01 1) How to build it @@ -39,7 +39,7 @@ - solaris for Solaris 8 or 10 (others untested) - freebsd for FreeBSD 5 to 10 (others untested) - osx for Mac OS/X - - openbsd for OpenBSD 3.1 to 5.2 (others untested) + - openbsd for OpenBSD 3.1 and above - aix51 for AIX 5.1 - aix52 for AIX 5.2 - cygwin for Cygwin @@ -281,259 +281,7 @@ 5) How to contribute -------------------- -It is possible that you'll want to add a specific feature to satisfy your needs -or one of your customers'. Contributions are welcome, however I'm often very -picky about changes. I will generally reject patches that change massive parts -of the code, or that touch the core parts without any good reason if those -changes have not been discussed first. - -The proper place to discuss your changes is the HAProxy Mailing List. There are -enough skilled readers to catch hazardous mistakes and to suggest improvements. -I trust a number of them enough to merge a patch if they say it's OK, so using -the list is the fastest way to get your code reviewed and merged. You can -subscribe to it by sending an empty e-mail at the following address : - - haproxy+subscribe@formilux.org - -If you have an idea about something to implement, *please* discuss it on the -list first. It has already happened several times that two persons did the same -thing simultaneously. This is a waste of time for both of them. It's also very -common to see some changes rejected because they're done in a way that will -conflict with future evolutions, or that does not leave a good feeling. It's -always unpleasant for the person who did the work, and it is unpleasant for me -too because I value people's time and efforts. That would not happen if these -were discussed first. There is no problem posting work in progress to the list, -it happens quite often in fact. Also, don't waste your time with the doc when -submitting patches for review, only add the doc with the patch you consider -ready to merge. - -Another important point concerns code portability. Haproxy requires gcc as the -C compiler, and may or may not work with other compilers. However it's known -to build using gcc 2.95 or any later version. As such, it is important to keep -in mind that certain facilities offered by recent versions must not be used in -the code : - - - declarations mixed in the code (requires gcc >= 3.x) - - GCC builtins without checking for their availability based on version and - architecture ; - - assembly code without any alternate portable form for other platforms - - use of stdbool.h, "bool", "false", "true" : simply use "int", "0", "1" - - in general, anything which requires C99 (such as declaring variables in - "for" statements) - -Since most of these restrictions are just a matter of coding style, it is -normally not a problem to comply. - -If your work is very confidential and you can't publicly discuss it, you can -also mail me directly about it, but your mail may be waiting several days in -the queue before you get a response. - -If you'd like a feature to be added but you think you don't have the skills to -implement it yourself, you should follow these steps : - - 1. discuss the feature on the mailing list. It is possible that someone - else has already implemented it, or that someone will tell you how to - proceed without it, or even why not to do it. It is also possible that - in fact it's quite easy to implement and people will guide you through - the process. That way you'll finally have YOUR patch merged, providing - the feature YOU need. - - 2. if you really can't code it yourself after discussing it, then you may - consider contacting someone to do the job for you. Some people on the - list might sometimes be OK with trying to do it. - -Note to contributors: it's very handy when patches comes with a properly -formated subject. There are 3 criteria of particular importance in any patch : - - - its nature (is it a fix for a bug, a new feature, an optimization, ...) - - its importance, which generally reflects the risk of merging/not merging it - - what area it applies to (eg: http, stats, startup, config, doc, ...) - -It's important to make these 3 criteria easy to spot in the patch's subject, -because it's the first (and sometimes the only) thing which is read when -reviewing patches to find which ones need to be backported to older versions. - -Specifically, bugs must be clearly easy to spot so that they're never missed. -Any patch fixing a bug must have the "BUG" tag in its subject. Most common -patch types include : - - - BUG fix for a bug. The severity of the bug should also be indicated - when known. Similarly, if a backport is needed to older versions, - it should be indicated on the last line of the commit message. If - the bug has been identified as a regression brought by a specific - patch or version, this indication will be appreciated too. New - maintenance releases are generally emitted when a few of these - patches are merged. - - - CLEANUP code cleanup, silence of warnings, etc... theorically no impact. - These patches will rarely be seen in stable branches, though they - may appear when they remove some annoyance or when they make - backporting easier. By nature, a cleanup is always minor. - - - REORG code reorganization. Some blocks may be moved to other places, - some important checks might be swapped, etc... These changes - always present a risk of regression. For this reason, they should - never be mixed with any bug fix nor functional change. Code is - only moved as-is. Indicating the risk of breakage is highly - recommended. - - - BUILD updates or fixes for build issues. Changes to makefiles also fall - into this category. The risk of breakage should be indicated if - known. It is also appreciated to indicate what platforms and/or - configurations were tested after the change. - - - OPTIM some code was optimised. Sometimes if the regression risk is very - low and the gains significant, such patches may be merged in the - stable branch. Depending on the amount of code changed or replaced - and the level of trust the author has in the change, the risk of - regression should be indicated. - - - RELEASE release of a new version (development or stable). - - - LICENSE licensing updates (may impact distro packagers). - - -When the patch cannot be categorized, it's best not to put any tag. This is -commonly the case for new features, which development versions are mostly made -of. - -Additionally, the importance of the patch should be indicated when known. A -single upper-case word is preferred, among : - - - MINOR minor change, very low risk of impact. It is often the case for - code additions that don't touch live code. For a bug, it generally - indicates an annoyance, nothing more. - - - MEDIUM medium risk, may cause unexpected regressions of low importance or - which may quickly be discovered. For a bug, it generally indicates - something odd which requires changing the configuration in an - undesired way to work around the issue. - - - MAJOR major risk of hidden regression. This happens when I rearrange - large parts of code, when I play with timeouts, with variable - initializations, etc... We should only exceptionally find such - patches in stable branches. For a bug, it indicates severe - reliability issues for which workarounds are identified with or - without performance impacts. - - - CRITICAL medium-term reliability or security is at risk and workarounds, - if they exist, might not always be acceptable. An upgrade is - absolutely required. A maintenance release may be emitted even if - only one of these bugs are fixed. Note that this tag is only used - with bugs. Such patches must indicate what is the first version - affected, and if known, the commit ID which introduced the issue. - -If this criterion doesn't apply, it's best not to put it. For instance, most -doc updates and most examples or test files are just added or updated without -any need to qualify a level of importance. - -The area the patch applies to is quite important, because some areas are known -to be similar in older versions, suggesting a backport might be desirable, and -conversely, some areas are known to be specific to one version. When the tag is -used alone, uppercase is preferred for readability, otherwise lowercase is fine -too. The following tags are suggested but not limitative : - - - doc documentation updates or fixes. No code is affected, no need to - upgrade. These patches can also be sent right after a new feature, - to document it. - - - examples example files. Be careful, sometimes these files are packaged. - - - tests regression test files. No code is affected, no need to upgrade. - - - init initialization code, arguments parsing, etc... - - - config configuration parser, mostly used when adding new config keywords - - - http the HTTP engine - - - stats the stats reporting engine as well as the stats socket CLI - - - checks the health checks engine (eg: when adding new checks) - - - acl the ACL processing core or some ACLs from other areas - - - peers the peer synchronization engine - - - listeners everything related to incoming connection settings
View file
haproxy-1.5.14.tar.gz/VERDATE -> haproxy-1.5.15.tar.gz/VERDATE
Changed
@@ -1,2 +1,2 @@ $Format:%ci$ -2015/07/02 +2015/11/01
View file
haproxy-1.5.14.tar.gz/VERSION -> haproxy-1.5.15.tar.gz/VERSION
Changed
@@ -1,1 +1,1 @@ -1.5.14 +1.5.15
View file
haproxy-1.5.14.tar.gz/doc/configuration.txt -> haproxy-1.5.15.tar.gz/doc/configuration.txt
Changed
@@ -2,9 +2,9 @@ HAProxy Configuration Manual ---------------------- - version 1.5.14 + version 1.5.15 willy tarreau - 2015/07/02 + 2015/11/01 This document covers the configuration language as implemented in the version @@ -1367,10 +1367,11 @@ option log-separate-errors (*) X X X - option logasap (*) X X X - option mysql-check X - X X -option pgsql-check X - X X option nolinger (*) X X X X option originalto X X X X option persist (*) X - X X +option pgsql-check X - X X +option prefer-last-server (*) X - X X option redispatch (*) X - X X option redis-check X - X X option smtpchk X - X X @@ -1419,18 +1420,18 @@ server - - X X source X - X X srvtimeout (deprecated) X - X X -stats admin - - X X -stats auth X - X X -stats enable X - X X -stats hide-version X - X X -stats http-request - - X X -stats realm X - X X -stats refresh X - X X -stats scope X - X X -stats show-desc X - X X -stats show-legends X - X X -stats show-node X - X X -stats uri X - X X +stats admin - X X X +stats auth X X X X +stats enable X X X X +stats hide-version X X X X +stats http-request - X X X +stats realm X X X X +stats refresh X X X X +stats scope X X X X +stats show-desc X X X X +stats show-legends X X X X +stats show-node X X X X +stats uri X X X X -- keyword -------------------------- defaults - frontend - listen -- backend - stick match - - X X stick on - - X X @@ -1888,6 +1889,12 @@ listen external_bind_app1 bind fd@${FD_APP1} + Note: regarding Linux's abstract namespace sockets, HAProxy uses the whole + sun_path length is used for the address length. Some other programs + such as socat use the string length only by default. Pass the option + ",unix-tightsocklen=0" to any abstract socket definition in socat to + make it compatible with HAProxy's. + See also : "source", "option forwardfor", "unix-bind" and the PROXY protocol documentation, and section 5 about bind options. @@ -2055,7 +2062,7 @@ Example: capture request header Host len 15 capture request header X-Forwarded-For len 15 - capture request header Referrer len 15 + capture request header Referer len 15 See also : "capture cookie", "capture response header" as well as section 8 about logging. @@ -3135,7 +3142,7 @@ Example: http-request set-header X-Haproxy-Current-Date %T http-request set-header X-SSL %[ssl_fc] - http-request set-header X-SSL-Session_ID %[ssl_fc_session_id] + http-request set-header X-SSL-Session_ID %[ssl_fc_session_id,hex] http-request set-header X-SSL-Client-Verify %[ssl_c_verify] http-request set-header X-SSL-Client-DN %{+Q}[ssl_c_s_dn] http-request set-header X-SSL-Client-CN %{+Q}[ssl_c_s_dn(cn)] @@ -5443,7 +5450,7 @@ is desired. Only codes 301, 302, 303, 307 and 308 are supported, with 302 used by default if no code is specified. 301 means "Moved permanently", and a browser may cache the Location. 302 - means "Moved permanently" and means that the browser should not + means "Moved temporarily" and means that the browser should not cache the redirection. 303 is equivalent to 302 except that the browser will fetch the location with a GET method. 307 is just like 302 but makes it clear that the same method must be reused. @@ -5996,6 +6003,12 @@ server www1_dc1 ${LAN_DC1}.101:80 server www1_dc2 ${LAN_DC2}.101:80 + Note: regarding Linux's abstract namespace sockets, HAProxy uses the whole + sun_path length is used for the address length. Some other programs + such as socat use the string length only by default. Pass the option + ",unix-tightsocklen=0" to any abstract socket definition in socat to + make it compatible with HAProxy's. + See also: "default-server", "http-send-name-header" and section 5 about server options @@ -6117,6 +6130,8 @@ is possible at the server level using the "source" server option. Refer to section 5 for more information. + In order to work, "usesrc" requires root privileges. + Examples : backend private # Connect to the servers using our 192.168.1.200 source address @@ -12379,7 +12394,7 @@ | | %hrl | captured_request_headers CLF style | string list | | | %hs | captured_response_headers default style | string | | | %hsl | captured_response_headers CLF style | string list | - | | %ms | accept date milliseconds | numeric | + | | %ms | accept date milliseconds (left-padded with 0) | numeric | | | %pid | PID | numeric | | H | %r | http_request | string | | | %rc | retries | numeric |
View file
haproxy-1.5.14.tar.gz/examples/haproxy.spec -> haproxy-1.5.15.tar.gz/examples/haproxy.spec
Changed
@@ -1,6 +1,6 @@ Summary: HA-Proxy is a TCP/HTTP reverse proxy for high availability environments Name: haproxy -Version: 1.5.14 +Version: 1.5.15 Release: 1 License: GPL Group: System Environment/Daemons @@ -76,6 +76,9 @@ %attr(0755,root,root) %config %{_sysconfdir}/rc.d/init.d/%{name} %changelog +* Sun Nov 1 2015 Willy Tarreau <w@1wt.eu> +- updated to 1.5.15 + * Fri Jul 3 2015 Willy Tarreau <w@1wt.eu> - updated to 1.5.14
View file
haproxy-1.5.14.tar.gz/include/common/syscall.h -> haproxy-1.5.15.tar.gz/include/common/syscall.h
Changed
@@ -104,6 +104,10 @@ #define __NR_epoll_create 254 #define __NR_epoll_ctl 255 #define __NR_epoll_wait 256 +#elif defined (__s390__) || defined(__s390x__) +#define __NR_epoll_create 249 +#define __NR_epoll_ctl 250 +#define __NR_epoll_wait 251 #endif /* $arch */ #endif /* __NR_epoll_ctl */ @@ -121,6 +125,8 @@ #define __NR_splice 468 #elif defined (__i386__) #define __NR_splice 313 +#elif defined(__s390__) || defined(__s390x__) +#define __NR_splace 306 #endif /* $arch */ #endif /* __NR_splice */
View file
haproxy-1.5.14.tar.gz/include/types/proto_http.h -> haproxy-1.5.15.tar.gz/include/types/proto_http.h
Changed
@@ -219,7 +219,6 @@ /* Known HTTP methods */ enum http_meth_t { - HTTP_METH_NONE = 0, HTTP_METH_OPTIONS, HTTP_METH_GET, HTTP_METH_HEAD,
View file
haproxy-1.5.14.tar.gz/src/acl.c -> haproxy-1.5.15.tar.gz/src/acl.c
Changed
@@ -488,7 +488,7 @@ } /* Note: -m found is always valid, bool/int are compatible, str/bin/reg/len are compatible */ - if (!sample_casts[cur_type][pat_match_types[idx]]) { + if (idx != PAT_MATCH_FOUND && !sample_casts[cur_type][pat_match_types[idx]]) { memprintf(err, "matching method '%s' cannot be used with fetch keyword '%s'", args[1], expr->kw); goto out_free_expr; }
View file
haproxy-1.5.14.tar.gz/src/cfgparse.c -> haproxy-1.5.15.tar.gz/src/cfgparse.c
Changed
@@ -703,6 +703,11 @@ goto out; } global.tune.bufsize = atol(args[1]); + if (global.tune.bufsize <= 0) { + Alert("parsing [%s:%d] : '%s' expects a positive integer argument.\n", file, linenum, args[0]); + err_code |= ERR_ALERT | ERR_FATAL; + goto out; + } if (global.tune.maxrewrite >= global.tune.bufsize / 2) global.tune.maxrewrite = global.tune.bufsize / 2; chunk_init(&trash, realloc(trash.str, global.tune.bufsize), global.tune.bufsize); @@ -5434,8 +5439,8 @@ } if (rc >= HTTP_ERR_SIZE) { - Warning("parsing [%s:%d] : status code %d not handled, error relocation will be ignored.\n", - file, linenum, errnum); + Warning("parsing [%s:%d] : status code %d not handled by '%s', error relocation will be ignored.\n", + file, linenum, errnum, args[0]); free(err); } } @@ -5494,8 +5499,8 @@ } if (rc >= HTTP_ERR_SIZE) { - Warning("parsing [%s:%d] : status code %d not handled, error customization will be ignored.\n", - file, linenum, errnum); + Warning("parsing [%s:%d] : status code %d not handled by '%s', error customization will be ignored.\n", + file, linenum, errnum, args[0]); err_code |= ERR_WARN; free(err); } @@ -6193,6 +6198,12 @@ break; } + if ((curproxy->cap & PR_CAP_FE) && LIST_ISEMPTY(&curproxy->conf.listeners)) { + Warning("config : %s '%s' has no 'bind' directive. Please declare it as a backend if this was intended.\n", + proxy_type_str(curproxy), curproxy->id); + err_code |= ERR_WARN; + } + if ((curproxy->cap & PR_CAP_BE) && (curproxy->mode != PR_MODE_HEALTH)) { if (curproxy->lbprm.algo & BE_LB_KIND) { if (curproxy->options & PR_O_TRANSP) {
View file
haproxy-1.5.14.tar.gz/src/dumpstats.c -> haproxy-1.5.15.tar.gz/src/dumpstats.c
Changed
@@ -334,7 +334,7 @@ return -1; } - if (kw->parse(args, cur_arg, curpx, bind_conf, err) != 0) { + if (kw->parse(args, cur_arg, global.stats_fe, bind_conf, err) != 0) { if (err && *err) memprintf(err, "'%s %s' : '%s'", args[0], args[1], *err); else
View file
haproxy-1.5.14.tar.gz/src/haproxy.c -> haproxy-1.5.15.tar.gz/src/haproxy.c
Changed
@@ -1370,7 +1370,7 @@ if (global.rlimit_memmax) { limit.rlim_cur = limit.rlim_max = - global.rlimit_memmax * 1048576 / global.nbproc; + global.rlimit_memmax * 1048576ULL / global.nbproc; #ifdef RLIMIT_AS if (setrlimit(RLIMIT_AS, &limit) == -1) { Warning("[%s.main()] Cannot fix MEM limit to %d megs.\n",
View file
haproxy-1.5.14.tar.gz/src/log.c -> haproxy-1.5.15.tar.gz/src/log.c
Changed
@@ -167,22 +167,26 @@ static inline const char *fmt_directive(const struct proxy *curproxy) { switch (curproxy->conf.args.ctx) { - case ARGC_UIF: - return "unique-id-format"; + case ARGC_ACL: + return "acl"; + case ARGC_STK: + return "stick"; + case ARGC_TRK: + return "track-sc"; + case ARGC_LOG: + return "log-format"; case ARGC_HRQ: return "http-request"; case ARGC_HRS: return "http-response"; - case ARGC_STK: - return "stick"; - case ARGC_TRK: - return "track-sc"; break; + case ARGC_UIF: + return "unique-id-format"; case ARGC_RDR: - return "redirect"; break; - case ARGC_ACL: - return "acl"; break; + return "redirect"; + case ARGC_CAP: + return "capture"; default: - return "log-format"; + return "undefined(please report this bug)"; /* must never happen */ } }
View file
haproxy-1.5.14.tar.gz/src/pattern.c -> haproxy-1.5.15.tar.gz/src/pattern.c
Changed
@@ -1423,14 +1423,13 @@ /* delete pattern from reference */ list_for_each_entry_safe(elt, safe, &ref->head, list) { if (elt == refelt) { + list_for_each_entry(expr, &ref->pat, list) + pattern_delete(expr, elt); + LIST_DEL(&elt->list); free(elt->sample); free(elt->pattern); free(elt); - - list_for_each_entry(expr, &ref->pat, list) - pattern_delete(expr, elt); - return 1; } }
View file
haproxy-1.5.14.tar.gz/src/proto_http.c -> haproxy-1.5.15.tar.gz/src/proto_http.c
Changed
@@ -353,6 +353,9 @@ ['H' - 'A'] = { [0] = { .meth = HTTP_METH_HEAD , .len=4, .text="HEAD" }, }, + ['O' - 'A'] = { + [0] = { .meth = HTTP_METH_OPTIONS , .len=7, .text="OPTIONS" }, + }, ['P' - 'A'] = { [0] = { .meth = HTTP_METH_POST , .len=4, .text="POST" }, [1] = { .meth = HTTP_METH_PUT , .len=3, .text="PUT" }, @@ -361,12 +364,11 @@ [0] = { .meth = HTTP_METH_TRACE , .len=5, .text="TRACE" }, }, /* rest is empty like this : - * [1] = { .meth = HTTP_METH_NONE , .len=0, .text="" }, + * [0] = { .meth = HTTP_METH_OTHER , .len=0, .text="" }, */ }; const struct http_method_name http_known_methods[HTTP_METH_OTHER] = { - [HTTP_METH_NONE] = { "", 0 }, [HTTP_METH_OPTIONS] = { "OPTIONS", 7 }, [HTTP_METH_GET] = { "GET", 3 }, [HTTP_METH_HEAD] = { "HEAD", 4 }, @@ -793,8 +795,8 @@ } /* - * returns HTTP_METH_NONE if there is nothing valid to read (empty or non-text - * string), HTTP_METH_OTHER for unknown methods, or the identified method. + * returns a known method among HTTP_METH_* or HTTP_METH_OTHER for all unknown + * ones. */ enum http_meth_t find_http_meth(const char *str, const int len) { @@ -810,10 +812,8 @@ if (likely(memcmp(str, h->text, h->len) == 0)) return h->meth; }; - return HTTP_METH_OTHER; } - return HTTP_METH_NONE; - + return HTTP_METH_OTHER; } /* Parse the URI from the given transaction (which is assumed to be in request @@ -11249,6 +11249,8 @@ curr_date += args[0].data.sint; tm = gmtime(&curr_date); + if (!tm) + return 0; temp = get_trash_chunk(); temp->len = snprintf(temp->str, temp->size - temp->len,
View file
haproxy-1.5.14.tar.gz/src/proxy.c -> haproxy-1.5.15.tar.gz/src/proxy.c
Changed
@@ -727,19 +727,23 @@ Warning("Stopping %s %s in %d ms.\n", proxy_cap_str(p->cap), p->id, p->grace); send_log(p, LOG_WARNING, "Stopping %s %s in %d ms.\n", proxy_cap_str(p->cap), p->id, p->grace); p->stop_time = tick_add(now_ms, p->grace); - } - if (p->table.size && p->table.sync_task) - task_wakeup(p->table.sync_task, TASK_WOKEN_MSG); - /* wake every proxy task up so that they can handle the stopping */ - if (p->task) - task_wakeup(p->task, TASK_WOKEN_MSG); + /* Note: do not wake up stopped proxies' task nor their tables' + * tasks as these ones might point to already released entries. + */ + if (p->table.size && p->table.sync_task) + task_wakeup(p->table.sync_task, TASK_WOKEN_MSG); + + if (p->task) + task_wakeup(p->task, TASK_WOKEN_MSG); + } p = p->next; } prs = peers; while (prs) { - stop_proxy((struct proxy *)prs->peers_fe); + if (prs->peers_fe) + stop_proxy(prs->peers_fe); prs = prs->next; } /* signal zero is used to broadcast the "stopping" event */ @@ -873,8 +877,8 @@ prs = peers; while (prs) { - p = prs->peers_fe; - err |= !pause_proxy(p); + if (prs->peers_fe) + err |= !pause_proxy(prs->peers_fe); prs = prs->next; } @@ -907,8 +911,8 @@ prs = peers; while (prs) { - p = prs->peers_fe; - err |= !resume_proxy(p); + if (prs->peers_fe) + err |= !resume_proxy(prs->peers_fe); prs = prs->next; }
View file
haproxy-1.5.14.tar.gz/src/session.c -> haproxy-1.5.15.tar.gz/src/session.c
Changed
@@ -2293,7 +2293,7 @@ /* Now we can add the server name to a header (if requested) */ /* check for HTTP mode and proxy server_name_hdr_name != NULL */ - if ((s->si[1].state >= SI_ST_CON) && + if ((s->si[1].state >= SI_ST_CON) && (s->si[1].state < SI_ST_CLO) && (s->be->server_id_hdr_name != NULL) && (s->be->mode == PR_MODE_HTTP) && objt_server(s->target)) { @@ -2806,6 +2806,33 @@ return &l4->stkctr[num]; } +/* same as smp_fetch_sc_stkctr() but dedicated to src_* and can create + * the entry if it doesn't exist yet. This is needed for a few fetch + * functions which need to create an entry, such as src_inc_gpc* and + * src_clr_gpc*. + */ +struct stkctr * +smp_create_src_stkctr(struct session *sess, const struct arg *args, const char *kw) +{ + static struct stkctr stkctr; + struct stktable_key *key; + struct connection *conn = objt_conn(sess->si[0].end); + + if (strncmp(kw, "src_", 4) != 0) + return NULL; + + if (!conn) + return NULL; + + key = addr_to_stktable_key(&conn->addr.from, args->data.prx->table.type); + if (!key) + return NULL; + + stkctr.table = &args->data.prx->table; + stkctr_set_entry(&stkctr, stktable_update_key(stkctr.table, key)); + return &stkctr; +} + /* set return a boolean indicating if the requested session counter is * currently being tracked or not. * Supports being called as "sc[0-9]_tracked" only. @@ -2887,6 +2914,9 @@ if (!stkctr) return 0; + if (stkctr_entry(stkctr) == NULL) + stkctr = smp_create_src_stkctr(l4, args, kw); + smp->flags = SMP_F_VOL_TEST; smp->type = SMP_T_UINT; smp->data.uint = 0; @@ -2924,6 +2954,9 @@ if (!stkctr) return 0; + if (stkctr_entry(stkctr) == NULL) + stkctr = smp_create_src_stkctr(l4, args, kw); + smp->flags = SMP_F_VOL_TEST; smp->type = SMP_T_UINT; smp->data.uint = 0;
View file
haproxy-1.5.14.tar.gz/src/ssl_sock.c -> haproxy-1.5.15.tar.gz/src/ssl_sock.c
Changed
@@ -1405,8 +1405,14 @@ ssloptions |= SSL_OP_NO_TLSv1_2; if (bind_conf->ssl_options & BC_SSL_O_NO_TLS_TICKETS) ssloptions |= SSL_OP_NO_TICKET; - if (bind_conf->ssl_options & BC_SSL_O_USE_SSLV3) + if (bind_conf->ssl_options & BC_SSL_O_USE_SSLV3) { +#ifndef OPENSSL_NO_SSL3 SSL_CTX_set_ssl_version(ctx, SSLv3_server_method()); +#else + Alert("SSLv3 support requested but unavailable.\n"); + cfgerr++; +#endif + } if (bind_conf->ssl_options & BC_SSL_O_USE_TLSV10) SSL_CTX_set_ssl_version(ctx, TLSv1_server_method()); #if SSL_OP_NO_TLSv1_1 @@ -1750,8 +1756,14 @@ options |= SSL_OP_NO_TLSv1_2; if (srv->ssl_ctx.options & SRV_SSL_O_NO_TLS_TICKETS) options |= SSL_OP_NO_TICKET; - if (srv->ssl_ctx.options & SRV_SSL_O_USE_SSLV3) + if (srv->ssl_ctx.options & SRV_SSL_O_USE_SSLV3) { +#ifndef OPENSSL_NO_SSL3 SSL_CTX_set_ssl_version(srv->ssl_ctx.ctx, SSLv3_client_method()); +#else + Alert("SSLv3 support requested but unavailable.\n"); + cfgerr++; +#endif + } if (srv->ssl_ctx.options & SRV_SSL_O_USE_TLSV10) SSL_CTX_set_ssl_version(srv->ssl_ctx.ctx, TLSv1_client_method()); #if SSL_OP_NO_TLSv1_1
View file
haproxy-1.5.14.tar.gz/src/standard.c -> haproxy-1.5.15.tar.gz/src/standard.c
Changed
@@ -709,6 +709,11 @@ goto out; } + if (!*str2) { + memprintf(err, "'%s' resolves to an empty address (environment variable missing?)\n", str); + goto out; + } + memset(&ss, 0, sizeof(ss)); if (strncmp(str2, "unix@", 5) == 0) {
Locations
Projects
Search
Status Monitor
Help
Open Build Service
OBS Manuals
API Documentation
OBS Portal
Reporting a Bug
Contact
Mailing List
Forums
Chat (IRC)
Twitter
Open Build Service (OBS)
is an
openSUSE project
.