Re: Hey! I want to partner with you.

[Nova Meyer]

Hey,



Hope you're having an amazing week!

I'm going to assume you're not interested in collaborating with us but
still, I wanted to see what you thought of my suggestion to move things
along.

Let me know if things change.



All the Best,

Nova


-Original Message-

Hello,



Making sure my last message reached your inbox. I know gmail can get pretty
chaotic and things get lost all the time, so I was wondering how I can get
back on your radar.

To reiterate it, I work for Geonode  , the leading
unmetered residential proxy services for developers and I noticed that you
have content that touch base our site's focus.

With that, I am following up for your response if you could feature our
site in your site.

I will wait for your response and I am looking forwards to our
collaboration.



Thanks,

Nova


-Original Message-

Hey Team,

I'm Nova from Geonode  . We're the leading unmetered
residential proxy services for developers.

I've been looking for content related to *Residential Proxies *and I
noticed that on your site, you write and link to a lot of content relevant
to it, just like this  https://www.haproxy.org, and it caught my eye.

The reason I wanted to reach out is because I think there might be some
mutually beneficial collaboration opportunities.

If you are open to linking to our site, we would be happy to collaborate
with you.

I thought your readers might find it as a useful resource and it would make
a nice addition to your page.

Let me know what you think about it.

Thank you and keep up the great work at  haproxy.org!



All the best,

N

Re: Proposal about new default SSL log format

[Willy Tarreau]

On Thu, Jul 08, 2021 at 02:18:32PM +0200, William Lallemand wrote:
> I saw that you hesitated between "conn_status" and "conn_err_code", the
> "conn_" prefix could be confusing at some point once you try to have
> errors on the frontend and the backend side in the same log-format, I
> think something starting by "fc_conn_" would be more understandable.

Indeed, and more consistent with what we already have. fc_* is for the
front connection, bc_* is for the back connection. By the way if we're
focusing on SSL it should even be ssl_fc_* (we already have a ton of
them, nobody will find the new one if it doesn't use the same prefix).

> That seems good to me, we only need frontend info IMHO. People who need
> the SSL backend connection are not the most common case so they could
> make their own log-format with it.

I tend to think that if we're focusing on https vs http, it makes sense
to consider the frontend only as well for the standard logs.

Also some background on the log format, originally we used to place the
URI at the end of the line because most loggers used to truncate logs
at 1024 bytes and the tail of the URI was far less important than other
fields. This explains why we've started to insert certain fields at
certain places before this. 20 years later I think it is perfectly
reasonable to consider appending fields *after* the URI, which is also
a great way of applying minimal changes to existing log parsers, and
to allow http/https log lines to be easily compared when aligned.

Willy

Re: ratio spam/useful message

[Julien Pivotto]

On 08 Jul 05:40, Willy Tarreau wrote:
> Hi Julien,
> 
> On Tue, Jul 06, 2021 at 11:06:05AM +0200, Julien Pivotto wrote:
> > Hello,
> > 
> > Lately, the ratio spam/useful message on the ML has been quite high.
> 
> Well, that's not what I'm seeing in the archives here:
> 
>https://www.mail-archive.com/haproxy@formilux.org/
> 
> I had to manually delete 9 messages this month and 29 last month from
> my mbox, or 1 per day, I don't find it high at all, quite the opposite!

Hello Willy,

Yes, that is what I have too. I guess we simply don't have the same
standards - to me one spam a day is 'high'.

> I've added the recurrent "NFP workshops" ones and the occasional
> "sock-raw.org" to the block list, but I'm not seeing that much come in.
> Are you getting more from the list ? Am I the only one getting so few ?
> Even checking the local archives here didn't reveal anything exceptional.

Nope, it is just that I am not used to receive a spam a day on the other
mailing lists I follow.

> 
> Willy
> 

Regards,

-- 
 (o-Julien Pivotto
 //\Open-Source Consultant
 V_/_   Inuits - https://www.inuits.eu


signature.asc
Description: PGP signature

Re: Proposal about new default SSL log format

[William Lallemand]

On Thu, Jul 08, 2021 at 02:48:32PM +0200, Willy Tarreau wrote:
> On Thu, Jul 08, 2021 at 02:18:32PM +0200, William Lallemand wrote:
> > I saw that you hesitated between "conn_status" and "conn_err_code", the
> > "conn_" prefix could be confusing at some point once you try to have
> > errors on the frontend and the backend side in the same log-format, I
> > think something starting by "fc_conn_" would be more understandable.
> 
> Indeed, and more consistent with what we already have. fc_* is for the
> front connection, bc_* is for the back connection. By the way if we're
> focusing on SSL it should even be ssl_fc_* (we already have a ton of
> them, nobody will find the new one if it doesn't use the same prefix).
>

That's what Rémi implemented for the SSL fetches, but the connection
error one is more generic and does not focus on SSL at all.

> > That seems good to me, we only need frontend info IMHO. People who need
> > the SSL backend connection are not the most common case so they could
> > make their own log-format with it.
> 
> I tend to think that if we're focusing on https vs http, it makes sense
> to consider the frontend only as well for the standard logs.
>

I agree.

> Also some background on the log format, originally we used to place the
> URI at the end of the line because most loggers used to truncate logs
> at 1024 bytes and the tail of the URI was far less important than other
> fields. This explains why we've started to insert certain fields at
> certain places before this. 20 years later I think it is perfectly
> reasonable to consider appending fields *after* the URI, which is also
> a great way of applying minimal changes to existing log parsers, and
> to allow http/https log lines to be easily compared when aligned.
> 

I agree, this way it's easily readable without having to realign
mentally the fields in common between an http line and an https one.


-- 
William Lallemand

Re: Proposal about new default SSL log format

[William Lallemand]

Hello,

On Wed, Jul 07, 2021 at 04:43:53PM +0200, Remi Tricot-Le Breton wrote:
> I was indeed more focused on logging SSL related information only, with 
> the idea that an SSL log line could be displayed after a completed 
> handshake, hence the lack of upper layer information in the log line. 
> But it would indeed bring a new level of complexity in the log because 
> correlating the SSL and HTTP log lines of a specific session might be a 
> pain. After talking with Willy, an https log was deemed more useful. It 
> would only be an extension of the existing HTTP log with SSL specific 
> information added. This log format would concern every log line raised 
> by the frontends using this log format (one line per HTTP response of 
> the SSL session).

Yes, what would be great is a "option httpslog" which would provide a
default log line for HTTP over SSL.

> A quick recap of the topics raised by the multiple conversations had in 
> this thread :
> - we won't used tabs as separators in order to remain consistent with 
> the existing log format (especially since this new format will only be 
> an extension of the HTTP one)

I agree, using tab doesn't not seems to be something we would want, it's
the same problem with people that would want json in their log, they
need a new format, not the default one.

> - the date format won't change right now, it is a whole new subject
> - the logged lines will all have the same "date+process_name+pid" prefix 
> as the already existing logs
> - the HTTP log format won't be touched yet, changing it would be a whole 
> new subject as well

Agreed.

> 
> 
> The log would then be as follows :
> 
> 
>      >>> Jul  1 18:11:31 haproxy[143338]: 127.0.0.1:37740 
> [01/Jul/2021:18:11:31.517] \
>    ssl_frontend~ ssl_frontend/s2 0/0/0/7/+7 200 2750 - -  \
>    1/1/1/1/0 0/0 {1wt.eu} {} "GET /index.html HTTP/1.1 \
>    0/0/0/0 TLSv1.3/TLS_AES_256_GCM_SHA384
> 
>    Field   Format    Extract from the 
> example above
>    1   process_name '[' pid ']:' haproxy[143338]:
>    2   client_ip ':' client_port 127.0.0.1:37740
>    3   '[' request_date ']' [01/Jul/2021:18:11:31.517]
>    4   frontend_name ssl_frontend~
>    5   backend_name '/' server_name ssl_frontend/s2
>    6   TR '/' Tw '/' Tc '/' Tr '/' Ta*   
> 0/0/0/7/+7
>    7 status_code 200
>    8 bytes_read* 2750
>    9 captured_request_cookie -
>   10 captured_response_cookie -
>   11 termination_state 
>   12   actconn '/' feconn '/' beconn '/' srv_conn '/' retries*    
> 1/1/1/1/0
>   13   srv_queue '/' 
> backend_queue  0/0
>   14   '{' captured_request_headers* '}' {haproxy.1wt.eu}
>   15   '{' captured_response_headers* 
> '}'    {}
>   16   '"' http_request '"'  "GET /index.html 
> HTTP/1.1"
>   17 *conn_status '/' SSL fe hsk error '/' SSL vfy '/' SSL CA vfy*  
> 0/0/0/0
>   18 *ssl_version '/' ssl_ciphers* TLSv1.3/TLS_AES_256_GCM_SHA384
> 
> and the corresponding log-format :
> 
>      %ci:%cp [%tr] %ft %b/%s %TR/%Tw/%Tc/%Tr/%Ta %ST %B %CC \
>      %CS %tsc %ac/%fc/%bc/%sc/%rc %sq/%bq %hr %hs %{+Q}r \
> *%[conn_err_code]/%[ssl_fc_hsk_err]/%[ssl_c_err]/%[ssl_c_ca_err]* \
> *%sslv/%sslc*
> 

I saw that you hesitated between "conn_status" and "conn_err_code", the
"conn_" prefix could be confusing at some point once you try to have
errors on the frontend and the backend side in the same log-format, I
think something starting by "fc_conn_" would be more understandable.

That seems good to me, we only need frontend info IMHO. People who need
the SSL backend connection are not the most common case so they could
make their own log-format with it.


-- 
William Lallemand

[ANNOUNCE] haproxy-2.3.12

[Willy Tarreau]

Hi,

HAProxy 2.3.12 was released on 2021/07/08. It added 2 new commits
after version 2.3.11.

Please do not use 2.3.11! I failed the backport of the use-after-free bug
fix in the lockless pools between 2.4 and 2.3. The pools code in 2.4 was
significantly reworked to be cleaner and simpler, and I found two
occurrences in 2.3 and older that required the same fix and that were
missing it. The result can be a runtime deadlock depending on the build
options, the operating system and the load (the watchdog will catch it,
but nobody wants to deploy this, obviously).

After scrutinizing the code all the afternoon and torturing it under
different build options, I can now affirm that the code is properly fixed
in 2.3.12.

These patches were backported into 2.2 as well because the faulty patch was
already there. For 2.0 and below the patch was fixed to limit the risks of
incomplete backports (namely for those who continue to cherry-pick selected
fixes).

I'm seeing that at least Vincent was fast enough to package 2.3.11 for
debian 10, I hope nobody deployed it yet. I'm really sorry for the mess.
For those who are wondering, 2.4 was not affected.

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.3/src/
   Git repository   : http://git.haproxy.org/git/haproxy-2.3.git/
   Git Web browsing : http://git.haproxy.org/?p=haproxy-2.3.git
   Changelog: http://www.haproxy.org/download/2.3/src/CHANGELOG
   Cyril's HTML doc : http://cbonte.github.io/haproxy-dconv/

Willy
---
Complete changelog :
Willy Tarreau (2):
  BUG/MAJOR: pools: fix incomplete backport of lockless pool fix
  BUG/MAJOR: pools: second fix for incomplete backport of lockless pool fix

---

Long broken option http_proxy: should we kill it ?

[Willy Tarreau]

Hi all,

Amaury discovered that "option http_proxy" was broken. I quickly checked
when it started, and it got broken with the introduction of HTX in 1.9
three years ago. It still used to work in legacy mode in 1.9 and 2.0
but 2.0 uses HTX by default and legacy disappeared from 2.1. Thus to
summarize it, no single version emitted during the last 2.5 years saw it
working.

As such I was considering removing it from 2.5 without prior deprecation.
My opinion is that something that doesn't work for 2.5 years and that
triggers no single report is a sufficient indicator of non-use. We'll
still need to deploy reasonable efforts to see under what conditions it
can be fixed and the fix backported, of course. Does anyone object to
this ?

For a bit of background, this option was added 14 years ago to extract
an IP address an a port from an absolute URI, rewrite it to relative
and forward the request to the original IP:port, thus acting like a
non-resolving proxy. Nowadays one could probably achieve the same
by doing something such asthe following:

http-request set-dst url_ip
http-request set-dst-port url_port
http-request set-uri %[path]

And it could even involve the do_resolve() action to resolve names to
addresses. That's why I'm in favor of not even trying to keep this one
further.

Thanks,
Willy

Re: Long broken option http_proxy: should we kill it ?

[Aleksandar Lazic]

On 08.07.21 18:33, Willy Tarreau wrote:

Hi all,

Amaury discovered that "option http_proxy" was broken. I quickly checked
when it started, and it got broken with the introduction of HTX in 1.9
three years ago. It still used to work in legacy mode in 1.9 and 2.0
but 2.0 uses HTX by default and legacy disappeared from 2.1. Thus to
summarize it, no single version emitted during the last 2.5 years saw it
working.

As such I was considering removing it from 2.5 without prior deprecation.
My opinion is that something that doesn't work for 2.5 years and that
triggers no single report is a sufficient indicator of non-use. We'll
still need to deploy reasonable efforts to see under what conditions it
can be fixed and the fix backported, of course. Does anyone object to
this ?

For a bit of background, this option was added 14 years ago to extract
an IP address an a port from an absolute URI, rewrite it to relative
and forward the request to the original IP:port, thus acting like a
non-resolving proxy. Nowadays one could probably achieve the same
by doing something such asthe following:

 http-request set-dst url_ip
 http-request set-dst-port url_port
 http-request set-uri %[path]

And it could even involve the do_resolve() action to resolve names to
addresses. That's why I'm in favor of not even trying to keep this one
further.


+1 to remove


Thanks,
Willy

Re: [ANNOUNCE] haproxy-2.3.12

[Vincent Bernat]

 ❦  8 July 2021 17:47 +02, Willy Tarreau:

> I'm seeing that at least Vincent was fast enough to package 2.3.11 for
> debian 10, I hope nobody deployed it yet. I'm really sorry for the mess.
> For those who are wondering, 2.4 was not affected.

The new packages are available!
-- 
Let the data structure the program.
- The Elements of Programming Style (Kernighan & Plauger)

Re: [ANNOUNCE] haproxy-2.3.12

[Willy Tarreau]

On Thu, Jul 08, 2021 at 07:11:27PM +0200, Vincent Bernat wrote:
>  ?  8 July 2021 17:47 +02, Willy Tarreau:
> 
> > I'm seeing that at least Vincent was fast enough to package 2.3.11 for
> > debian 10, I hope nobody deployed it yet. I'm really sorry for the mess.
> > For those who are wondering, 2.4 was not affected.
> 
> The new packages are available!

Excellent, many thanks Vincent for always being so reactive!

Willy