[PATCH] DOC: add description of pidfile in master-worker mode
Hi, all, pidfile is handled differently in daemon mode and master-worker mode. I added the difference to the document. Best regards, MIZUTA Takeshi 0001-DOC-add-description-of-pidfile-in-master-worker-mode.patch Description: 0001-DOC-add-description-of-pidfile-in-master-worker-mode.patch
stable-bot: Bugfixes waiting for a release 2.2 (18), 2.1 (13), 2.0 (8), 1.8 (6)
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 2.2.2 was issued on 2020-07-31. There are currently 18 patches in the queue cut down this way: - 1 MAJOR, first one merged on 2020-08-05 - 6 MEDIUM, first one merged on 2020-08-05 - 11 MINOR, first one merged on 2020-08-05 Thus the computed ideal release date for 2.2.3 would be 2020-08-19, which was one week ago. Last release 2.1.8 was issued on 2020-07-31. There are currently 13 patches in the queue cut down this way: - 4 MEDIUM, first one merged on 2020-08-05 - 9 MINOR, first one merged on 2020-08-11 Thus the computed ideal release date for 2.1.9 would be 2020-09-04, which is in two weeks or less. Last release 2.0.17 was issued on 2020-07-31. There are currently 8 patches in the queue cut down this way: - 4 MEDIUM, first one merged on 2020-08-05 - 4 MINOR, first one merged on 2020-08-11 Thus the computed ideal release date for 2.0.18 would be 2020-10-04, which is in six weeks or less. Last release 1.8.26 was issued on 2020-08-03. There are currently 6 patches in the queue cut down this way: - 2 MEDIUM, first one merged on 2020-08-05 - 4 MINOR, first one merged on 2020-08-03 Thus the computed ideal release date for 1.8.27 would be 2020-10-26, which is in nine weeks or less. The current list of patches in the queue is: - 2.2 - MAJOR : dns: disabled servers through SRV records never recover - 2.2 - MEDIUM : ssl: never generates the chain from the verify store - 2.1, 2.2 - MEDIUM : ssl: memory leak of ocsp data at SSL_CTX_free() - 1.8, 2.0 - MEDIUM : mux-h2: Don't fail if nothing is parsed for a legacy chunk response - 2.0, 2.1, 2.2 - MEDIUM : mux-h1: Refresh H1 connection timeout after a synchronous send - 2.2 - MEDIUM : ssl: fix the ssl-skip-self-issued-ca option - 1.8, 2.0, 2.1, 2.2- MEDIUM : map/lua: Return an error if a map is loaded during runtime - 2.0, 2.1, 2.2 - MEDIUM : htx: smp_prefetch_htx() must always validate the direction - 1.8, 2.0, 2.1, 2.2- MINOR : lua: Check argument type to convert it to IPv4/IPv6 arg validation - 2.1, 2.2 - MINOR : ssl: fix memory leak at OCSP loading - 2.1, 2.2 - MINOR : lua: Duplicate map name to load it when a new Map object is created - 2.1, 2.2 - MINOR : arg: Fix leaks during arguments validation for fetches/converters - 1.8 - MINOR : dns: ignore trailing dot - 2.0, 2.1, 2.2 - MINOR : snapshots: leak of snapshots on deinit() - 2.1, 2.2 - MINOR : converters: Store the sink in an arg pointer for debug() converter - 2.2 - MINOR : ssl: ssl-skip-self-issued-ca requires >= 1.0.2 - 1.8, 2.0, 2.1, 2.2- MINOR : lua: Check argument type to convert it to IP mask in arg validation - 2.1, 2.2 - MINOR : lua: Duplicate lua strings in sample fetches/converters arg array - 1.8, 2.0, 2.1, 2.2- MINOR : stats: use strncmp() instead of memcmp() on health states - 2.2 - MINOR : spoa-server: fix size_t format printing -- 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 v3 0/2] Certificate Generation Enhancements
On Sun, Aug 23, 2020 at 01:58:11PM +0300, gers...@gmail.com wrote: > From: Shimi Gersner > > Hi Team, William, > > Took me some time to get back to this. This version resolves all > comments from previous patch. > As suggested, this is now the default behaviour. > > PR Reference https://github.com/Azure/haproxy/tree/wip/sgersner/ca-features > > Thanks, > Shimi. > > Shimi Gersner (2): > MEDIUM: ssl: Support certificate chaining for certificate generation > MINOR: ssl: Support SAN extension for certificate generation > > include/haproxy/listener-t.h | 3 +- > src/ssl_sock.c | 147 +-- > 2 files changed, 105 insertions(+), 45 deletions(-) > > -- > 2.27.0 I just pushed the two patches in the master repository. It made me realize that we don't have any reg-tests for this feature in HAProxy. Contributions are also welcomed regarding the reg-tests :-) Thanks! -- William Lallemand
RE: Logging using %HP (path) produce different results with H1 and H2
Hi Willy, On Tue, Aug 25, 2020 at 14:53:05PM +0200, Willy Tarreau wrote: > Thus an HTTP/2 request effectively "looks like" an HTTP/1 request using > an absolute URI. What causes the mess in the logs is that such HTTP/1 > requests are rarely used (most only for proxies), but they are perfectly > valid and given that they are often used to take routing decisions, it's > mandatory that they are part of the logs. For example if you decide that > every *url* starting with "/img" has to be routed to the static server > and the rest to the application, you're forgetting that "https://foo/img/"; > is valid as well and will be routed to the application. That's what I do > not want to report fake or reconstructed information in the logs. > > In 1.8, what happened when we introduced H2 is that it was directly turned > into HTTP/1.1 before being processed and that given that we didn't support > server-side H2, the most seamless way to handle it was to just replace > everything with origin requests (no authority). That remained till 2.0 > since it was not really acceptable to imagine that depending on whether > you enabled HTX or not you'd get different logs for the exact same request. > But now we cannot cheat anymore, it had caused too much trouble already I clearly understood the problem is more complex than it seems in the first place, due to protocol + internal representations changes that occured recently. > What I understand however is that it's possible that we need to rethink > what we're logging. Maybe instead of logging the URI by default (and missing > the Host in HTTP/1) we ought to instead log the scheme, authority and path > parts. These are not always there (scheme or authority in H1) but we can > log an empty field like "-" in this case. Clearly that was my point. Especially when you manipulate "high-level variables" such as %HP %HQ %HU and so on, you probably expect the hard work to be done for you. > We cannot realistically do that in the default "httplog" format, but we > can imagine a new default format which would report such info (htxlog?), > or maybe renaming httplog to http-legacy-log and changing the httplog's > default. We should then consider this opportunity to revisit certain > fields that do not make sense anymore, like the "~" in front of the > frontend's name for SSL, the various timers that need to report idle > and probably user-facing time instead of just data, etc. I +1 on this as a tradeoff (even though ~ in front frontends is already OK by using %f vs. %ft - I understand it's more a matter of leveraging this change in order to remove tech debt). > So I think it's the right place to open such a discussion (what we should > log and whether or not it loses info by default or requires to duplicate > some data while waiting for the response), so that we can reach a better > and more modern solution. I'm open to proposals. That's wider than I initially thought :) -- Pierre
Re: [*EXT*] http/2 fine tuning
That's improvement ! Are there similar settings in haproxy to get these numbers ? Ionel De: " ???" À: "haproxy" Envoyé: Mardi 25 Août 2020 09:25:55 Objet: [*EXT*] http/2 fine tuning just in case someone missed [ https://blog.cloudflare.com/delivering-http-2-upload-speed-improvements/ | https://blog.cloudflare.com/delivering-http-2-upload-speed-improvements/ ] -- 232 avenue Napoleon BONAPARTE 92500 RUEIL MALMAISON Capital EUR 219 300,00 - RCS Nanterre B 408 832 301 - TVA FR 09 408 832 301
Re: Logging using %HP (path) produce different results with H1 and H2
Willy, Am 25.08.20 um 14:53 schrieb Willy Tarreau: > So I think it's the right place to open such a discussion (what we should > log and whether or not it loses info by default or requires to duplicate > some data while waiting for the response), so that we can reach a better > and more modern solution. I'm open to proposals. > %ID by default, please. See also this issue: https://github.com/haproxy/haproxy/issues/401#issuecomment-562776569 and this: https://github.com/haproxy/haproxy/issues/771 Best regards Tim Düsterhus
Re: Logging using %HP (path) produce different results with H1 and H2
Hi Pierre, On Mon, Aug 24, 2020 at 08:17:05AM +, Pierre Cheynier wrote: > On Fri, Aug 21, 2020 at 8:11 PM William Dauchy wrote: > > So awesome to get the first response from your direct colleague :) > > > I believe this is expected; this behaviour has changed since v2.1 though. > > Indeed, we don't use this logging variable since a long time, so I'm not > really able to confirm if this is so new. > Anyway, I understand this is related to handling h2 and its specifics, still > I think there should be something to fix (in one way or the other) to get > back to a consistent/deterministic meaning of %HP (and maybe in other places > where this had an impact). > > Willy, any thought about this? What is certain is that I don't want to start logging a false or misleading information. The issues stems from browsers using a different way to represent a resource in a request depending on HTTP versions (and it's not their fault, it's the recommended way to do it). In HTTP/1.x we used to have : - relative URIs made of a path only with a separate Host header - absolute URIs made of a scheme + host + path and the Host header having to be repeated. In HTTP/2 this has been greatly simplified and only the second full URI was kept by default. In order to save servers from having to parse these elements, they are sent already split into: - a ":scheme" pseudo header holding the scheme of the URI - a ":authority" pseudo header holding the equivalent of the host part of the URI - a ":path" pseudo header holding the path part of the URI And no Host header is needed anymore. Thus an HTTP/2 request effectively "looks like" an HTTP/1 request using an absolute URI. What causes the mess in the logs is that such HTTP/1 requests are rarely used (most only for proxies), but they are perfectly valid and given that they are often used to take routing decisions, it's mandatory that they are part of the logs. For example if you decide that every *url* starting with "/img" has to be routed to the static server and the rest to the application, you're forgetting that "https://foo/img/"; is valid as well and will be routed to the application. That's what I do not want to report fake or reconstructed information in the logs. In 1.8, what happened when we introduced H2 is that it was directly turned into HTTP/1.1 before being processed and that given that we didn't support server-side H2, the most seamless way to handle it was to just replace everything with origin requests (no authority). That remained till 2.0 since it was not really acceptable to imagine that depending on whether you enabled HTX or not you'd get different logs for the exact same request. But now we cannot cheat anymore, it had caused too much trouble already What I understand however is that it's possible that we need to rethink what we're logging. Maybe instead of logging the URI by default (and missing the Host in HTTP/1) we ought to instead log the scheme, authority and path parts. These are not always there (scheme or authority in H1) but we can log an empty field like "-" in this case. We cannot realistically do that in the default "httplog" format, but we can imagine a new default format which would report such info (htxlog?), or maybe renaming httplog to http-legacy-log and changing the httplog's default. We should then consider this opportunity to revisit certain fields that do not make sense anymore, like the "~" in front of the frontend's name for SSL, the various timers that need to report idle and probably user-facing time instead of just data, etc. There was something important I've been wanting for a few versions, which was to have named log formats that we could declare in a central place and use everywhere. It would tremendously help here. I know it can be done using environment variables declared in the global section but I personally find this ugly. So I think it's the right place to open such a discussion (what we should log and whether or not it loses info by default or requires to duplicate some data while waiting for the response), so that we can reach a better and more modern solution. I'm open to proposals. Cheers, Willy
Re: HAProxy 2.2.2 CE issue report
On Tue, Aug 25, 2020 at 10:23:27AM +0200, Vincent Bernat wrote: > ? 24 août 2020 21:59 +03, Milen Simeonov: > > > frontend fe_main > > bind 127.0.0.1:443 ssl crt-list /etc/haproxy/certs/websites.crt_list > > I am not able to reproduce. The configuration is missing a path to a > certificate. Does it also crash if you don't provide a crt-list? FWIW I couldn't reproduce it either and am also suspecting something odd in the crt-list. Willy
Re: HAProxy 2.2.2 CE issue report
❦ 24 août 2020 21:59 +03, Milen Simeonov: > frontend fe_main > bind 127.0.0.1:443 ssl crt-list /etc/haproxy/certs/websites.crt_list I am not able to reproduce. The configuration is missing a path to a certificate. Does it also crash if you don't provide a crt-list? -- Don't comment bad code - rewrite it. - The Elements of Programming Style (Kernighan & Plauger)
http/2 fine tuning
just in case someone missed https://blog.cloudflare.com/delivering-http-2-upload-speed-improvements/
