stable-bot: WARNING: 10 bug fixes in queue for next release
Hi, This is a friendly bot that watches fixes pending for the next haproxy-stable release! One such e-mail is sent periodically once patches are waiting in the last maintenance branch, and an ideal release date is computed based on the severity of these fixes and their merge date. Responses to this mail must be sent to the mailing list. Last release 1.8.17 was issued on 2019/01/08. There are currently 10 patches in the queue cut down this way: - 1 MAJOR, first one merged on 2019/01/28 - 3 MEDIUM, first one merged on 2019/01/28 - 6 MINOR, first one merged on 2019/01/28 Thus the computed ideal release date for 1.8.18 would be 2019/02/11, which is in one week or less. The current list of patches in the queue is: - MAJOR : cache: fix confusion between zero and uninitialized cache key - MEDIUM : ssl: missing allocation failure checks loading tls key file - MEDIUM : ssl: Fix handling of TLS 1.3 KeyUpdate messages - MEDIUM : ssl: Disable anti-replay protection and set max data with 0RTT. - MINOR : server: don't always trust srv_check_health when loading a server state - MINOR : check: Wake the check task if the check is finished in wake_srv_chk() - MINOR : stick_table: Prevent conn_cur from underflowing - MINOR : backend: BE_LB_LKUP_CHTREE is a value, not a bit - MINOR : backend: don't use url_param_name as a hint for BE_LB_ALGO_PH - MINOR : backend: balance uri specific options were lost across defaults --- The haproxy stable-bot is freely provided by HAProxy Technologies to help improve the quality of each HAProxy release. If you have any issue with these emails or if you want to suggest some improvements, please post them on the list so that the solutions suiting the most users can be found.
stable-bot: INFO: 31 bug fixes in queue for next release
Hi, This is a friendly bot that watches fixes pending for the next haproxy-stable release! One such e-mail is sent periodically once patches are waiting in the last maintenance branch, and an ideal release date is computed based on the severity of these fixes and their merge date. Responses to this mail must be sent to the mailing list. Last release 1.9.3 was issued on 2019/01/29. There are currently 31 patches in the queue cut down this way: - 24 MEDIUM, first one merged on 2019/02/01 - 7 MINOR, first one merged on 2019/02/01 Thus the computed ideal release date for 1.9.4 would be 2019/03/01, which is in four weeks or less. The current list of patches in the queue is: - MEDIUM : servers: Close the connection if we failed to install the mux. - MEDIUM : mux-h1: Don't add "transfer-encoding" if message-body is forbidden - MEDIUM : mux-h2: fix two half-closed to closed transitions - MEDIUM : peers: Handle mux creation failure. - MEDIUM : checks: Don't try to set ALPN if connection failed. - MEDIUM : h2: In h2_send(), stop the loop if we failed to alloc a buf. - MEDIUM : buffer: Make sure b_is_null handles buffers waiting for allocation. - MEDIUM : connections: Don't forget to remove CO_FL_SESS_IDLE. - MEDIUM : mux-h2: do not abort HEADERS frame before decoding them - MEDIUM : checks: Check that conn_install_mux succeeded. - MEDIUM : mux-h2: only close connection on request frames on closed streams - MEDIUM : mux-h2: wait for the mux buffer to be empty before closing the connection - MEDIUM : servers: Don't add an incomplete conn to the server idle list. - MEDIUM : servers: Only destroy a conn_stream we just allocated. - MEDIUM : htx: check the HTX compatibility in dynamic use-backend rules - MEDIUM : mux-h2: do not close the connection on aborted streams - MEDIUM : mux-h2: make sure never to send GOAWAY on too old streams - MEDIUM : backend: always release the previous connection into its own target srv_list - MEDIUM : mux-h2: wake up flow-controlled streams on initial window update - MEDIUM : mux-h2: always omit :scheme and :path for the CONNECT method - MEDIUM : mux-h2: properly consider the peer's advertised max-concurrent-streams - MEDIUM : stream: Don't forget to free s->unique_id in stream_free(). - MEDIUM : mux-h2: always set :authority on request output - MEDIUM : compression: Rewrite strong ETags - MINOR : mux-h2: always compare content-length to the sum of DATA frames - MINOR : stream: don't close the front connection when facing a backend error - MINOR : mux-h2: make sure response HEADERS are not received in other states than OPEN and HLOC - MINOR : server: fix logic flaw in idle connection list management - MINOR : deinit: tcp_rep.inspect_rules not deinit, add to deinit - MINOR : mux-h2: make sure request trailers on aborted streams don't break the connection - MINOR : backend: check srv_conn before dereferencing it --- The haproxy stable-bot is freely provided by HAProxy Technologies to help improve the quality of each HAProxy release. If you have any issue with these emails or if you want to suggest some improvements, please post them on the list so that the solutions suiting the most users can be found.
Re: [PATCH] DOC: Add HTX part in the documentation
Sorry have forgotten to add. Need to backport to 1.9 Regards Aleks Ursprüngliche Nachricht Von: Aleksandar Lazic Gesendet: 2. Februar 2019 10:01:26 MEZ An: haproxy@formilux.org Betreff: [PATCH] DOC: Add HTX part in the documentation Hi. attached a doc update for the new features of HAProxy 1.9. I hope the patch full fills the CONTRIBUTING rules as I haven't send patched to the list for long time ;-) Regards Aleks
Chained http -> http frontends: http/2 error 400 vs http/1.1 error 502 Reply-To:
Hi,
(This is kind of related to this thread:
https://www.mail-archive.com/haproxy@formilux.org/msg32255.html).
I'm seeing different behaviour between http1.1 / http2 when chaining
two frontends with mode http and the last frontend closes
connection with http-request reject (or tcp-request content reject).
When client uses http/1.1 then client receives 502 error (I think
this is expected because the "server" for the first frontend just closes
connection).
But when client uses http/2 then client will receive error 400.
(Tested with latest 2.0dev (2.0-dev0-32211a-258)).
I'm not sure if this is a bug, but at least seems to be different behaviour
between http/1.1 and http/2. (option http-use-htx doesn't seem to make
difference).
The attached varnishtest should explain what I mean. I put some debug
printf output to proto_htx and with http/2 the status 400 comes
from /* 3: client abort with an abortonclose */
(proto_htx.c line 1535, s->req.flags 0x9c42020).
With http/1.1 status 502 comes from /* 4: close from server, capture
the response if the server has started to respond */
(proto_htx.c line 1559, s->req.flags 0x9842000).
(If I interpret s->req.flags correctly then http/2 has
CF_READ_DONTWAIT and CF_SHUTR set and http/1.1 doesn't).
-Jarno
varnishtest "h2 chaining 400 error"
#REQUIRE_VERSION=1.9
feature ignore_unknown_macro
haproxy h1 -conf {
defaults
mode http
${no-htx} option http-use-htx
timeout connect 1s
timeout client 1s
timeout server 1s
listen HTTP_in
bind "fd@${HTTP_in}"
server tmpserver abns@proc1 send-proxy-v2
listen HTTP2_in
bind "fd@${HTTP2_in}" proto h2
server tmpserver abns@proc1 send-proxy-v2
frontend fe
bind abns@proc1 accept-proxy
http-request reject if TRUE
default_backend be
backend be
server s1 ${s1_addr}:${s1_port}
} -start
client c1h1 -connect ${h1_HTTP_in_sock} {
txreq
rxresp
expect resp.status == 502
} -run
client c1h2 -connect ${h1_HTTP2_in_sock} {
txpri
stream 0 {
txsettings
rxsettings
txsettings -ack
rxsettings
expect settings.ack == true
} -run
stream 1 {
# warning: -req, -scheme, -url MUST be placed first otherwise
# the H2 protocol is invalid since they are pseudo-headers
txreq \
-req GET \
-scheme "https" \
-url /path/to/file.ext
rxhdrs
expect resp.status == 502
#rxdata -all
} -run
} -run
--
Jarno Huuskonen
[PATCH] DOC: Add HTX part in the documentation
Hi. attached a doc update for the new features of HAProxy 1.9. I hope the patch full fills the CONTRIBUTING rules as I haven't send patched to the list for long time ;-) Regards AleksFrom c0e025e81b87a23f679aff80bddc02a96c4d43b0 Mon Sep 17 00:00:00 2001 From: Aleksandar Lazic Date: Sat, 2 Feb 2019 09:54:55 +0100 Subject: [PATCH] DOC: Add HTX part in the documentation --- doc/configuration.txt | 50 +-- 1 file changed, 48 insertions(+), 2 deletions(-) diff --git a/doc/configuration.txt b/doc/configuration.txt index fe5eb250..38ed12ed 100644 --- a/doc/configuration.txt +++ b/doc/configuration.txt @@ -192,8 +192,7 @@ HAProxy supports 4 connection modes : For HTTP/2, the connection mode resembles more the "server close" mode : given the independence of all streams, there is currently no place to hook the idle server connection after a response, so it is closed after the response. HTTP/2 -is only supported for incoming connections, not on connections going to -servers. +supports now end 2 end mode and trailers which is requierd for gRPC. 1.2. HTTP request @@ -384,6 +383,53 @@ Response headers work exactly like request headers, and as such, HAProxy uses the same parsing function for both. Please refer to paragraph 1.2.2 for more details. +1.3.3. HAProxy HTX +-- +In this version of HAProxy was a new http-engine developed. With this huge +rewrite of the http engine is it now possible to add "easier" some other and +new protocols. + +It is requierd to use option http-use-htx to activate this new engine. + +With HTX is it now possible to handle the following protocols with HAProxy. + +TCP <> HTTP/X +SSL/TLS <> TCP +SSL/TLS <> HTTP/X +HTTP/1.x <> HTTP/2 +HTTP/2 <> HTTP/1.x + +The Diagramm below was described in this post. +https://www.mail-archive.com/haproxy@formilux.org/msg31727.html + + + +-+ stream + | all HTTP processing | layer + +-+ + ^ ^ ^ + HTX | HTX | HTX | normalised + v v v interface + +--+ ++ ++ + |applet| | HTTP/1 | | HTTP/2 | whatever layer (called mux for now + +--+ ++ ++ but may change once we have others, +cache || || could be presentation in OSI) +stats | +--+ | +Lua svc | |TLS | | transport layer + | +--+ | + | | | ++-+ +| TCP/Unix/socketpair | control layer ++-+ + | ++--+ +|file descriptor | socket layer ++--+ + | + +---+ + | operating | + | system | + +---+ + 2. Configuring HAProxy -- -- 2.20.1
