Bug#859490: unblock: haproxy/1.7.5-1 (pre-approval)
Control: tags -1 - moreinfo
Hi,
On 13:40 Wed 05 Apr , Niels Thykier wrote:
> Ack, please go ahead and remove the moreinfo tag once the upload has
> been built successfully on all relevant release architectures.
Uploaded and built everywhere, thanks!
I'm also attaching the full source debdiff for reference.
Regards,
Apollon
diff -Nru haproxy-1.7.4/CHANGELOG haproxy-1.7.5/CHANGELOG
--- haproxy-1.7.4/CHANGELOG 2017-03-28 00:37:58.000000000 +0300
+++ haproxy-1.7.5/CHANGELOG 2017-04-03 11:28:32.000000000 +0300
@@ -1,6 +1,16 @@
ChangeLog :
===========
+2017/04/03 : 1.7.5
+ - BUG/MEDIUM: peers: fix buffer overflow control in intdecode.
+ - BUG/MEDIUM: buffers: Fix how input/output data are injected into buffers
+ - BUG/MEDIUM: http: Fix blocked HTTP/1.0 responses when compression is enabled
+ - BUG/MINOR: filters: Don't force the stream's wakeup when we wait in flt_end_analyze
+ - DOC: fix parenthesis and add missing "Example" tags
+ - DOC: update the contributing file
+ - DOC: log-format/tcplog/httplog update
+ - MINOR: config parsing: add warning when log-format/tcplog/httplog is overriden in "defaults" sections
+
2017/03/27 : 1.7.4
- MINOR: config: warn when some HTTP rules are used in a TCP proxy
- BUG/MINOR: spoe: Fix soft stop handler using a specific id for spoe filters
diff -Nru haproxy-1.7.4/CONTRIBUTING haproxy-1.7.5/CONTRIBUTING
--- haproxy-1.7.4/CONTRIBUTING 2017-03-28 00:37:58.000000000 +0300
+++ haproxy-1.7.5/CONTRIBUTING 2017-04-03 11:28:32.000000000 +0300
@@ -71,8 +71,10 @@
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.
+several days in the queue before you get a response, if you get a response at
+all. Retransmit if you don't get a response by one week. Please note that
+direct sent e-mails to this address for non-confidential subjects may simply
+be forwarded to the list or be deleted without notification.
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 :
@@ -96,7 +98,9 @@
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")
+1) Comply with the license
+
+ 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
@@ -107,7 +111,9 @@
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
+2) Develop on development branch, not stable ones
+
+ 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
@@ -119,7 +125,9 @@
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
+3) Read and respect the coding style
+
+ You have read and understood "doc/coding-style.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
@@ -133,7 +141,9 @@
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
+4) Present clean work
+
+ 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
@@ -145,7 +155,9 @@
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 :
+5) Documentation is very important
+
+ 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
@@ -208,7 +220,9 @@
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.
+6) US-ASCII only!
+
+ 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
@@ -219,7 +233,9 @@
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
+7) Comments
+
+ 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
@@ -250,7 +266,9 @@
- return 0;
-
-8) Limit the length of your identifiers in the code. When your identifiers start
+8) Short, readable identifiers
+
+ 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
@@ -284,16 +302,22 @@
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
+9) Unified diff only
+
+ The best way to build your patches is to use "git format-patch". This means
+ that you have committed your patch to a local branch, with an appropriate
+ subject line and a useful commit message explaining what the patch attempts
+ to do. It is not strictly required to use git, but what is strictly required
+ is to have all these elements in the same mail, easily distinguishible, and
+ a patch 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
@@ -301,82 +325,151 @@
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 independently 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 formatted 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 formatting 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 formatted 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 succinct 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 formatting.
-
-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 mentioned in the file you change, or a subsystem
- maintainers whose address is mentioned 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.
+10) One patch per feature
+
+ Please cut your work in series of patches that can be independently 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.
+
+ If you can, please always put all the bug fixes at the beginning of the
+ series. This often makes it easier to backport them because they will not
+ depend on context that your other patches changed.
+
+11) Real commit messages please!
+
+ Please properly format your commit messages. To get an idea, just run
+ "git log" on the file you've just modified. Patches always have the format
+ of an e-mail made of a subject, a description and the actual patch. If you
+ are sending a patch as an e-mail formatted this way, it can quickly be
+ applied with limited effort so that's acceptable :
+
+ - A subject line (may wrap to the next line, but please read below)
+ - an empty line (subject delimiter)
+ - a non-empty description (the body of the e-mail)
+ - the patch itself
+
+ The subject describes the "What" of the change ; the description explains
+ the "why", the "how" and sometimes "what next". For example a commit message
+ looking like this will be rejected :
+
+ | From: Mr Foobar <foobar@example.com>
+ | Subject: BUG: fix typo in ssl_sock
+ |
+
+ This one as well (too long subject, not the right place for the details) :
+
+ | From: Mr Foobar <foobar@example.com>
+ | Subject: BUG/MEDIUM: ssl: use an error flag to prevent ssl_read() from
+ | returning 0 when dealing with large buffers because that can cause
+ | an infinite loop
+ |
+
+ This one ought to be used instead :
+
+ | From: Mr Foobar <foobar@example.com>
+ | Subject: BUG/MEDIUM: ssl: fix risk of infinite loop in ssl_sock
+ |
+ | ssl_read() must not return 0 on error or the caller may loop forever.
+ | Instead we add a flag to the connection to notify about the error and
+ | check it at all call places. This situation can only happen with large
+ | buffers so a workaround is to limit buffer sizes. Another option would
+ | have been to return -1 but it required to use signed ints everywhere
+ | and would have made the patch larger and riskier. This fix should be
+ | backported to versions 1.2 and upper.
+
+ It is important to understand that for any reader to guess the text above
+ when it's absent, it will take a huge amount of time. If you made the
+ analysis leading to your patch, you must explain it, including the ideas
+ you dropped if you had a good reason for this.
+
+ 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. But if you
+ are comfortable with writing clean e-mails and inserting your patches, you
+ don't need to use Git.
+
+ 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
+ formatting 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 formatted 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 succinct 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 formatting.
+
+ As a rule of thumb, your patch must never be made only of a subject line,
+ it *must* contain a description. Even one or two lines, or indicating
+ whether a backport is desired or not. It turns out that single-line commits
+ are so rare in the Git world that they require special manual (hence
+ painful) handling when they are backported, and at least for this reason
+ it's important to keep this in mind.
+
+12) Discuss on the mailing list
+
+ 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's often
+ convenient to prepend "[PATCH]" in front of your mail's subject to mention
+ that this e-mail contains a patch (or a series of patches), because it will
+ easily catch reviewer's attention. It's automatically done by tools such as
+ "git format-patch" and "git send-email". If you don't want your patch to be
+ merged yet and prefer to show it for discussion, better tag it as "[RFC]"
+ (stands for "Request For Comments") and it will be reviewed but not merged
+ without your approval. It is also important to CC any author mentioned in
+ the file you change, or a subsystem maintainers whose address is mentioned
+ 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
@@ -449,11 +542,11 @@
- 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.
+When the patch cannot be categorized, it's best not to put any type tag, and to
+only use a risk or complexity information only as below. 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
+The importance, complexity 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
@@ -519,6 +612,8 @@
- acl the ACL processing core or some ACLs from other areas
+ - filters everything related to the filters core
+
- peers the peer synchronization engine
- lua the Lua scripting engine
@@ -533,6 +628,8 @@
- server server connection management, queueing
+ - spoe SPOE code
+
- ssl the SSL/TLS interface
- proxy proxy maintenance (start/stop)
@@ -556,9 +653,9 @@
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 :
+followed by a colon. Thus, all of the following subject lines are valid :
-Examples of messages :
+Examples of subject lines :
- 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
diff -Nru haproxy-1.7.4/debian/changelog haproxy-1.7.5/debian/changelog
--- haproxy-1.7.4/debian/changelog 2017-03-31 12:01:14.000000000 +0300
+++ haproxy-1.7.5/debian/changelog 2017-04-04 14:25:38.000000000 +0300
@@ -1,3 +1,13 @@
+haproxy (1.7.5-1) unstable; urgency=medium
+
+ * New upstream version release (see CHANGELOG):
+ - BUG/MEDIUM: peers: fix buffer overflow control in intdecode.
+ - BUG/MEDIUM: buffers: Fix how input/output data are injected into buffers
+ - BUG/MEDIUM: http: Fix blocked HTTP/1.0 responses when compression is
+ enabled
+
+ -- Apollon Oikonomopoulos <apoikos@debian.org> Tue, 04 Apr 2017 14:25:38 +0300
+
haproxy (1.7.4-1) unstable; urgency=medium
* New upstream release (see CHANGELOG):
diff -Nru haproxy-1.7.4/doc/configuration.txt haproxy-1.7.5/doc/configuration.txt
--- haproxy-1.7.4/doc/configuration.txt 2017-03-28 00:37:58.000000000 +0300
+++ haproxy-1.7.5/doc/configuration.txt 2017-04-03 11:28:32.000000000 +0300
@@ -4,7 +4,7 @@
----------------------
version 1.7
willy tarreau
- 2017/03/27
+ 2017/04/03
This document covers the configuration language as implemented in the version
@@ -4756,6 +4756,9 @@
the same log format. Please see section 8.2.4 which covers the log format
string in depth.
+ "log-format" directive overrides previous "option tcplog", "log-format" and
+ "option httplog" directives.
+
log-format-sd <string>
Specifies the RFC5424 structured-data log format string
May be used in sections: defaults | frontend | listen | backend
@@ -5807,6 +5810,8 @@
Specifying only "option httplog" will automatically clear the 'clf' mode
if it was set by default.
+ "option httplog" overrides any previous "log-format" directive.
+
See also : section 8 about logging.
@@ -6665,6 +6670,8 @@
This option may be set either in the frontend or the backend.
+ "option tcplog" overrides any previous "log-format" directive.
+
See also : "option httplog", and section 8 about logging.
@@ -13243,6 +13250,7 @@
typically used as a second ACL in an expression in order to mark a connection
when a first ACL was verified :
+ Example:
# block if 5 consecutive requests continue to come faster than 10 sess
# per second, and reset the counter as soon as the traffic slows down.
acl abuse sc0_http_req_rate gt 10
@@ -13343,6 +13351,7 @@
return 1. This is typically used as a second ACL in an expression in order
to mark a connection when a first ACL was verified :
+ Example:
acl abuse sc0_http_req_rate gt 10
acl kill sc0_inc_gpc0 gt 0
tcp-request connection reject if abuse kill
@@ -13445,6 +13454,7 @@
second ACL in an expression in order to mark a connection when a first ACL
was verified :
+ Example:
# block if 5 consecutive requests continue to come faster than 10 sess
# per second, and reset the counter as soon as the traffic slows down.
acl abuse src_http_req_rate gt 10
@@ -13527,6 +13537,7 @@
This is typically used as a second ACL in an expression in order to mark a
connection when a first ACL was verified :
+ Example:
acl abuse src_http_req_rate gt 10
acl kill src_inc_gpc0 gt 0
tcp-request connection reject if abuse kill
@@ -13730,6 +13741,7 @@
Note that the output is binary, so if you want to pass that signature to the
server, you need to encode it in hex or base64, such as in the example below:
+ Example:
http-request set-header X-SSL-Client-SHA1 %[ssl_c_sha1,hex]
ssl_c_sig_alg : string
@@ -14670,7 +14682,7 @@
# match http://example.com/foo;JSESSIONID=some_id
stick on urlp(JSESSIONID,;)
-urlp_val([<name>[,<delim>])] : integer
+urlp_val([<name>[,<delim>]]) : integer
See "urlp" above. This one extracts the URL parameter <name> in the request
and converts it to an integer value. This can be used for session stickiness
based on a user ID for example, or with ACLs to match a page number or price.
diff -Nru haproxy-1.7.4/examples/haproxy.spec haproxy-1.7.5/examples/haproxy.spec
--- haproxy-1.7.4/examples/haproxy.spec 2017-03-28 00:37:58.000000000 +0300
+++ haproxy-1.7.5/examples/haproxy.spec 2017-04-03 11:28:32.000000000 +0300
@@ -1,6 +1,6 @@
Summary: HA-Proxy is a TCP/HTTP reverse proxy for high availability environments
Name: haproxy
-Version: 1.7.4
+Version: 1.7.5
Release: 1
License: GPL
Group: System Environment/Daemons
@@ -74,6 +74,9 @@
%attr(0755,root,root) %config %{_sysconfdir}/rc.d/init.d/%{name}
%changelog
+* Mon Apr 3 2017 Willy Tarreau <w@1wt.eu>
+- updated to 1.7.5
+
* Mon Mar 27 2017 Willy Tarreau <w@1wt.eu>
- updated to 1.7.4
diff -Nru haproxy-1.7.4/include/common/buffer.h haproxy-1.7.5/include/common/buffer.h
--- haproxy-1.7.4/include/common/buffer.h 2017-03-28 00:37:58.000000000 +0300
+++ haproxy-1.7.5/include/common/buffer.h 2017-04-03 11:28:32.000000000 +0300
@@ -156,6 +156,41 @@
return b->o;
}
+/* Return the amount of bytes that can be written into the input area at once
+ * including reserved space which may be overwritten (this is the caller
+ * responsibility to know if the reserved space is protected or not).
+*/
+static inline int bi_contig_space(const struct buffer *b)
+{
+ const char *left, *right;
+
+ left = bi_end(b);
+ right = bo_ptr(b);
+
+ if (left >= right)
+ right = b->data + b->size;
+
+ return (right - left);
+}
+
+/* Return the amount of bytes that can be written into the output area at once
+ * including reserved space which may be overwritten (this is the caller
+ * responsibility to know if the reserved space is protected or not). Input data
+ * are assumed to not exist.
+*/
+static inline int bo_contig_space(const struct buffer *b)
+{
+ const char *left, *right;
+
+ left = bo_end(b);
+ right = bo_ptr(b);
+
+ if (left >= right)
+ right = b->data + b->size;
+
+ return (right - left);
+}
+
/* Return the buffer's length in bytes by summing the input and the output */
static inline int buffer_len(const struct buffer *buf)
{
@@ -226,21 +261,6 @@
return count;
}
-/* Return the amount of bytes that can be written into the buffer at once,
- * including reserved space which may be overwritten.
- */
-static inline int buffer_contig_space(const struct buffer *buf)
-{
- const char *left, *right;
-
- if (buf->data + buf->o <= buf->p)
- right = buf->data + buf->size;
- else
- right = buf->p + buf->size - buf->o;
-
- left = buffer_wrap_add(buf, buf->p + buf->i);
- return right - left;
-}
/* Returns the amount of byte that can be written starting from <p> into the
* input buffer at once, including reserved space which may be overwritten.
@@ -340,17 +360,13 @@
buf->p += n;
}
-/*
- * Tries to realign the given buffer, and returns how many bytes can be written
- * there at once without overwriting anything.
- */
-static inline int buffer_realign(struct buffer *buf)
+/* Tries to realign the given buffer. */
+static inline void buffer_realign(struct buffer *buf)
{
if (!(buf->i | buf->o)) {
/* let's realign the buffer to optimize I/O */
buf->p = buf->data;
}
- return buffer_contig_space(buf);
}
/* Schedule all remaining buffer data to be sent. ->o is not touched if it
@@ -402,7 +418,7 @@
if (!len)
return 0;
- half = buffer_contig_space(b);
+ half = bo_contig_space(b);
if (half > len)
half = len;
diff -Nru haproxy-1.7.4/README haproxy-1.7.5/README
--- haproxy-1.7.4/README 2017-03-28 00:37:58.000000000 +0300
+++ haproxy-1.7.5/README 2017-04-03 11:28:32.000000000 +0300
@@ -3,7 +3,7 @@
----------------------
version 1.7
willy tarreau
- 2017/03/27
+ 2017/04/03
1) How to build it
diff -Nru haproxy-1.7.4/src/cfgparse.c haproxy-1.7.5/src/cfgparse.c
--- haproxy-1.7.4/src/cfgparse.c 2017-03-28 00:37:58.000000000 +0300
+++ haproxy-1.7.5/src/cfgparse.c 2017-04-03 11:28:32.000000000 +0300
@@ -4792,6 +4792,21 @@
if (alertif_too_many_args_idx(1, 1, file, linenum, args, &err_code))
goto out;
}
+ if (curproxy->conf.logformat_string && curproxy == &defproxy) {
+ char *oldlogformat = "log-format";
+ char *clflogformat = "";
+
+ if (curproxy->conf.logformat_string == default_http_log_format)
+ oldlogformat = "option httplog";
+ else if (curproxy->conf.logformat_string == default_tcp_log_format)
+ oldlogformat = "option tcplog";
+ else if (curproxy->conf.logformat_string == clf_http_log_format)
+ oldlogformat = "option httplog clf";
+ if (logformat == clf_http_log_format)
+ clflogformat = " clf";
+ Warning("parsing [%s:%d]: 'option httplog%s' overrides previous '%s' in 'defaults' section.\n",
+ file, linenum, clflogformat, oldlogformat);
+ }
if (curproxy->conf.logformat_string != default_http_log_format &&
curproxy->conf.logformat_string != default_tcp_log_format &&
curproxy->conf.logformat_string != clf_http_log_format)
@@ -4803,6 +4818,18 @@
curproxy->conf.lfs_line = curproxy->conf.args.line;
}
else if (!strcmp(args[1], "tcplog")) {
+ if (curproxy->conf.logformat_string && curproxy == &defproxy) {
+ char *oldlogformat = "log-format";
+
+ if (curproxy->conf.logformat_string == default_http_log_format)
+ oldlogformat = "option httplog";
+ else if (curproxy->conf.logformat_string == default_tcp_log_format)
+ oldlogformat = "option tcplog";
+ else if (curproxy->conf.logformat_string == clf_http_log_format)
+ oldlogformat = "option httplog clf";
+ Warning("parsing [%s:%d]: 'option tcplog' overrides previous '%s' in 'defaults' section.\n",
+ file, linenum, oldlogformat);
+ }
/* generate a detailed TCP log */
if (curproxy->conf.logformat_string != default_http_log_format &&
curproxy->conf.logformat_string != default_tcp_log_format &&
@@ -6046,7 +6073,18 @@
err_code |= ERR_ALERT | ERR_FATAL;
goto out;
}
+ if (curproxy->conf.logformat_string && curproxy == &defproxy) {
+ char *oldlogformat = "log-format";
+ if (curproxy->conf.logformat_string == default_http_log_format)
+ oldlogformat = "option httplog";
+ else if (curproxy->conf.logformat_string == default_tcp_log_format)
+ oldlogformat = "option tcplog";
+ else if (curproxy->conf.logformat_string == clf_http_log_format)
+ oldlogformat = "option httplog clf";
+ Warning("parsing [%s:%d]: 'log-format' overrides previous '%s' in 'defaults' section.\n",
+ file, linenum, oldlogformat);
+ }
if (curproxy->conf.logformat_string != default_http_log_format &&
curproxy->conf.logformat_string != default_tcp_log_format &&
curproxy->conf.logformat_string != clf_http_log_format)
diff -Nru haproxy-1.7.4/src/channel.c haproxy-1.7.5/src/channel.c
--- haproxy-1.7.4/src/channel.c 2017-03-28 00:37:58.000000000 +0300
+++ haproxy-1.7.5/src/channel.c 2017-04-03 11:28:32.000000000 +0300
@@ -91,8 +91,8 @@
return -2;
}
- max = buffer_realign(chn->buf);
-
+ buffer_realign(chn->buf);
+ max = bo_contig_space(chn->buf);
if (len > max)
return max;
@@ -166,7 +166,7 @@
return 0;
/* OK so the data fits in the buffer in one or two blocks */
- max = buffer_contig_space(chn->buf);
+ max = bi_contig_space(chn->buf);
memcpy(bi_end(chn->buf), blk, MIN(len, max));
if (len > max)
memcpy(chn->buf->data, blk + max, len - max);
diff -Nru haproxy-1.7.4/src/filters.c haproxy-1.7.5/src/filters.c
--- haproxy-1.7.4/src/filters.c 2017-03-28 00:37:58.000000000 +0300
+++ haproxy-1.7.5/src/filters.c 2017-04-03 11:28:32.000000000 +0300
@@ -843,12 +843,7 @@
/* Remove backend filters from the list */
flt_stream_release(s, 1);
}
- else {
- /* This analyzer ends only for one channel. So wake up the
- * stream to be sure to process it for the other side as soon as
- * possible. */
- task_wakeup(s->task, TASK_WOKEN_MSG);
- }
+
return ret;
}
diff -Nru haproxy-1.7.4/src/peers.c haproxy-1.7.5/src/peers.c
--- haproxy-1.7.4/src/peers.c 2017-03-28 00:37:58.000000000 +0300
+++ haproxy-1.7.5/src/peers.c 2017-04-03 11:28:32.000000000 +0300
@@ -174,6 +174,12 @@
struct peers *peers = NULL;
static void peer_session_forceshutdown(struct appctx *appctx);
+/* This function encode an uint64 to 'dynamic' length format.
+ The encoded value is written at address *str, and the
+ caller must assure that size after *str is large enought.
+ At return, the *str is set at the next Byte after then
+ encoded integer. The function returns then length of the
+ encoded integer in Bytes */
int intencode(uint64_t i, char **str) {
int idx = 0;
unsigned char *msg;
@@ -205,36 +211,35 @@
*str point on the beginning of the integer to decode
at the end of decoding *str point on the end of the
encoded integer or to null if end is reached */
-uint64_t intdecode(char **str, char *end) {
- uint64_t i;
- int idx = 0;
+uint64_t intdecode(char **str, char *end)
+{
unsigned char *msg;
+ uint64_t i;
+ int shift;
if (!*str)
return 0;
msg = (unsigned char *)*str;
- if (msg >= (unsigned char *)end) {
- *str = NULL;
- return 0;
- }
+ if (msg >= (unsigned char *)end)
+ goto fail;
- if (msg[idx] < 240) {
- *str = (char *)&msg[idx+1];
- return msg[idx];
- }
- i = msg[idx];
- do {
- idx++;
- if (msg >= (unsigned char *)end) {
- *str = NULL;
- return 0;
- }
- i += (uint64_t)msg[idx] << (4 + 7*(idx-1));
+ i = *(msg++);
+ if (i >= 240) {
+ shift = 4;
+ do {
+ if (msg >= (unsigned char *)end)
+ goto fail;
+ i += (uint64_t)*msg << shift;
+ shift += 7;
+ } while (*(msg++) >= 128);
}
- while (msg[idx] >= 128);
- *str = (char *)&msg[idx+1];
- return i;
+ *str = (char *)msg;
+ return i;
+
+ fail:
+ *str = NULL;
+ return 0;
}
/* Set the stick-table UPDATE message type byte at <msg_type> address,
diff -Nru haproxy-1.7.4/src/proto_http.c haproxy-1.7.5/src/proto_http.c
--- haproxy-1.7.4/src/proto_http.c 2017-03-28 00:37:58.000000000 +0300
+++ haproxy-1.7.5/src/proto_http.c 2017-04-03 11:28:32.000000000 +0300
@@ -6827,11 +6827,9 @@
}
skip_header_mangling:
- if ((msg->flags & HTTP_MSGF_XFER_LEN) || HAS_DATA_FILTERS(s, rep) ||
- (txn->flags & TX_CON_WANT_MSK) == TX_CON_WANT_TUN) {
- rep->analysers &= ~AN_RES_FLT_XFER_DATA;
- rep->analysers |= AN_RES_HTTP_XFER_BODY;
- }
+ /* Always enter in the body analyzer */
+ rep->analysers &= ~AN_RES_FLT_XFER_DATA;
+ rep->analysers |= AN_RES_HTTP_XFER_BODY;
/* if the user wants to log as soon as possible, without counting
* bytes from the server, then this is the right moment. We have
@@ -6974,11 +6972,11 @@
/* When TE: chunked is used, we need to get there again to parse
* remaining chunks even if the server has closed, so we don't want to
- * set CF_DONTCLOSE. Similarly, if the body length is undefined, if
- * keep-alive is set on the client side or if there are filters
- * registered on the stream, we don't want to forward a close
+ * set CF_DONTCLOSE. Similarly, if keep-alive is set on the client side
+ * or if there are filters registered on the stream, we don't want to
+ * forward a close
*/
- if ((msg->flags & HTTP_MSGF_TE_CHNK) || !(msg->flags & HTTP_MSGF_XFER_LEN) ||
+ if ((msg->flags & HTTP_MSGF_TE_CHNK) ||
HAS_DATA_FILTERS(s, res) ||
(txn->flags & TX_CON_WANT_MSK) == TX_CON_WANT_KAL ||
(txn->flags & TX_CON_WANT_MSK) == TX_CON_WANT_SCL)
@@ -6995,6 +6993,14 @@
if ((msg->flags & HTTP_MSGF_TE_CHNK) || (msg->flags & HTTP_MSGF_COMPRESSING))
res->flags |= CF_EXPECT_MORE;
+ /* If there is neither content-length, nor transfer-encoding header
+ * _AND_ there is no data filtering, we can safely forward all data
+ * indefinitely. */
+ if (!(msg->flags & HTTP_MSGF_XFER_LEN) && !HAS_DATA_FILTERS(s, res)) {
+ buffer_flush(res->buf);
+ channel_forward_forever(res);
+ }
+
/* the stream handler will take care of timeouts and errors */
return 0;
diff -Nru haproxy-1.7.4/VERDATE haproxy-1.7.5/VERDATE
--- haproxy-1.7.4/VERDATE 2017-03-28 00:37:58.000000000 +0300
+++ haproxy-1.7.5/VERDATE 2017-04-03 11:28:32.000000000 +0300
@@ -1,2 +1,2 @@
$Format:%ci$
-2017/03/27
+2017/04/03
diff -Nru haproxy-1.7.4/VERSION haproxy-1.7.5/VERSION
--- haproxy-1.7.4/VERSION 2017-03-28 00:37:58.000000000 +0300
+++ haproxy-1.7.5/VERSION 2017-04-03 11:28:32.000000000 +0300
@@ -1 +1 @@
-1.7.4
+1.7.5
Reply to: