Re: Haproxy running on ipv6 and http-in/
Hi Christoph,
Christoph Kukulies wrote on 2023-12-01 09:59:
>> Seems normal, status code is 301 and you have "redirect scheme https code
>> 301 if !{ ssl_fc }"
>> Is this what you expect or do you think there're some errors ?
>
> But the http-in/is bugging me.
This tells you that the request was accepted by and handled in the
http-in frontend without being forwarded to any backend
server.
This is expected since the request was answered by HAProxy
itself with the 301 redirect. The LR-- termination state in the log line
confirms this. To quote the documentation:
> LR The request was intercepted and locally handled by HAProxy. Generally
> it means that this was a redirect or a stats request.
All the best,
Holger
--
Holger JUST (he/him)
[PR] BUG/MEDIUM: server-state: update server if the ports in config and state match
Dear list! Author: Steven Lu Number of patches: 1 This is an automated relay of the Github pull request: BUG/MEDIUM: server-state: update server if the ports in config and state match Patch title(s): BUG/MEDIUM: server-state: Only update server if the ports in config and state still match Link: https://github.com/haproxy/haproxy/pull/2370 Edit locally: wget https://github.com/haproxy/haproxy/pull/2370.patch && vi 2370.patch Apply locally: curl https://github.com/haproxy/haproxy/pull/2370.patch | git am - Description: BUG/MEDIUM: server-state: update server if the ports in config and state match When `load-server-state-from-file` is enabled, and change the backend port or check port in the config file (without altering the backend name and server name), restarting haproxy will not apply the port number changes from the new config file. This will result in users being unable to connect to the backend using the new port. The reason is that haproxy only uses the backend name and server name to decide whether to use state information. To fix the issue, we can only update the server info if the ports in the config and the state still match. This patch should solve the issue #2103. 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: Haproxy running on ipv6 and http-in/
Thanks, Jarno, for sorting this out. Running on ipv6 is probably obvious due to
the bind :::80 and bind :::443 statements.
This v4v6 extension I got from somewhere and is supposed to be Linux kernel
specific.
> Am 01.12.2023 um 07:56 schrieb Jarno Huuskonen :
>
> Hi,
>
> On Tue, 2023-11-28 at 16:29 +0100, Christoph Kukulies wrote:
>> I'm wondering why I see haproxy running on ipv6 (Ubuntu 22.04):
>>
>> Excerpt from haproxy.cfg:
>>
>> frontend http-in
>> #bind *:80
>> bind :::80 v4v6
>> #bind *:443 ssl crt /etc/haproxy/certs/xx.pem
>> bind :::443 v4v6 ssl crt /etc/haproxy/certs/xx.pem
>> bind quic4@0.0.0.0:443 name quic443 ssl crt
>> /etc/haproxy/certs/xxx.pem proto quic alpn h3,h3-29,h3-28,h3-27 npn
>> h3,h3-29,h3-28,h3-27 allow-0rtt curves secp521r1:secp384r1
>> http-response add-header alt-svc 'h3=":443"; ma=7200,h3-29=":443";
>> ma=7200,h3-Q050=":443"; ma=7200,h3-Q046=":443"; ma=7200,h3-
>> Q043=":443"; ma=7200,quic=":443"; ma=7200'
>>
>> http-request return status 200 content-type text/plain lf-string
>> "%[path,field(-1,/)].${ACCOUNT_THUMBPRINT}\n" if { path_beg '/.well-
>> known/acme-challenge/' }
>>
>
> This and "use_backend letsencrypt-backend if letsencrypt-acl" seem like
> duplicate and only one of them is used ?
>
>> # Redirect if HTTPS is *not* used
>> redirect scheme https code 301 if !{ ssl_fc }
>> acl letsencrypt-acl path_beg /.well-known/acme-challenge/
>>
>> use_backend letsencrypt-backend if letsencrypt-acl
>> default_backend website
>>
>> In my haproxy.log I see:
>>
>> Nov 28 16:10:19 mail haproxy[59727]: :::88.181.85.41:63772
>> [28/Nov/2023:16:10:19.728] http-in http-in/ 0/-1/-1/-1/0 301 97 - -
>> LR-- 1/1/0/0/0 0/0 "GET / HTTP/1.1"
>>
>> This stems from a request I did that way:
>>
>> curl http://www.kukulies.org
Re: [PATCH 3/3] DOC: Clarify the differences between field() and word()
Hi Tim, On Thu, Nov 30, 2023 at 04:41:18PM +0100, Tim Duesterhus wrote: > word() mentions that delimiters at the start and end are ignored, but it does > not mention that consecutive delimiters are merged. (...) Series just merged as well, I didn't notice it while I was typing the announce message yesterday ;-) Thanks, Willy
