[PR] Add srvkey option to stick-table
Dear list! Author: Thayne McCombs Number of patches: 2 This is an automated relay of the Github pull request: Add srvkey option to stick-table Patch title(s): Add srvkey option to stick-table Harden sa2str agains 107-byte-long abstract unix domain path Link: https://github.com/haproxy/haproxy/pull/979 Edit locally: wget https://github.com/haproxy/haproxy/pull/979.patch && vi 979.patch Apply locally: curl https://github.com/haproxy/haproxy/pull/979.patch | git am - Description: This allows using the address of the server rather than the name of the server for keeping track of servers in a backend for stickiness. Fixes #814 I haven't tested this at all yet, and it still needs some polish, but here is a draft of how to fix #814. This is my first significant contribution to haproxy, so I would not be surprised if I'm doing something terribly wrong, and I'm sure there are at least some small mistakes in it. Initial feedback would be very welcome. Instructions: This github pull request will be closed automatically; patch should be reviewed on the haproxy mailing list (haproxy@formilux.org). Everyone is invited to comment, even the patch's author. Please keep the author and list CCed in replies. Please note that in absence of any response this pull request will be lost.
[ANNOUNCE] haproxy-2.2.6
Hi,
HAProxy 2.2.6 was released on 2020/11/30. It added 49 new commits after
version 2.2.5.
Two major bugs were fixed in this versions, both leading to a memory
corruption and random crashes. The first one was in the SPOE. Some released
spoe applets could still be referenced in the offload streams. There are
many ways to trigger this bug. The easiest is probably during reloads. The
second one was in the checks. The buffers used for I/O were still allocated
by hand during the startup with a specific size (not necessarily the same
than other buffers). But since the recent refactoring of the checks to rely
exclusively on the tcp-checks and to use the underlying mux layer, this part
was totally buggy. Indeed, because these buffers are now passed to a mux,
they may be swapped if a zero-copy is possible. In fact, for now it is
only possible in h2_rcv_buf(). Thus, the bug concretely only existed if a h2
health-check was performed. But, it was a latent bug for other muxes. Now,
these buffers are allocated using the buffer pool. As a side effect, the
"tune.chksize" global option is now deprecated.
Another major bug fixed is a possible overflow in the offset variable when
using the filters. It was in fact an hidden bug, only revealed by another
commit of this release. So, not so major in reality. The commit in question
is a fix on filters to forward all filtered data at the end of http
filtering. When http filtering ends, if there are some filtered data not
forwarded yet, we now forward them in flt_http_end(). It is required for
tunnel established using a CONNECT.
The last major bug fixed is an inter-release bug, in a Willy's attempt to
fix a decoding problem in the peers implementation which was leading to
protocol errors. Frédéric also fixed two other bugs on peers and added some
traces so that exchanges can now be observed. Everything should be fixed on
this part now.
Amaury fixed a problem in the checks which could lead to a segfault when a
pure tcp-check was performed on an HTTP server. Now, extra tests are
performed during startup to select the right mode and an error is triggered
if an incompatibility is detected.
A bug in the http-after-response ruleset was fixed. It is unexpected to
evaluate these rules on an empty response. This may happen when an empty
errorfile is returned. This case is now properly handled.
Maciej fixed the sample fetches to retrieve messages cookies when called
without cookie name. This case was never properly handled, contrary to what
the doc says. He also implemented the "-m" argument to the "del-header"
action to match on a full header name, a substring, a prefix, a suffix, or
even a regex.
Thierry fixed a bug in string pattern matching. Constant sample fetches must
be duplicated first to not overwrite it when the trailing 0 is added.
William Lallemand fixed a SSL bug, a segfault on startup when a certificate
using the X509v3 AKID extension without the keyid field was loaded. And
ssl_{c,s}_chain_der fetch methods, added by William Dauchy, was backported.
On the build part, Tim added the DEBUG flags in haproxy -vv output. He also
added them in .build_opts file, forcing recompilation if the flags change.
The configuration manual was improved. Among other, Willy added a better
description of the configuration file format and the escaping/quoting rules.
The other fixes and patches are listed in the complete changelog below. It
is highly recommended to update to this version.
Please find the usual URLs below :
Site index : http://www.haproxy.org/
Discourse: http://discourse.haproxy.org/
Slack channel: https://slack.haproxy.org/
Issue tracker: https://github.com/haproxy/haproxy/issues
Wiki : https://github.com/haproxy/wiki/wiki
Sources : http://www.haproxy.org/download/2.2/src/
Git repository : http://git.haproxy.org/git/haproxy-2.2.git/
Git Web browsing : http://git.haproxy.org/?p=haproxy-2.2.git
Changelog: http://www.haproxy.org/download/2.2/src/CHANGELOG
Cyril's HTML doc : http://cbonte.github.io/haproxy-dconv/
---
Complete changelog :
Amaury Denoyelle (3):
BUG/MEDIUM: check: reuse srv proto only if using same mode
MINOR: check: report error on incompatible proto
MINOR: check: report error on incompatible connect proto
Christopher Faulet (20):
MINOR: http-htx: Add understandable errors for the errorfiles parsing
BUG/MINOR: http-htx: Just warn if payload of an errorfile doesn't match
the C-L
DOC: config: Fix a typo on ssl_c_chain_der
BUG/MINOR: http-fetch: Fix calls w/o parentheses of the cookie sample
fetches
BUG/MINOR: http-htx: Handle warnings when parsing http-error and
http-errors
BUG/MAJOR: spoe: Be sure to remove all references on a released spoe
applet
MINOR: spoe: Don't close connection in sync mode on processing timeout
BUG/MINOR: tcpcheck: Don't warn on unused rules if check option is after
MINOR: init:
Re: [ANNOUNCE] haproxy-2.2.6
Christopher, Willy, Am 30.11.20 um 18:37 schrieb Christopher Faulet: > Your Name (1): > MINOR: plock: use an ARMv8 instruction barrier for the pause > instruction > I stumbled upon that name. The commit is this one: https://github.com/haproxy/haproxy/commit/1e237d037b3a45ec92d1dfa80dfd2c6bd7fc3af9. >From the wording in commit message I would assume that it's not a third party contribution. Did someone of you change machines without a proper git setup? Best regards Tim Düsterhus
Re: [ANNOUNCE] haproxy-2.2.6
someone who wishes to stay anonymous :) пн, 30 нояб. 2020 г. в 23:37, Tim Düsterhus : > Christopher, > Willy, > > Am 30.11.20 um 18:37 schrieb Christopher Faulet: > > Your Name (1): > > MINOR: plock: use an ARMv8 instruction barrier for the pause > > instruction > > > > I stumbled upon that name. The commit is this one: > > https://github.com/haproxy/haproxy/commit/1e237d037b3a45ec92d1dfa80dfd2c6bd7fc3af9 > . > > From the wording in commit message I would assume that it's not a third > party contribution. Did someone of you change machines without a proper > git setup? > > Best regards > Tim Düsterhus > >
Re: [ANNOUNCE] haproxy-2.2.6
On Mon, Nov 30, 2020 at 07:34:51PM +0100, Tim Düsterhus wrote: > Christopher, > Willy, > > Am 30.11.20 um 18:37 schrieb Christopher Faulet: > > Your Name (1): > > MINOR: plock: use an ARMv8 instruction barrier for the pause > > instruction > > > > I stumbled upon that name. The commit is this one: > https://github.com/haproxy/haproxy/commit/1e237d037b3a45ec92d1dfa80dfd2c6bd7fc3af9. > > From the wording in commit message I would assume that it's not a third > party contribution. Did someone of you change machines without a proper > git setup? Argh! good catch, it's me :-( I did it on the aforementioned machine. I hate doing remote development on test machines, I always do mistakes like these. Too late now, sorry. Willy
Re: [PATCH] DOC: Clarify %HP description in log-format
Hi I have a small patch which adds a new log-format variable %HPR for logging relative path. I hope it is clean and useful! :) Kind regards, czw., 26 lis 2020 o 19:08 Willy Tarreau napisał(a): > Hi Maciej, > > On Thu, Nov 26, 2020 at 12:39:19PM +0100, Maciej Zdeb wrote: > > Hi, > > > > Since 30ee1efe676e8264af16bab833c621d60a72a4d7 "MEDIUM: h2: use the > > normalized URI encoding for absolute form requests" we're using absolute > > URI when possible. As stated in the commit message this also changed the > > way it is reported in logs, especially for H2. > > > > Docs describes %HP as "HTTP request URI without query string (path)" and > > the word "path" suggests that %HP behaves exactly the same as "path" > sample > > fetch (it surprised me after HAProxy update that it's not true). > Shouldn't > > we delete the "(path)" from that description? Even better would be to > > change it to "rel_path/abs_path" like it is in rfc or "relative/absolute > > URI" but it is too long. :) If I'm the only one that got confused then it > > may stay. But... > > > > Do you think that it might be useful to implement another var, let's say > > %HRU described as "HTTP request relative URI"? :) Usually in my logs I'm > > not interested in absolute uri and relative is sufficient. > > Few people play with absolute URIs in practice, that's why such issues > started to pop up very late. Your example above is just yet another proof > of this. So you're probalbly not the only one, but the few others might > have silently fixed the meaning in their mind while you've fixed it in the > doc, which is better! > > Applied now, thank you! > Willy > 0001-MINOR-log-Logging-relative-URI-path-with-HPR.patch Description: Binary data
(possibly off topic) how to handle Chrome on SSL mass hosting ?
Hello, I'm looking for best practices related to please Chrome on mass SSL hosting. let us consider 3 websites a.example.com b.example.com c.example.com they share wildcard *.example.com certificate and they share single IP address. in such case Chrome decides to open a single http2 connection instead of 3 separate connections. while I do not mind to have such optimization, but when 'a.example.com" responds with http2 GOAWAY, that affects also "b.example.com" and " c.example.com". Chrome is not clever enough to open new connections instead of abandoned one. I guess here are people running similar high density SSL hosting, do you have some approaches to please Chrome ? I would be happy if I can tell him to open separate connections for the domains that I wish. Ilya
[PR] Skip unsupported ciphers for ecdsa cert
Dear list! Author: Marcoen Hirschberg Number of patches: 3 This is an automated relay of the Github pull request: Skip unsupported ciphers for ecdsa cert Patch title(s): MINOR: ssl: variable renames for clarity MINOR: ssl: skip unknown client cipher BUG/MINOR: ssl: only choose ECDSA cert if server and client have common ECDSA ciphers Link: https://github.com/haproxy/haproxy/pull/983 Edit locally: wget https://github.com/haproxy/haproxy/pull/983.patch && vi 983.patch Apply locally: curl https://github.com/haproxy/haproxy/pull/983.patch | git am - Description: Instructions: This github pull request will be closed automatically; patch should be reviewed on the haproxy mailing list (haproxy@formilux.org). Everyone is invited to comment, even the patch's author. Please keep the author and list CCed in replies. Please note that in absence of any response this pull request will be lost.
Re: [PR] Skip unsupported ciphers for ecdsa cert
will it run on LibreSSL, BoringSSL ? вт, 1 дек. 2020 г. в 00:26, PR Bot : > Dear list! > > Author: Marcoen Hirschberg > Number of patches: 3 > > This is an automated relay of the Github pull request: >Skip unsupported ciphers for ecdsa cert > > Patch title(s): >MINOR: ssl: variable renames for clarity >MINOR: ssl: skip unknown client cipher >BUG/MINOR: ssl: only choose ECDSA cert if server and client have common > ECDSA ciphers > > Link: >https://github.com/haproxy/haproxy/pull/983 > > Edit locally: >wget https://github.com/haproxy/haproxy/pull/983.patch && vi 983.patch > > Apply locally: >curl https://github.com/haproxy/haproxy/pull/983.patch | git am - > > Description: > > > Instructions: >This github pull request will be closed automatically; patch should be >reviewed on the haproxy mailing list (haproxy@formilux.org). Everyone > is >invited to comment, even the patch's author. Please keep the author and >list CCed in replies. Please note that in absence of any response this >pull request will be lost. > >
Re: (possibly off topic) how to handle Chrome on SSL mass hosting ?
Ilya,
Am 30.11.20 um 20:21 schrieb Илья Шипицин:
> I guess here are people running similar high density SSL hosting, do you
> have some approaches to please Chrome ? I would be happy if I can tell him
> to open separate connections for the domains that I wish.
>
Use HTTP 421 Misdirected Request:
> http-request set-var(txn.host)hdr(host)
> http-request deny deny_status 400 unless { req.hdr_cnt(host) eq 1 }
> http-request deny deny_status 421 unless {
> ssl_fc_sni,strcmp(txn.host) eq 0 }
Or just use a dedicated certificate or IPv6 address per customer.
Best regards
Tim Düsterhus
Re: [PR] Skip unsupported ciphers for ecdsa cert
Good point, I just tried with boringssl and compilation failed. Thanks for pointing that out. On Mon, Nov 30, 2020 at 8:28 PM Илья Шипицин wrote: > will it run on LibreSSL, BoringSSL ? > > вт, 1 дек. 2020 г. в 00:26, PR Bot : > >> Dear list! >> >> Author: Marcoen Hirschberg >> Number of patches: 3 >> >> This is an automated relay of the Github pull request: >>Skip unsupported ciphers for ecdsa cert >> >> Patch title(s): >>MINOR: ssl: variable renames for clarity >>MINOR: ssl: skip unknown client cipher >>BUG/MINOR: ssl: only choose ECDSA cert if server and client have >> common ECDSA ciphers >> >> Link: >>https://github.com/haproxy/haproxy/pull/983 >> >> Edit locally: >>wget https://github.com/haproxy/haproxy/pull/983.patch && vi 983.patch >> >> Apply locally: >>curl https://github.com/haproxy/haproxy/pull/983.patch | git am - >> >> Description: >> >> >> Instructions: >>This github pull request will be closed automatically; patch should be >>reviewed on the haproxy mailing list (haproxy@formilux.org). Everyone >> is >>invited to comment, even the patch's author. Please keep the author and >>list CCed in replies. Please note that in absence of any response this >>pull request will be lost. >> >>
Re: [PATCH] DOC: Clarify %HP description in log-format
Hi Maciej, On Mon, Nov 30, 2020 at 08:17:42PM +0100, Maciej Zdeb wrote: > Hi > > I have a small patch which adds a new log-format variable %HPR for logging > relative path. I hope it is clean and useful! :) What's the difference with %[path] ? I'm trying to have a sample-fetch equivalent for all individual log tags so I'm a bit worried about seeing new ones being introduced if they can already be expressed differently. Thanks, Willy
Re: [PATCH] DOC: Clarify %HP description in log-format
There's no difference with %[path] in fact this patch only exposes "path" fetch as %HPR. It's only an usability matter. Usually I'm setting some sane log-format in the defaults section (where I can't use %[path]) and only for some critically important frontends I'm overwriting it to be more verbose. wt., 1 gru 2020 o 04:12 Willy Tarreau napisał(a): > Hi Maciej, > > On Mon, Nov 30, 2020 at 08:17:42PM +0100, Maciej Zdeb wrote: > > Hi > > > > I have a small patch which adds a new log-format variable %HPR for > logging > > relative path. I hope it is clean and useful! :) > > What's the difference with %[path] ? I'm trying to have a sample-fetch > equivalent for all individual log tags so I'm a bit worried about seeing > new ones being introduced if they can already be expressed differently. > > Thanks, > Willy >
Re: [PATCH] DOC: Clarify %HP description in log-format
On Tue, Dec 01, 2020 at 06:54:16AM +0100, Maciej Zdeb wrote: > There's no difference with %[path] in fact this patch only exposes "path" > fetch as %HPR. It's only an usability matter. Usually I'm setting some sane > log-format in the defaults section (where I can't use %[path]) and only for > some critically important frontends I'm overwriting it to be more verbose. Why do you say you can't use %[path] in the defaults section ? Willy
Re: [PATCH] DOC: Clarify %HP description in log-format
For such defaults section: defaults log stdout local0 log-format 'path:%[path]' I'm getting following error: [ALERT] 335/060923 (13259) : Parsing [haproxy.cfg:11]: failed to parse log-format : sample fetch may not be reliably used here because it needs 'HTTP request headers' which is not available here. What I'm doing wrong? :) wt., 1 gru 2020 o 06:56 Willy Tarreau napisał(a): > On Tue, Dec 01, 2020 at 06:54:16AM +0100, Maciej Zdeb wrote: > > There's no difference with %[path] in fact this patch only exposes "path" > > fetch as %HPR. It's only an usability matter. Usually I'm setting some > sane > > log-format in the defaults section (where I can't use %[path]) and only > for > > some critically important frontends I'm overwriting it to be more > verbose. > > Why do you say you can't use %[path] in the defaults section ? > > Willy >
Re: [PATCH] DOC: Clarify %HP description in log-format
On Tue, Dec 01, 2020 at 07:13:32AM +0100, Maciej Zdeb wrote: > For such defaults section: > defaults > log stdout local0 > log-format 'path:%[path]' > > I'm getting following error: > [ALERT] 335/060923 (13259) : Parsing [haproxy.cfg:11]: failed to parse > log-format : sample fetch may not be reliably used here because it > needs 'HTTP request headers' which is not available here. > > What I'm doing wrong? :) You're missing "mode http" in your defaults section. I tend to recommend not to mix TCP and HTTP defaults, because that tends to make TCP proxies inherit lots of HTTP settings. The checks are done everywhere (as you can see here), but this requires a lot of dedicated code to deal with corner cases, and I must admit I never know if from time to time an HTTP directive slips into a TCP proxy. The good practice instead is to have one "defaults" section for TCP and another one later for HTTP. I've long wanted to have named defaults that could be reused in proxies. This would require to extend the "frontend", "listen" and "backend" directives to take a section name at the declaration moment. For example: defaults tcp timeout client 1h defaults http mode http timeout client 10s frontend f1 from tcp bind :1234 frontend f2 from http bind :80 The last declared section would always set the current defaults though. If anyone is interested in working on this, it's not very difficult, the config parser currently knows about a single "defproxy", instead it could perform a lookup (or even copy it from the current designated one). Willy
Re: [PATCH] DOC: Clarify %HP description in log-format
Even with mode http: defaults mode http log stdout local0 log-format 'path:%[path]' it still fails. What is more even if you use %[path] on http frontend: defaults mode http log stdout local0 frontend front mode http # http-request set-var(txn.path) path # log-format 'path:%[var(txn.path)]' log-format 'path:%[path]' bind 127.0.0.1: default_backend back backend back mode http server srv 127.0.0.1:80 check it will also fail. The only way I know for using fetches in log-format is through set-var()/var() (commented lines in above config). Idea with named defaults is brilliant! :) wt., 1 gru 2020 o 07:26 Willy Tarreau napisał(a): > On Tue, Dec 01, 2020 at 07:13:32AM +0100, Maciej Zdeb wrote: > > For such defaults section: > > defaults > > log stdout local0 > > log-format 'path:%[path]' > > > > I'm getting following error: > > [ALERT] 335/060923 (13259) : Parsing [haproxy.cfg:11]: failed to parse > > log-format : sample fetch may not be reliably used here because > it > > needs 'HTTP request headers' which is not available here. > > > > What I'm doing wrong? :) > > You're missing "mode http" in your defaults section. I tend to recommend > not > to mix TCP and HTTP defaults, because that tends to make TCP proxies > inherit > lots of HTTP settings. The checks are done everywhere (as you can see > here), > but this requires a lot of dedicated code to deal with corner cases, and I > must admit I never know if from time to time an HTTP directive slips into a > TCP proxy. > > The good practice instead is to have one "defaults" section for TCP and > another one later for HTTP. I've long wanted to have named defaults that > could be reused in proxies. This would require to extend the "frontend", > "listen" and "backend" directives to take a section name at the declaration > moment. For example: > > defaults tcp > timeout client 1h > > defaults http > mode http > timeout client 10s > > frontend f1 from tcp > bind :1234 > > frontend f2 from http > bind :80 > > The last declared section would always set the current defaults though. > If anyone is interested in working on this, it's not very difficult, the > config parser currently knows about a single "defproxy", instead it could > perform a lookup (or even copy it from the current designated one). > > Willy >
Re: [PATCH] DOC: Clarify %HP description in log-format
On Tue, Dec 01, 2020 at 07:55:10AM +0100, Maciej Zdeb wrote: > Even with mode http: > > defaults > mode http > log stdout local0 > log-format 'path:%[path]' > > it still fails. > > What is more even if you use %[path] on http frontend: > > defaults > mode http > log stdout local0 > > frontend front > mode http > # http-request set-var(txn.path) path > # log-format 'path:%[var(txn.path)]' > log-format 'path:%[path]' > bind 127.0.0.1: > default_backend back > backend back > mode http > server srv 127.0.0.1:80 check > > it will also fail. The only way I know for using fetches in log-format is > through set-var()/var() (commented lines in above config). Ah I'm stupid, sorry! The problem is not caused by the defaults section but by the fact that %[path] extracts the path from the request while your proposal takes it from the copy of the URI that was kept for logging. OK, at first glance your patch looks good. However the description of the token doesn't seem perfect. Given that we already use the terminology "path", I'd rather make it clear that it's the patth. What about, for example, "%HPO" for "HTTP path only (without host nor query string)" ? Thanks, Willy
[ANNOUNCE] haproxy-2.4-dev2
Hi, HAProxy 2.4-dev2 was released on 2020/12/01. It added 43 new commits after version 2.4-dev1. Given that 2.4-dev1 experienced a few hickups, I preferred to emit a replacement one quickly to help with testing. We've spent more than one week dealing with races in threads and other issues, it was not exactly fun, but the good news is that once all of these are addressed at once, we're expected to get a better experience again. Roughly out of my head, there was a data filter keeping some data stuck and backend connection established (that caused me to temporarily revert on haproxy.org but it's been OK for one week now), health checks using a their own buffers that were not compatible with H2, memory barrier issues on some ARM machines having stricter ordering requirements (the AWS Graviton2 CPU uses awesome ARM Neoverse-N1 cores but you have to be kind with them), and a missing error handling in the peers code that was woken up by my previous fix, causing endless loops and panics on truncated messages. Among the few other things, some users noticed that the default log format was accidently changed in 2.3 when introducing the new formats, because the host name is now always being sent while in the past it was sent only when "log-send-hostname" was set. Emeric changed this to turn back to the old behavior by adding a new "local" message format that's suitable for use with a local logger and made it the default instead of rfc3164. This will be backported to 2.3 to avoid some pain dealing with the logs. The cache was improved to start to support the Vary header (still limited to Accept-Encoding and Referer for now) but some more work is currently ongoing in this area. Layer 7 retries now support HTTP 401 and 403 status codes. It's obviously not recommended but if you do this you probably know this already. The tcp checks can now enforce the ok-status that may be used to turn a server to soft-stop mode for example (equivalent to disable-on-404). And The rest are basically cleanups. A side note for those running haproxy on AWS's new ARM machines (t4g, m6g, c6g, r6g): I could test the impact of the new ARMv8.1 atomic instructions supported by these CPUs, and the gains in scalability are tremendous, with 16 cores I could observe a jump from 101k to 420k req/s. Said differently, the older ones bring a huge overhead. If you're using haproxy there, do not forget to add "CPU=native" to your build line to benefit from this, and you'll probably need a much smaller machine for the same workload. Please find the usual URLs below : Site index : http://www.haproxy.org/ Discourse: http://discourse.haproxy.org/ Slack channel: https://slack.haproxy.org/ Issue tracker: https://github.com/haproxy/haproxy/issues Wiki : https://github.com/haproxy/wiki/wiki Sources : http://www.haproxy.org/download/2.4/src/ Git repository : http://git.haproxy.org/git/haproxy.git/ Git Web browsing : http://git.haproxy.org/?p=haproxy.git Changelog: http://www.haproxy.org/download/2.4/src/CHANGELOG Cyril's HTML doc : http://cbonte.github.io/haproxy-dconv/ Willy --- Complete changelog : Christopher Faulet (13): BUG/MAJOR: filters: Always keep all offsets up to date during data filtering BUG/MINOR: tcpcheck: Don't forget to reset tcp-check flags on new kind of check MINOR: tcpcheck: Don't handle anymore in-progress send rules in tcpcheck_main BUG/MAJOR: tcpcheck: Allocate input and output buffers from the buffer pool MINOR: tcpcheck: Don't handle anymore in-progress connect rules in tcpcheck_main MINOR: config: Deprecate and ignore tune.chksize global option MINOR: config: Add a warning if tune.chksize is used REORG: tcpcheck: Move check option parsing functions based on tcp-check MINOR: check: Always increment check health counter on CONPASS MINOR: tcpcheck: Add support of L7OKC on expect rules error-status argument DOC: config: Make disable-on-404 option clearer on transition conditions DOC: config: Move req.hdrs and req.hdrs_bin in L7 samples fetches section BUG/MINOR: http-fetch: Fix smp_fetch_body() when called from a health-check Emeric Brun (1): BUG/MEDIUM: local log format regression. Ilya Shipitsin (5): CLEANUP: remove unused function "ssl_sock_is_ckch_valid" BUILD: SSL: add BoringSSL guarding to "RAND_keep_random_devices_open" BUILD: SSL: do not "update" BoringSSL version equivalent anymore CI: github actions: update LibreSSL to 3.3.0 CI: github actions: enable 51degrees feature Joao Morais (1): DOC: better describes how to configure a fallback crt Julien Pivotto (1): MINOR: stream: Add level 7 retries on http error 401, 403 Maciej Zdeb (2): BUG/MEDIUM: http_act: Restore init of log-format list DOC: Clarify %HP description in log-format Olivier Houchard (1): BUG/MEDIUM: lists: Lock the element whi
Re: [PATCH] DOC: Clarify %HP description in log-format
wt., 1 gru 2020 o 08:14 Willy Tarreau napisał(a): > Ah I'm stupid, sorry! The problem is not caused by the defaults section > but by the fact that %[path] extracts the path from the request while your > proposal takes it from the copy of the URI that was kept for logging. > No need to be sorry. :) I'm the one that is learning here. I didn't notice that logging is done from the copy of URI and didn't give you full information about the difference between %HPR and %[path]. OK, at first glance your patch looks good. However the description of > the token doesn't seem perfect. Given that we already use the terminology > "path", I'd rather make it clear that it's the patth. What about, for > example, "%HPO" for "HTTP path only (without host nor query string)" ? > I was scratching my head for a long time with this. "HTTP path only" sounds much better to me. I've adjusted the patch. Thank you Willy! 0001-MINOR-log-Logging-HTTP-path-only-with-HPO.patch Description: Binary data
