Hi,
I have an HTTP frontend running on specific PORT for the purpose of
external health checks, so typical:
mode http
option httplog
I noticed the log lines though for haproxy v2.0.13 I installed from the
usual Ubuntu PPA from Vincent:
# haproxy -v
HA-Proxy version 2.0.13-1ppa1~bionic 2
On Wed, Feb 26, 2020 at 04:20:49PM +0100, Tim Duesterhus wrote:
> Previously when the `unique-id-format` contained non-deterministic parts,
> such as the `uuid` fetch each use of the `unique-id` fetch would generate
> a new unique ID, replacing the old one. The following configuration shows
> the e
On Wed, Feb 26, 2020 at 04:20:50PM +0100, Tim Duesterhus wrote:
> Currently unique IDs for a stream are generated using repetitive code in
> multiple locations, possibly allowing for inconsistent behavior.
Just a few minor coding style comments :
> +int stream_generate_unique_id(struct stream *st
On Wed, Feb 26, 2020 at 04:20:51PM +0100, Tim Duesterhus wrote:
> This patch replaces the ad-hoc generation of stream's `unique_id` values
> by calls to `stream_generate_unique_id`.
It seems to me that it won't generate the unique_id anymore if there
is no unique-id-header directive in the config
Previously when the `unique-id-format` contained non-deterministic parts,
such as the `uuid` fetch each use of the `unique-id` fetch would generate
a new unique ID, replacing the old one. The following configuration shows
the error:
global
log stdout format short daemon
listen test
Willy,
during my investigation regarding unique IDs for TCP streams I noticed that
the `unique-id` sample fetch had a bug. Thus I spun out the first pieces of
my work into this patchset. The first patch fixes the bug in the fetch. The
other patches clean up the repetitive generation of the unique
This patch replaces the ad-hoc generation of stream's `unique_id` values
by calls to `stream_generate_unique_id`.
---
src/http_ana.c | 14 ++
src/http_fetch.c | 17 -
src/log.c| 3 +--
3 files changed, 15 insertions(+), 19 deletions(-)
diff --git a/src/http_
Currently unique IDs for a stream are generated using repetitive code in
multiple locations, possibly allowing for inconsistent behavior.
---
include/proto/stream.h | 3 +++
src/http_ana.c | 1 -
src/stream.c | 19 +++
3 files changed, 22 insertions(+), 1 deleti
I've adjusted commit message.
ср, 26 февр. 2020 г. в 12:40, Илья Шипицин :
> it's pretty much like to gcc.
> I've no idea why does FreeBSD decided to check its version (and nobody
> knows).
>
> I'll update commit message
>
> ср, 26 февр. 2020 г. в 05:37, Tim Düsterhus :
>
>> Ilya,
>>
>> Am 25.02.
On Wed, Feb 26, 2020 at 12:25:52PM +0100, Tim Düsterhus wrote:
> Thank you. When I try this within `conn_si_send_proxy`it works as expected.
>
> I have a question about the '} else if (!cs && conn->owner) {' case,
> though. It was added within this commit:
> https://github.com/haproxy/haproxy/comm
On Wed, Feb 26, 2020 at 11:15:00AM +0100, Emmanuel Hocdet wrote:
> Hi,
>
> > Le 18 févr. 2020 à 17:49, Emmanuel Hocdet a écrit :
> >>
> >> Yes. Show the chain-filename would be very helpful.
> >> For that i think a good way would be to keep ckch->chain and ckch->issuer
> >> with value (or NULL)
Willy,
Am 26.02.20 um 09:59 schrieb Willy Tarreau:
>>> However in many cases you could know the stream that requested the
>>> outgoing connection. That's what is used when you see that "remote"
>>> thing. In conn_si_send_proxy(), there's a test to see if the the
>>> first connection's conn_stream'
Hi,Le 18 févr. 2020 à 17:49, Emmanuel Hocdet a écrit :Yes. Show the chain-filename would be very helpful.For that i think a good way would be to keep ckch->chain and ckch->issuerwith value (or NULL) from PEM/, and resolve chain and ocsp_issuerwhen needed. « show ssl cert » will be
On Tue, Feb 25, 2020 at 12:26:41PM +0100, Tim Düsterhus wrote:
> > You will not get back to a stream based on a connection because there
> > may be many streams per connection. A connection will lead you to a
> > mux (H1,H2,FCGI) and from there depending on the mux's protocol and
> > internals you'
14 matches
Mail list logo