[PR] add a vhost setting per backend

[PR Bot]

Dear list!

Author: romain.d.morotti 
Number of patches: 4

This is an automated relay of the Github pull request:
   add a vhost setting  per backend

Patch title(s): 
   add vhost setting per backend. it sets the host header in requests, in 
healthchecks and in TLS connections (SNI).
   add unit test on vhost.
   add documentation on vhost setting.
   use spaces for alignment. not tabs.

Link:
   https://github.com/haproxy/haproxy/pull/167

Edit locally:
   wget https://github.com/haproxy/haproxy/pull/167.patch && vi 167.patch

Apply locally:
   curl https://github.com/haproxy/haproxy/pull/167.patch | git am -

Description:
   Add a vhost setting per backend. It sets the host header for the
   backend in http requests, http healthchecks and TLS connections.
   This is required to support services using the host header for routing
   (kube ingress, ALB, other load balancer...).

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] BUG/MINOR: mux-h1: Correctly report Ti timer when HTX and keepalives are used

[Christopher Faulet]

Le 12/07/2019 à 16:20, Christopher Faulet a écrit :

Le 12/07/2019 à 15:56, David Pirotte a écrit :

Sure thing, Christopher. Patch is attached. Thanks!


Thanks ! merged now.


Sorry, forgot to mention. I slightly amended you patch to also set t_handshake 
to 0 to have the right Th time.


--
Christopher Faulet

Re: [PATCH] BUG/MINOR: mux-h1: Correctly report Ti timer when HTX and keepalives are used

[Christopher Faulet]

Le 12/07/2019 à 15:56, David Pirotte a écrit :

Sure thing, Christopher. Patch is attached. Thanks!


Thanks ! merged now.

--
Christopher Faulet

Re: [PATCH] BUG/MINOR: mux-h1: Correctly report Ti timer when HTX and keepalives are used

[David Pirotte]

Sure thing, Christopher. Patch is attached. Thanks!

Cheers,
Dave

On Fri, Jul 12, 2019 at 5:00 AM Christopher Faulet 
wrote:

> Le 10/07/2019 à 17:58, David Pirotte a écrit :
> > Instructions to reproduce are below.
> >
> > When HTTP keepalives are used in conjunction with HTX, the Ti timer
> reports the
> > elapsed time since the beginning of the connection instead of the end of
> the
> > previous request as stated in the documentation. Tq and Tt also report
> > incorrectly as a result.
> >
> > So, when creating a new h1s, check if it is the first request on
> the connection.
> > If not, set the session create times to the current timestamp rather
> than the
> > initial session accept timestamp. This makes the logged timers behave as
> stated
> > in the documentation.
> >
> > I hope this is useful, and feedback is welcome if there is a more
> correct
> > strategy. Thanks!
> >
> Hi Dave,
>
> Thanks ! Of course it is useful. However, your patch was mangled by your
> mailer.
> Could you please resend it as an attachment or using the command "git
> send-email" ?
>
> --
> Christopher Faulet
>


0001-BUG-MINOR-mux-h1-Correctly-report-Ti-timer-when-HTX-.patch
Description: Binary data

Re: Case Sensitive Headers

[Luke Seelenbinder]

Hi Christopher,

That definitely is ugly—but it works. Thanks! I'll look for improvements in 2.1.

Best,
Luke
—
Luke Seelenbinder
SermonAudio.com  | Senior Software Engineer

> On Jul 10, 2019, at 14:53, Christopher Faulet  wrote:
> 
> Le 10/07/2019 à 13:08, Luke Seelenbinder a écrit :
>> Hi Patrick,
>> 
>> That didn't work (in a few different forms I tried)—thanks for the 
>> suggestion 
>> though!
>> 
>> It seems HTX is pretty picky about how those headers get emitted. :)
>> 
>> I'm still looking for a solution to this that doesn't involve disabling HTX.
>> 
> 
> Hi Luke,
> 
> It is pretty ugly but you may hide the full "Content-Length" header in the 
> value of
> another one, for instance:
> 
>http-response set-header x-custom-cl "1\r\nContent-Length: 
> %[res.fhdr(content-length)]" if { res.fhdr(content-length) -m found }
>http-response del-header content-length
> 
> As said, it is ugly. But it does the trick for now. I will probably try to 
> work
> on a solution for the 2.1. Even more so the legacy HTTP will be removed for
> this release.
> 
> -- 
> Christopher Faulet
> 

Re: Upgrade from 1.7 to 2.0 = increased CPU usage

[Elias Abacioglu]

Ok, thanks, I'll wait for 2.0.2 then.

On Thu, Jul 11, 2019 at 7:57 PM Lukas Tribus  wrote:

> Hello Elias,
>
> On Thu, 11 Jul 2019 at 17:05, Elias Abacioglu
>  wrote:
> >
> > I just reverted back to haproxy 1.7 now.
> > To be more accurate, CPU idle is around ~48% for core 2-3.
>
> I suggest to wait for 2.0.2 or pull the current 2.0 git tree.
>
> 2.0.1 just contains too many bugs at this point.
>
>
> Lukas
>

Re: [PATCH] BUG/MINOR: mux-h1: Correctly report Ti timer when HTX and keepalives are used

[Christopher Faulet]

Le 10/07/2019 à 17:58, David Pirotte a écrit :

Instructions to reproduce are below.

When HTTP keepalives are used in conjunction with HTX, the Ti timer reports the 
elapsed time since the beginning of the connection instead of the end of the 
previous request as stated in the documentation. Tq and Tt also report 
incorrectly as a result.


So, when creating a new h1s, check if it is the first request on the connection. 
If not, set the session create times to the current timestamp rather than the 
initial session accept timestamp. This makes the logged timers behave as stated 
in the documentation.


I hope this is useful, and feedback is welcome if there is a more correct 
strategy. Thanks!



Hi Dave,

Thanks ! Of course it is useful. However, your patch was mangled by your mailer. 
Could you please resend it as an attachment or using the command "git send-email" ?


--
Christopher Faulet

Re: Runaway process

[Sander Klein]

On 2019-07-12 04:27, Willy Tarreau wrote:


If you can at least show the backtrace, this could be useful and we
can see if the core would be needed or not. Maybe this will match
another known bug.


This is the BT of yesterday:

---
GNU gdb (Debian 7.12-6) 7.12.0.20161007-git
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 


This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show 
copying"

and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word".
Attaching to process 27066
[New LWP 27067]
[New LWP 27068]
[New LWP 27069]
[Thread debugging using libthread_db enabled]
Using host libthread_db library 
"/lib/x86_64-linux-gnu/libthread_db.so.1".
0x7f08655ef303 in epoll_wait () at 
../sysdeps/unix/syscall-template.S:84

84  ../sysdeps/unix/syscall-template.S: No such file or directory.
(gdb) thread apply all bt

Thread 4 (Thread 0x7f084d058700 (LWP 27069)):
#0  0x7f08655ef303 in epoll_wait () at 
../sysdeps/unix/syscall-template.S:84

#1  0x562cea640f95 in ?? ()
#2  0x562cea6e6792 in ?? ()
#3  0x7f08c4a4 in start_thread (arg=0x7f084d058700) at 
pthread_create.c:456
#4  0x7f08655eed0f in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:97


Thread 3 (Thread 0x7f084d859700 (LWP 27068)):
#0  0x562cea6af336 in ?? ()
#1  0x562cea73cd1d in si_cs_send ()
#2  0x562cea73d90a in si_update_both ()
#3  0x562cea6a1976 in process_stream ()
#4  0x562cea770728 in process_runnable_tasks ()
#5  0x562cea6e67c1 in ?? ()
#6  0x7f08c4a4 in start_thread (arg=0x7f084d859700) at 
pthread_create.c:456
#7  0x7f08655eed0f in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:97


Thread 2 (Thread 0x7f084e05a700 (LWP 27067)):
#0  0x7f08655ef303 in epoll_wait () at 
../sysdeps/unix/syscall-template.S:84

#1  0x562cea640f95 in ?? ()
#2  0x562cea6e6792 in ?? ()
#3  0x7f08c4a4 in start_thread (arg=0x7f084e05a700) at 
pthread_create.c:456
#4  0x7f08655eed0f in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:97


Thread 1 (Thread 0x7f0866e5c180 (LWP 27066)):
#0  0x7f08655ef303 in epoll_wait () at 
../sysdeps/unix/syscall-template.S:84

#1  0x562cea640f95 in ?? ()
#2  0x562cea6e6792 in ?? ()
#3  0x562cea63e96c in main ()
---

And today I had another one:

---
GNU gdb (Debian 7.12-6) 7.12.0.20161007-git
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 


This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show 
copying"

and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word".
Attaching to process 6982
[New LWP 6983]
[New LWP 6984]
[New LWP 6985]
[Thread debugging using libthread_db enabled]
Using host libthread_db library 
"/lib/x86_64-linux-gnu/libthread_db.so.1".
0x7fbdf0713303 in epoll_wait () at 
../sysdeps/unix/syscall-template.S:84

84  ../sysdeps/unix/syscall-template.S: No such file or directory.
(gdb) thread apply all bt

Thread 4 (Thread 0x7fbdd817c700 (LWP 6985)):
#0  0x5606dd570457 in ?? ()
#1  0x5606dd5fdd1d in si_cs_send ()
#2  0x5606dd5ff45d in si_cs_io_cb ()
#3  0x5606dd6319a6 in process_runnable_tasks ()
#4  0x5606dd5a77c1 in ?? ()
#5  0x7fbdf17904a4 in start_thread (arg=0x7fbdd817c700) at 
pthread_create.c:456
#6  0x7fbdf0712d0f in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:97


Thread 3 (Thread 0x7fbdd897d700 (LWP 6984)):
#0  0x7fbdf0713303 in epoll_wait () at 
../sysdeps/unix/syscall-template.S:84

#1  0x5606dd501f95 in ?? ()
#2  0x5606dd5a7792 in ?? ()
#3  0x7fbdf17904a4 in start_thread (arg=0x7fbdd897d700) at 
pthread_create.c:456
#4  0x7fbdf0712d0f in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:97


Thread 2 (Thread 0x7fbdd917e700 (LWP 6983)):
#0  0x7fbdf0713303 in epoll_wait () at 
../sysdeps/unix/syscall-template.S:84

#1  0x5606dd501f95 in ?? ()
#2  0x5606dd5a7792 in ?? ()
#3  0x7fbdf17904a4 in start_thread (arg=0x7fbdd917e700) at 
pthread_create.c:456
#4  0x7fbdf0712d0f in clone () at