|
[-]
[+]
|
Changed |
haproxy.spec
|
|
|
|
[-]
[+]
|
Changed |
_service:download_files:haproxy-1.5.15.tar.gz/.gitignore
^
|
| @@ -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
|
|
[-]
[+]
|
Changed |
_service:download_files:haproxy-1.5.15.tar.gz/CHANGELOG
^
|
| @@ -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
|
|
[-]
[+]
|
Added |
_service:download_files:haproxy-1.5.15.tar.gz/CONTRIBUTING
^
|
| @@ -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
+ it looks clean. Sometimes just copy-pasting your draft notes in a file to
+ keep a record of design ideas is better than losing them. Please do your
+ best so that other ones can read your doc. If these docs require a special
+ tool such as a graphics utility, ensure that the file name makes it
+ unambiguous how to process it. So there are no rules here for the contents,
+ except one. Please write the date in your file. Design docs tend to stay
+ forever and to remain long after they become obsolete. At this point that
+ can cause harm more than it can help. Writing the date in the document
+ helps developers guess the degree of validity and/or compare them with the
+ date of certain commits touching the same area.
+
+6) All text files and commit messages are written using the US-ASCII charset.
+ Please be careful that your contributions do not contain any character not
+ printable using this charset, as they will render differently in different
+ editors and/or terminals. Avoid latin1 and more importantly UTF-8 which some
+ editors tend to abuse to replace some US-ASCII characters with their
+ typographic equivalent which aren't readable anymore in other editors. The
+ only place where alternative charsets are tolerated is in your name in the
+ commit message, but it's at your own risk as it can be mangled during the
+ merge. Anyway if you have an e-mail address, you probably have a valid
+ US-ASCII representation for it as well.
+
+7) Be careful about comments when you move code around. It's not acceptable that
+ a block of code is moved to another place leaving irrelevant comments at the
+ old place, just like it's not acceptable that a function is duplicated without
+ the comments being adjusted. The example below started to become quite common
+ during the 1.6 cycle, it is not acceptable and wastes everyone's time :
+
+ /* Parse switching <str> to build rule <rule>. Returns 0 on error. */
+ int parse_switching_rule(const char *str, struct rule *rule)
+ {
+ ...
+ }
+
+ /* Parse switching <str> to build rule <rule>. Returns 0 on error. */
+ void execute_switching_rule(struct rule *rule)
+ {
+ ...
+ }
+
+ This patch is not acceptable either (and it's unfortunately not that rare) :
+
+ + if (!session || !arg || list_is_empty(&session->rules->head))
+ + return 0;
+ +
+ /* Check if session->rules is valid before dereferencing it */
+ if (!session->rules_allocated)
+ return 0;
+
+ - if (!arg || list_is_empty(&session->rules->head))
+ - return 0;
+ -
+
+8) Limit the length of your identifiers in the code. When your identifiers start
+ to sound like sentences, it's very hard for the reader to keep on track with
+ what operation they are observing. Also long names force expressions to fit
+ on several lines which also cause some difficulties to the reader. See the
+ example below :
+
+ int file_name_len_including_global_path;
+ int file_name_len_without_global_path;
+ int global_path_len_or_zero_if_default;
+
+ if (global_path)
+ global_path_len_or_zero_if_default = strlen(global_path);
+ else
+ global_path_len_or_zero_if_default = 0;
+
+ file_name_len_without_global_path = strlen(file_name);
+ file_name_len_including_global_path =
+ file_name_len_without_global_path + 1 + /* for '/' */
+ global_path_len_or_zero_if_default ?
+ global_path_len_or_zero_if_default : default_path_len;
+
+ Compare it to this one :
+
+ int f, p;
+
+ p = global_path ? strlen(global_path) : default_path_len;
+ f = p + 1 + strlen(file_name); /* 1 for '/' */
+
+ A good rule of thumb is that if your identifiers start to contain more than
+ 3 words or more than 15 characters, they can become confusing. For function
+ names it's less important especially if these functions are rarely used or
+ are used in a complex context where it is important to differenciate between
+ their multiple variants.
+
+9) Your patches should be sent in "diff -up" format, which is also the format
+ used by Git. This means the "unified" diff format must be used exclusively,
+ and with the function name printed in the diff header of each block. That
+ significantly helps during reviews. Keep in mind that most reviews are done
+ on the patch and not on the code after applying the patch. Your diff must
+ keep some context (3 lines above and 3 lines below) so that there's no doubt
+ where the code has to be applied. Don't change code outside of the context of
+ your patch (eg: take care of not adding/removing empty lines once you remove
+ your debugging code). If you are using Git (which is strongly recommended),
+ please produce your patches using "git format-patch" and not "git diff", and
+ always use "git show" after doing a commit to ensure it looks good, and
+ enable syntax coloring that will automatically report in red the trailing
+ spaces or tabs that your patch added to the code and that must absolutely be
+ removed. These ones cause a real pain to apply patches later because they
+ mangle the context in an invisible way. Such patches with trailing spaces at
+ end of lines will be rejected.
+
+10) Please cut your work in series of patches that can be independantly reviewed
+ and merged. Each patch must do something on its own that you can explain to
+ someone without being ashamed of what you did. For example, you must not say
+ "This is the patch that implements SSL, it was tricky". There's clearly
+ something wrong there, your patch will be huge, will definitely break things
+ and nobody will be able to figure what exactly introduced the bug. However
+ it's much better to say "I needed to add some fields in the session to store
+ the SSL context so this patch does this and doesn't touch anything else, so
+ it's safe". Also when dealing with series, you will sometimes fix a bug that
+ one of your patches introduced. Please do merge these fixes (eg: using git
+ rebase -i and squash or fixup), as it is not acceptable to see patches which
+ introduce known bugs even if they're fixed later. Another benefit of cleanly
+ splitting patches is that if some of your patches need to be reworked after
+ a review, the other ones can still be merged so that you don't need to care
+ about them anymore. When sending multiple patches for review, prefer to send
+ one e-mail per patch than all patches in a single e-mail. The reason is that
+ not everyone is skilled in all areas nor has the time to review everything
+ at once. With one patch per e-mail, it's easy to comment on a single patch
+ without giving an opinion on the other ones, especially if a long thread
+ starts about one specific patch on the mailing list. "git send-email" does
+ that for you though it requires a few trials before getting it right.
+
+11) Please properly format your commit messages. While it's not strictly
+ required to use Git, it is strongly recommended because it helps you do the
+ cleanest job with the least effort. Patches always have the format of an
+ e-mail made of a subject, a description and the actual patch. If you're
+ sending a patch as an e-mail formated this way, it can quickly be applied
+ with limited effort so that's acceptable. But in any case, it is important
+ that there is a clean description of what the patch does, the motivation for
+ what it does, why it's the best way to do it, its impacts, and what it does
+ not yet cover. Also, in HAProxy, like many projects which take a great care
+ of maintaining stable branches, patches are reviewed later so that some of
+ them can be backported to stable releases. While reviewing hundreds of
+ patches can seem cumbersome, with a proper formating of the subject line it
+ actually becomes very easy. For example, here's how one can find patches
+ that need to be reviewed for backports (bugs and doc) between since commit
+ ID 827752e :
+
+ $ git log --oneline 827752e.. | grep 'BUG\|DOC'
+ 0d79cf6 DOC: fix function name
+ bc96534 DOC: ssl: missing LF
+ 10ec214 BUG/MEDIUM: lua: the lua fucntion Channel:close() causes a segf
+ bdc97a8 BUG/MEDIUM: lua: outgoing connection was broken since 1.6-dev2
+ ba56d9c DOC: mention support for RFC 5077 TLS Ticket extension in start
+ f1650a8 DOC: clarify some points about SSL and the proxy protocol
+ b157d73 BUG/MAJOR: peers: fix current table pointer not re-initialized
+ e1ab808 BUG/MEDIUM: peers: fix wrong message id on stick table updates
+ cc79b00 BUG/MINOR: ssl: TLS Ticket Key rotation broken via socket comma
+ d8e42b6 DOC: add new file intro.txt
+ c7d7607 BUG/MEDIUM: lua: bad error processing
+ 386a127 DOC: match several lua configuration option names to those impl
+ 0f4eadd BUG/MEDIUM: counters: ensure that src_{inc,clr}_gpc0 creates a
+
+ It is made possible by the fact that subject lines are properly formated and
+ always respect the same principle : one part indicating the nature and
+ severity of the patch, another one to indicate which subsystem is affected,
+ and the last one is a succint description of the change, with the important
+ part at the beginning so that it's obvious what it does even when lines are
+ truncated like above. The whole stable maintenance process relies on this.
+ For this reason, it is mandatory to respect some easy rules regarding the
+ way the subject is built. Please see the section below for more information
+ regarding this formating.
+
+12) When submitting changes, please always CC the mailing list address so that
+ everyone gets a chance to spot any issue in your code. It will also serve
+ as an advertisement for your work, you'll get more testers quicker and
+ you'll feel better knowing that people really use your work. It is also
+ important to CC any author mentionned in the file you change, or a subsystem
+ maintainers whose address is mentionned in a MAINTAINERS file. Not everyone
+ reads the list on a daily basis so it's very easy to miss some changes.
+ Don't consider it as a failure when a reviewer tells you you have to modify
+ your patch, actually it's a success because now you know what is missing for
+ your work to get accepted. That's why you should not hesitate to CC enough
+ people. Don't copy people who have no deal with your work area just because
+ you found their address on the list. That's the best way to appear careless
+ about their time and make them reject your changes in the future.
+
+
+Patch classifying rules
+-----------------------
+
+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.
+It also helps when trying to find which patch is the most likely to have caused
+a regression.
+
+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. If the bug is a vulnerability for which a CVE
+ identifier was assigned before you publish the fix, you can mention
+ it in the commit message, it will help distro maintainers.
+
+ - 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 of minor
+ importance and it's not needed to mention it.
+
+ - DOC updates to any of the documentation files, including README. Many
+ documentation updates are backported since they don't impact the
+ product's stability and may help users avoid bugs. So please
+ indicate in the commit message if a backport is desired. When a
+ feature gets documented, it's preferred that the doc patch appears
+ in the same patch or after the feature patch, but not before, as it
+ becomes confusing when someone working on a code base including
+ only the doc patch won't understand why a documented feature does
+ not work as documented.
+
+ - 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. Minor breakage is tolerated in such patches if trying
+ to fix it at once makes the whole change even more confusing. That
+ may happen for example when some #ifdefs need to be propagated in
+ every file consecutive to the change.
+
+ - 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 type tag. This is
+commonly the case for new features, which development versions are mostly made
+of.
+
+Additionally, the importance of the patch or severity of the bug it fixes must
+be indicated when relevant. 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. As a rule of thumb, a
+ patch tagged "MINOR" is safe enough to be backported to stable
+ branches. 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. In short, the patch is safe but
+ touches working areas and it is always possible that you missed
+ something you didn't know existed (eg: adding a "case" entry or
+ an error message after adding an error code to an enum). 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 large parts of
+ the code are rearranged, when new timeouts are introduced, when
+ sensitive parts of the session scheduling are touched, etc... We
+ should only exceptionally find such patches in stable branches when
+ there is no other option to fix a design issue. 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.
+
+The expected length of the commit message grows with the importance of the
+change. While a MINOR patch may sometimes be described in 1 or 2 lines, MAJOR
+or CRITICAL patches cannot have less than 10-15 lines to describe exactly the
+impacts otherwise the submitter's work will be considered as rough sabotage.
+
+For BUILD, DOC and CLEANUP types, this tag is not always relevant and may be
+omitted.
+
+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. The area is a
+single-word lowercase name the contributor find clear enough to describe what
+part is being touched. The following tags are suggested but not limitative :
+
+ - 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
+
+ - cli the stats socket CLI
+
+ - checks the health checks engine (eg: when adding new checks)
+
+ - sample the sample fetch system (new fetch or converter functions)
+
+ - acl the ACL processing core or some ACLs from other areas
+
+ - peers the peer synchronization engine
+
+ - lua the Lua scripting engine
+
+ - listeners everything related to incoming connection settings
+
+ - frontend everything related to incoming connection processing
+
+ - backend everything related to LB algorithms and server farm
+
+ - session session processing and flags (very sensible, be careful)
+
+ - server server connection management, queueing
+
+ - ssl the SSL/TLS interface
+
+ - proxy proxy maintenance (start/stop)
+
+ - log log management
+
+ - poll any of the pollers
+
+ - halog the halog sub-component in the contrib directory
+
+ - contrib any addition to the contrib directory
+
+Other names may be invented when more precise indications are meaningful, for
+instance : "cookie" which indicates cookie processing in the HTTP core. Last,
+indicating the name of the affected file is also a good way to quickly spot
+changes. Many commits were already tagged with "stream_sock" or "cfgparse" for
+instance.
+
+It is required that the type of change and the severity when relevant are
+indicated, as well as the touched area when relevant as well in the patch
+subject. Normally, we would have the 3 most often. The two first criteria should
+be present before a first colon (':'). If both are present, then they should be
+delimited with a slash ('/'). The 3rd criterion (area) should appear next, also
+followed by a colon. Thus, all of the following messages are valid :
+
+Examples of messages :
+ - DOC: document options forwardfor to logasap
+ - DOC/MAJOR: reorganize the whole document and change indenting
+ - BUG: stats: connection reset counters must be plain ascii, not HTML
+ - BUG/MINOR: stats: connection reset counters must be plain ascii, not HTML
+ - MEDIUM: checks: support multi-packet health check responses
+ - RELEASE: Released version 1.4.2
+ - BUILD: stats: stdint is not present on solaris
+ - OPTIM/MINOR: halog: make fgets parse more bytes by blocks
+ - REORG/MEDIUM: move syscall redefinition to specific places
+
+Please do not use square brackets anymore around the tags, because they induce
+more work when merging patches, which need to be hand-edited not to lose the
+enclosed part.
+
+In fact, one of the only square bracket tags that still makes sense is '[RFC]'
+at the beginning of the subject, when you're asking for someone to review your
+change before getting it merged. If the patch is OK to be merged, then it can
+be merge as-is and the '[RFC]' tag will automatically be removed. If you don't
+want it to be merged at all, you can simply state it in the message, or use an
+alternate 'WIP/' prefix in front of your tag tag ("work in progress").
+
+The tags are not rigid, follow your intuition first, and they may be readjusted
+when your patch is merged. It may happen that a same patch has a different tag
+in two distinct branches. The reason is that a bug in one branch may just be a
+cleanup or safety measure in the other one because the code cannot be triggered.
+
+
+Working with Git
+----------------
+
+For a more efficient interaction between the mainline code and your code, you
+are strongly encouraged to try the Git version control system :
+
+ http://git-scm.com/
+
+It's very fast, lightweight and lets you undo/redo your work as often as you
+want, without making your mistakes visible to the rest of the world. It will
+definitely help you contribute quality code and take other people's feedback
+in consideration. In order to clone the HAProxy Git repository :
+
+ $ git clone http://git.haproxy.org/git/haproxy.git/ (development)
+
+If you decide to use Git for your developments, then your commit messages will
+have the subject line in the format described above, then the whole description
+of your work (mainly why you did it) will be in the body. You can directly send
+your commits to the mailing list, the format is convenient to read and process.
+
+It is recommended to create a branch for your work that is based on the master
+branch :
+
+ $ git checkout -b 20150920-fix-stats master
+
+You can then do your work and even experiment with multiple alternatives if you
+are not completely sure that your solution is the best one :
+
+ $ git checkout -b 20150920-fix-stats-v2
+
+Then reorder/merge/edit your patches :
+
+ $ git rebase -i master
+
+When you think you're ready, reread your whole patchset to ensure there is no
+formating or style issue :
+
+ $ git show master..
+
+And once you're satisfied, you should update your master branch to be sure that
+nothing changed during your work (only neede if you left it unattended for days
+or weeks) :
+
+ $ git checkout -b 20150920-fix-stats-rebased
+ $ git fetch origin master:master
+ $ git rebase master
+
+They can build a list of patches ready for submission like this :
+
+ $ git format-patch master
+
+The output files are the patches ready to be sent over e-mail, either via a
+regular e-mail or via git send-email (carefully check the man page). Don't
+destroy your other work branches until your patches get merged, it may happen
+that earlier designs will be preferred for various reasons. Patches should be
+sent to the mailing list : haproxy@formilux.org and CCed to relevant subsystem
+maintainers or authors of the modified files if their address appears at the
+top of the file.
+
+Please don't send pull-requests, they are really unconvenient. First, a pull
+implies a merge operation and the code doesn't move fast enough to justify the
+use of merges. Second, pull requests are not easily commented on by the
+project's participants, contrary to e-mails where anyone is allowed to have an
+opinion and to express it.
+
+-- end
|
|
[-]
[+]
|
Changed |
_service:download_files:haproxy-1.5.15.tar.gz/README
^
|
| @@ -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
-
- - frontend everything related to incoming connection processing
-
- - backend everything related to LB algorithms and server farm
-
- - session session processing and flags (very sensible, be careful)
-
- - server server connection management, queueing
-
- - proxy proxy maintenance (start/stop)
-
- - log log management
-
- - poll any of the pollers
-
- - halog the halog sub-component in the contrib directory
-
- - contrib any addition to the contrib directory
-
-Other names may be invented when more precise indications are meaningful, for
-instance : "cookie" which indicates cookie processing in the HTTP core. Last,
-indicating the name of the affected file is also a good way to quickly spot
-changes. Many commits were already tagged with "stream_sock" or "cfgparse" for
-instance.
-
-It is desired that AT LEAST one of the 3 criteria tags is reported in the patch
-subject. Ideally, we would have the 3 most often. The two first criteria should
-be present before a first colon (':'). If both are present, then they should be
-delimited with a slash ('/'). The 3rd criterion (area) should appear next, also
-followed by a colon. Thus, all of the following messages are valid :
-
-Examples of messages :
- - DOC: document options forwardfor to logasap
- - DOC/MAJOR: reorganize the whole document and change indenting
- - BUG: stats: connection reset counters must be plain ascii, not HTML
- - BUG/MINOR: stats: connection reset counters must be plain ascii, not HTML
- - MEDIUM: checks: support multi-packet health check responses
- - RELEASE: Released version 1.4.2
- - BUILD: stats: stdint is not present on solaris
- - OPTIM/MINOR: halog: make fgets parse more bytes by blocks
- - REORG/MEDIUM: move syscall redefinition to specific places
-
-Please do not use square brackets anymore around the tags, because they give me
-more work when merging patches. By default I'm asking Git to keep them but this
-causes trouble when patches are prefixed with the [PATCH] tag because in order
-not to store it, I have to hand-edit the patches. So as of now, I will ask Git
-to remove whatever is located between square brackets, which implies that any
-subject formatted the old way will have its tag stripped out.
-
-In fact, one of the only square bracket tags that still makes sense is '[RFC]'
-at the beginning of the subject, when you're asking for someone to review your
-change before getting it merged. If the patch is OK to be merged, then I can
-merge it as-is and the '[RFC]' tag will automatically be removed. If you don't
-want it to be merged at all, you can simply state it in the message, or use an
-alternate '[WIP]' tag ("work in progress").
-
-The tags are not rigid, follow your intuition first, anyway I reserve the right
-to change them when merging the patch. It may happen that a same patch has a
-different tag in two distinct branches. The reason is that a bug in one branch
-may just be a cleanup in the other one because the code cannot be triggered.
-
-
-For a more efficient interaction between the mainline code and your code, I can
-only strongly encourage you to try the Git version control system :
-
- http://git-scm.com/
-
-It's very fast, lightweight and lets you undo/redo your work as often as you
-want, without making your mistakes visible to the rest of the world. It will
-definitely help you contribute quality code and take other people's feedback
-in consideration. In order to clone the HAProxy Git repository :
-
- $ git clone http://git.haproxy.org/git/haproxy-1.5.git (stable 1.5)
- $ git clone http://git.haproxy.org/git/haproxy.git/ (development)
-
-If you decide to use Git for your developments, then your commit messages will
-have the subject line in the format described above, then the whole description
-of your work (mainly why you did it) will be in the body. You can directly send
-your commits to the mailing list, the format is convenient to read and process.
+Please carefully read the CONTRIBUTING file that comes with the sources. It is
+mandatory.
-- end
|
|
[-]
[+]
|
Changed |
_service:download_files:haproxy-1.5.15.tar.gz/VERDATE
^
|
| @@ -1,2 +1,2 @@
$Format:%ci$
-2015/07/02
+2015/11/01
|
|
[-]
[+]
|
Changed |
_service:download_files:haproxy-1.5.15.tar.gz/VERSION
^
|
| @@ -1 +1 @@
-1.5.14
+1.5.15
|
|
[-]
[+]
|
Changed |
_service:download_files:haproxy-1.5.15.tar.gz/doc/configuration.txt
^
|
| @@ -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 |
|
|
[-]
[+]
|
Changed |
_service:download_files:haproxy-1.5.15.tar.gz/examples/haproxy.spec
^
|
| @@ -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
|
|
[-]
[+]
|
Changed |
_service:download_files:haproxy-1.5.15.tar.gz/include/common/syscall.h
^
|
| @@ -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 */
|
|
[-]
[+]
|
Changed |
_service:download_files:haproxy-1.5.15.tar.gz/include/types/proto_http.h
^
|
| @@ -219,7 +219,6 @@
/* Known HTTP methods */
enum http_meth_t {
- HTTP_METH_NONE = 0,
HTTP_METH_OPTIONS,
HTTP_METH_GET,
HTTP_METH_HEAD,
|
|
[-]
[+]
|
Changed |
_service:download_files:haproxy-1.5.15.tar.gz/src/acl.c
^
|
| @@ -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;
}
|
|
[-]
[+]
|
Changed |
_service:download_files:haproxy-1.5.15.tar.gz/src/cfgparse.c
^
|
| @@ -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) {
|
|
[-]
[+]
|
Changed |
_service:download_files:haproxy-1.5.15.tar.gz/src/dumpstats.c
^
|
| @@ -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
|
|
[-]
[+]
|
Changed |
_service:download_files:haproxy-1.5.15.tar.gz/src/haproxy.c
^
|
| @@ -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",
|
|
[-]
[+]
|
Changed |
_service:download_files:haproxy-1.5.15.tar.gz/src/log.c
^
|
| @@ -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 */
}
}
|
|
[-]
[+]
|
Changed |
_service:download_files:haproxy-1.5.15.tar.gz/src/pattern.c
^
|
| @@ -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;
}
}
|
|
[-]
[+]
|
Changed |
_service:download_files:haproxy-1.5.15.tar.gz/src/proto_http.c
^
|
| @@ -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,
|
|
[-]
[+]
|
Changed |
_service:download_files:haproxy-1.5.15.tar.gz/src/proxy.c
^
|
| @@ -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;
}
|
|
[-]
[+]
|
Changed |
_service:download_files:haproxy-1.5.15.tar.gz/src/session.c
^
|
| @@ -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;
|
|
[-]
[+]
|
Changed |
_service:download_files:haproxy-1.5.15.tar.gz/src/ssl_sock.c
^
|
| @@ -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
|
|
[-]
[+]
|
Changed |
_service:download_files:haproxy-1.5.15.tar.gz/src/standard.c
^
|
| @@ -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) {
|
