Re: Syslog with systemd
❦ 2 mars 2018 09:49 +1100, Igor Cicimov : > $ ls -l /var/log/haproxy.log > -rw-r- 1 syslog adm 48939 Mar 1 20:17 /var/log/haproxy.log > > and I'm sure this file was automatically created (by rsyslog I guess?). > I'm sure this has always been the case hence the reason I was confused when > I had to create it manually (obviously with wrong permissiosn :-/ ). > > So the question is now why this file did not get created in the first place > although I restarted rsyslog and haproxy several times? I suppose the permissions of /var/log are incorrect. It should be owned by syslog? -- Format a program to help the reader understand it. - The Elements of Programming Style (Kernighan & Plauger)
Re: What is a nice way to bypass the maintenance mode for certain IP's?
Hi Cyril, On Thu, Mar 01, 2018 at 08:50:55PM +0100, Cyril Bonté wrote: > Well, I think your issue will be resolved by moving "force-persist" on the > backend side instead of the frontend one. > > The issue seems to exist from the first day of "force-persist", where the > code and the documentation don't agree about the sections where it can be > used. > > From the documentation and the config parser, it can be used in a frontend, > but the code only loop on the s->be to evaluate the > persistence options. I think you are totally right. At first this caught my eye, but I looked at the doc, and found that it was apparently supported in the frontend, which surprised me. Then a quick look at the code told me that we were setting SF_FORCE_PRST regardless of the frontend or backend. But after your comment I looked closer and noticed that the place where it's done is when processing the content switching rules, so by definition it can only be done on the backend. > > See commit > http://git.haproxy.org/?p=haproxy.git;a=commit;h=4de9149f876cc0c63495b71a2c7a3aefc722c9c0 > for details. > > The same issue was also introduced with "ignore-persist". You're right, both are set in the same loop. Usually I prefer to adapt the code to make it match the doc, but here I don't see a reasonable way to do it, so I think we'll instead update the code to emit a warning and update the doc. Any objection ? Thanks, Willy
Re: TLS termination with 2 certs on same IP
Hello Dave, On 2 March 2018 at 01:09, Dave Cottlehuber wrote: > I have 2 TLS cert bundles that I'd like to serve off haproxy, using a single > IP. Both certs have multiple SANs in them. > > - our main production site: api,beta,www.example.com using EV cert > - a lets-encrypt cert bundle for old DNS names that we only need to redirect > https: back to the main site > > I've followed > https://www.haproxy.com/blog/enhanced-ssl-load-balancing-with-server-name-indication-sni-tls-extension/ > and updated it a bit. Does this look sensible? is there a simpler way to do > this? Yes. You don't need TCP mode and manual SNI matching at all. Haproxy will do all those things for your automatically. The article is specifically about content switching TCP payload based on SNI, but that's not you usecase (not of you want a simple and build-in solution). The point is: you can specify multiple certificate or even directories with the "crt" keyword. frontend all bind :80 bind [::1]:443 ssl crt /usr/local/etc/ssl/keys/example.com.pem crt /usr/local/etc/ssl/keys/letsencrypt.example.com.pem # redirect letsencrypt requests acl url_acme path_beg /.well-known/acme-challenge/ use_backend acme_backend ifurl_acme # redirect traffic to beta or prod jail as required acl iwmn_prod hdr(host) example.com api.example.com acl iwmn_beta hdr(host) beta.example.com # redirect main site urls acl valid_host hdr(host) example.com api.example.com beta.example.com http-request redirect code 301 location https://example.com%[capture.req.uri] unless valid_host use_backend prod_backend if iwmn_prod default_backend imsorry_backend # ... backends cheers, lukas
Re: Syslog with systemd
On 2/27/2018 10:28 PM, Igor Cicimov wrote: Hi all, I have haproxy 1.7.10-1ppa1~xenial installed on Ubuntu-16.04 and struggling to enable rsyslog-ing for the service. I have rsyslog running and the following haproxy related config: # cat /etc/rsyslog.d/49-haproxy.conf # Create an additional socket in haproxy's chroot in order to allow logging via # /dev/log to chroot'ed HAProxy processes $AddUnixListenSocket /var/lib/haproxy/dev/log # Send HAProxy messages to a dedicated logfile if $programname startswith 'haproxy' then /var/log/haproxy.log &~ Haproxy is started with: global log /dev/log local0 log /dev/log local1 debug maxconn 4096 debug chroot /var/lib/haproxy stats socket /run/haproxy/admin.sock mode 660 level admin stats timeout 30s user haproxy group haproxy daemon same as I had for Ubuntu-14.04. What am I doing wrong? Thanks, Igor * What do you get for ls -l /var/log/haproxy.log on each box? * What do you get for ls -l /var/lib/haproxy/dev/log on each box? * Were both of these boxes upgraded in-place from 14.04 or fresh installations of 16.04? * Are you using the version of rsyslog that comes with Ubuntu 16.04 or the latest upstream package? http://www.rsyslog.com/ubuntu-repository/
TLS termination with 2 certs on same IP
I have 2 TLS cert bundles that I'd like to serve off haproxy, using a single
IP. Both certs have multiple SANs in them.
- our main production site: api,beta,www.example.com using EV cert
- a lets-encrypt cert bundle for old DNS names that we only need to redirect
https: back to the main site
I've followed
https://www.haproxy.com/blog/enhanced-ssl-load-balancing-with-server-name-indication-sni-tls-extension/
and updated it a bit. Does this look sensible? is there a simpler way to do
this?
#
frontend example_sniffer
bind1.2.3.4:443
bind[1:2:3::4]:443
modetcp
tcp-request inspect-delay 5s
tcp-request content accept if { req.ssl_hello_type 1 }
acl redirectreq.ssl_sni -i www.example.com.au blog.example.com
use_backend example_tls_forwarder if redirect
default_backend example_http_https_be
backend example_http_https_be
modetcp
server example_fe[::1]:10443
backend example_tls_forwarder
modetcp
server example_fe[::1]:10444
frontend example_http_https
bind[::1]:80
bind[::1]:10443 ssl crt
/usr/local/etc/ssl/keys/example.com.pem
bind[::1]:10444 ssl crt
/usr/local/etc/ssl/keys/letsencrypt.example.com.pem
# redirect letsencrypt requests
acl url_acme path_beg /.well-known/acme-challenge/
use_backend acme_backend ifurl_acme
# redirect traffic to beta or prod jail as required
acl iwmn_prod hdr(host) example.com api.example.com
acl iwmn_beta hdr(host) beta.example.com
# redirect main site urls
acl valid_hosthdr(host) example.com api.example.com
beta.example.com
http-requestredirect code 301 location
https://example.com%[capture.req.uri] unless valid_host
use_backend prod_backend if iwmn_prod
default_backend imsorry_backend
# ... backends
thanks
Dave
Re: Syslog with systemd
On Thu, Mar 1, 2018 at 5:08 PM, Vincent Bernat wrote:
> ❦ 1 mars 2018 09:53 +1100, Igor Cicimov > :
>
> >> > Same, no logging:
> >> [...]
> >>
> >> Could you strace rsyslogd and check if it is receiving the messages?
> >
> >
> > Sure:
> >
> > # pidof rsyslogd
> > 4145
> > # strace -p 4145
> > strace: Process 4145 attached
> > select(1, NULL, NULL, NULL, {469, 541106}) = 0 (Timeout)
> > select(1, NULL, NULL, NULL, {600, 0}
> >
> > and that's it, sitting like this for 15 minutes.
>
> Try with -ff
>
Good point:
[*pid 4150*] 09:32:20 open("/var/log/haproxy.log",
O_WRONLY|O_CREAT|O_NOCTTY|O_APPEND|O_CLOEXEC, 0640) = -1 EACCES (Permission
denied)
which means the syslog user does not have permissions to write to this
file, which is correct:
# ls -l /var/log/haproxy.log
-rw-r--r-- 1 haproxy haproxy 0 Feb 28 15:31 /var/log/haproxy.log
On the working server I can see:
$ ls -l /var/log/haproxy.log
-rw-r- 1 syslog adm 48939 Mar 1 20:17 /var/log/haproxy.log
and I'm sure this file was automatically created (by rsyslog I guess?).
I'm sure this has always been the case hence the reason I was confused when
I had to create it manually (obviously with wrong permissiosn :-/ ).
So the question is now why this file did not get created in the first place
although I restarted rsyslog and haproxy several times?
Re: What is a nice way to bypass the maintenance mode for certain IP's?
Hi Pieter and Willy,
Le 01/03/2018 à 16:09, Pieter Vogelaar a écrit :
Hi Willy,
Yes I'm absolutely certain that the cookie is present in the browser request
when I get the 503.
I changed the JSESSIONID line to "cookie SERVERID insert indirect nocache", but
that didn't make a difference.
Log line when both servers in backend are in maintenance mode:
172.30.214.130:56887 [01/Mar/2018:15:37:24.928] default-https~ pieter-tomcat-tst/
0/-1/-1/-1/0 503 3576 - - SCDN 1/0/0/0/0 0/0
{tst-pieter.example.org||nl-NL,nl;q=0.9,en-US;q=0.8,en;q=0.7||Mozilla/5.0 (Macintosh; Intel Mac
OS X 10_13_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.186 Safari/537.36} {|||}
"GET /hello-world/ HTTP/1.1"
Log line when both servers in backend are active:
172.30.214.130:56451 [01/Mar/2018:15:37:09.734] default-https~
pieter-tomcat-tst/pieter-tomcat-01t:8080 0/0/1/2/3 200 5243 - - --VN 2/1/0/0/0 0/0
{tst-pieter.example.org||nl-NL,nl;q=0.9,en-US;q=0.8,en;q=0.7||Mozilla/5.0 (Macintosh;
Intel Mac OS X 10_13_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.186
Safari/537.36} {text/html;charset=ISO-8859-1|||} "GET /hello-world/ HTTP/1.1"
Well, I think your issue will be resolved by moving "force-persist" on
the backend side instead of the frontend one.
The issue seems to exist from the first day of "force-persist", where
the code and the documentation don't agree about the sections where it
can be used.
From the documentation and the config parser, it can be used in a
frontend, but the code only loop on the s->be to evaluate the
persistence options.
See commit
http://git.haproxy.org/?p=haproxy.git;a=commit;h=4de9149f876cc0c63495b71a2c7a3aefc722c9c0
for details.
The same issue was also introduced with "ignore-persist".
Best regards,
Pieter Vogelaar
Op 01-03-18 15:32 heeft Willy Tarreau geschreven:
On Thu, Mar 01, 2018 at 02:29:57PM +, Pieter Vogelaar wrote:
> Hi Willy,
>
> We use Memcached Session Manager that stores the Tomcat sessions to a Couchbase
cluster. It suffixes the session ID with "-n1" like:
>
> JSESSIONID=s01~1C7985929CDF981D9ACC79EBD8A3293D-n1
>
> Could this JSESSIONID format somehow have impact on HAProxy?
No, that's fine, but my point is : are you certain it is present in your
browser's request when you get the 503 ? If the 3 char of the termination
flags in the logs indicates '-' or 'N', it means it's absent. Or if you
can run haproxy in debug mode (with -d), you will see all requests on the
screen and it will be easy to tell whether the cookie is there or not.
Willy
--
Cyril Bonté
Re: What is a nice way to bypass the maintenance mode for certain IP's?
Hi Willy,
Yes I'm absolutely certain that the cookie is present in the browser request
when I get the 503.
I changed the JSESSIONID line to "cookie SERVERID insert indirect nocache", but
that didn't make a difference.
Log line when both servers in backend are in maintenance mode:
172.30.214.130:56887 [01/Mar/2018:15:37:24.928] default-https~
pieter-tomcat-tst/ 0/-1/-1/-1/0 503 3576 - - SCDN 1/0/0/0/0 0/0
{tst-pieter.example.org||nl-NL,nl;q=0.9,en-US;q=0.8,en;q=0.7||Mozilla/5.0
(Macintosh; Intel Mac OS X 10_13_2) AppleWebKit/537.36 (KHTML, like Gecko)
Chrome/64.0.3282.186 Safari/537.36} {|||} "GET /hello-world/ HTTP/1.1"
Log line when both servers in backend are active:
172.30.214.130:56451 [01/Mar/2018:15:37:09.734] default-https~
pieter-tomcat-tst/pieter-tomcat-01t:8080 0/0/1/2/3 200 5243 - - --VN 2/1/0/0/0
0/0 {tst-pieter.example.org||nl-NL,nl;q=0.9,en-US;q=0.8,en;q=0.7||Mozilla/5.0
(Macintosh; Intel Mac OS X 10_13_2) AppleWebKit/537.36 (KHTML, like Gecko)
Chrome/64.0.3282.186 Safari/537.36} {text/html;charset=ISO-8859-1|||} "GET
/hello-world/ HTTP/1.1"
Best regards,
Pieter Vogelaar
Op 01-03-18 15:32 heeft Willy Tarreau geschreven:
On Thu, Mar 01, 2018 at 02:29:57PM +, Pieter Vogelaar wrote:
> Hi Willy,
>
> We use Memcached Session Manager that stores the Tomcat sessions to a
Couchbase cluster. It suffixes the session ID with "-n1" like:
>
> JSESSIONID=s01~1C7985929CDF981D9ACC79EBD8A3293D-n1
>
> Could this JSESSIONID format somehow have impact on HAProxy?
No, that's fine, but my point is : are you certain it is present in your
browser's request when you get the 503 ? If the 3 char of the termination
flags in the logs indicates '-' or 'N', it means it's absent. Or if you
can run haproxy in debug mode (with -d), you will see all requests on the
screen and it will be easy to tell whether the cookie is there or not.
Willy
Re: [PATCH v2 0/3] Add SystemD's sandboxing options
Hi guys, On Thu, Mar 01, 2018 at 03:53:25PM +0100, Tim Düsterhus wrote: > Pavlos, > > Am 27.02.2018 um 22:50 schrieb Pavlos Parissis: > > BTW: The commit message is a bit misleading because If I don't read the > > code I will > > think that those options are enabled, which isn't true. So, you may want to > > mention they aren't > > enabled by default. > > > I'm not sure how I could put that succinctly into the first line of the > message. They are already too long. > > While I'm a huge proponent of clear messages I think in this case it's > easy to see in the diff that they are examples. I'll leave it up to > Willy to adapt the commit messages, if he considers them unclear, > instead of me sending even more patches to all the list subscriber's > mailboxes :-) Well, let's not bikeshed on the contents of commit messages for patches that "only" contain extra documentation in config files in the end :-) I've just merged them now. Thanks! Willy
Re: [PATCH v2 0/3] Add SystemD's sandboxing options
Pavlos, Am 27.02.2018 um 22:50 schrieb Pavlos Parissis: > BTW: The commit message is a bit misleading because If I don't read the code > I will > think that those options are enabled, which isn't true. So, you may want to > mention they aren't > enabled by default. > I'm not sure how I could put that succinctly into the first line of the message. They are already too long. While I'm a huge proponent of clear messages I think in this case it's easy to see in the diff that they are examples. I'll leave it up to Willy to adapt the commit messages, if he considers them unclear, instead of me sending even more patches to all the list subscriber's mailboxes :-) Thanks. Tim Düsterhus
Re: What is a nice way to bypass the maintenance mode for certain IP's?
On Thu, Mar 01, 2018 at 02:29:57PM +, Pieter Vogelaar wrote: > Hi Willy, > > We use Memcached Session Manager that stores the Tomcat sessions to a > Couchbase cluster. It suffixes the session ID with "-n1" like: > > JSESSIONID=s01~1C7985929CDF981D9ACC79EBD8A3293D-n1 > > Could this JSESSIONID format somehow have impact on HAProxy? No, that's fine, but my point is : are you certain it is present in your browser's request when you get the 503 ? If the 3 char of the termination flags in the logs indicates '-' or 'N', it means it's absent. Or if you can run haproxy in debug mode (with -d), you will see all requests on the screen and it will be easy to tell whether the cookie is there or not. Willy
Re: What is a nice way to bypass the maintenance mode for certain IP's?
Hi Willy,
We use Memcached Session Manager that stores the Tomcat sessions to a Couchbase
cluster. It suffixes the session ID with "-n1" like:
JSESSIONID=s01~1C7985929CDF981D9ACC79EBD8A3293D-n1
Could this JSESSIONID format somehow have impact on HAProxy?
Best regards,
Pieter Vogelaar
Op 01-03-18 15:25 heeft Willy Tarreau geschreven:
Hi Pieter,
On Thu, Mar 01, 2018 at 01:16:36PM +, Pieter Vogelaar wrote:
> Hi Willy,
>
> I have the following (stripped down) configuration:
>
> ---
>
> defaults
> log global
> maxconn 8000
> option redispatch
> option allbackups
> retries 3
> stats enable
> timeout http-request 10s
> timeout queue 1m
> timeout connect 10s
> timeout client 1m
> timeout server 1m
> timeout check 10s
>
> frontend default-http
> bind :80
> mode http
> force-persist if TRUE
> option httplog
> use_backend
%[base,regsub(^www\.,,i),map_beg(/etc/haproxy/http-bases-to-backends.map,default)]
>
> frontend default-https
> bind :443 ssl crt /etc/ssl/haproxy
> mode http
> force-persist if TRUE
> option httplog
> option http-server-close
> option forwardfor
> reqadd X-Forwarded-Proto:\ https
> reqadd X-Forwarded-Port:\ 443
> use_backend
%[base,regsub(^www\.,,i),map_beg(/etc/haproxy/http-bases-to-backends.map,default)]
>
> backend pieter-tomcat-tst
> mode http
> balance roundrobin
> cookie JSESSIONID prefix nocache
> redirect scheme https code 302 if !{ ssl_fc }
> server pieter-tomcat-01t:8080 10.15.17.142:8080 check cookie s01
> server pieter-tomcat-02t:8080 10.15.33.183:8080 check cookie s02
>
>
>
> In defaults I have "option redispatch" and in the frontends
"force-persist if
> TRUE". But when I put both tomcat servers in maintenance mode I get a 503
> served.
> Why am I not getting access even though the servers are in maintenance
mode?
For me it works here. The difference is that I'm using cookie insertion
since my server do not provide a cookie. Are you certain that you reached
the page where your servers delivered this cookie so that the persistence
can work ? I suspect that you don't have the JSESSIONID cookie yet in your
case.
Willy
Re: What is a nice way to bypass the maintenance mode for certain IP's?
Hi Pieter,
On Thu, Mar 01, 2018 at 01:16:36PM +, Pieter Vogelaar wrote:
> Hi Willy,
>
> I have the following (stripped down) configuration:
>
> ---
>
> defaults
> log global
> maxconn 8000
> option redispatch
> option allbackups
> retries 3
> stats enable
> timeout http-request 10s
> timeout queue 1m
> timeout connect 10s
> timeout client 1m
> timeout server 1m
> timeout check 10s
>
> frontend default-http
> bind :80
> mode http
> force-persist if TRUE
> option httplog
> use_backend
> %[base,regsub(^www\.,,i),map_beg(/etc/haproxy/http-bases-to-backends.map,default)]
>
> frontend default-https
> bind :443 ssl crt /etc/ssl/haproxy
> mode http
> force-persist if TRUE
> option httplog
> option http-server-close
> option forwardfor
> reqadd X-Forwarded-Proto:\ https
> reqadd X-Forwarded-Port:\ 443
> use_backend
> %[base,regsub(^www\.,,i),map_beg(/etc/haproxy/http-bases-to-backends.map,default)]
>
> backend pieter-tomcat-tst
> mode http
> balance roundrobin
> cookie JSESSIONID prefix nocache
> redirect scheme https code 302 if !{ ssl_fc }
> server pieter-tomcat-01t:8080 10.15.17.142:8080 check cookie s01
> server pieter-tomcat-02t:8080 10.15.33.183:8080 check cookie s02
>
>
>
> In defaults I have "option redispatch" and in the frontends "force-persist if
> TRUE". But when I put both tomcat servers in maintenance mode I get a 503
> served.
> Why am I not getting access even though the servers are in maintenance mode?
For me it works here. The difference is that I'm using cookie insertion
since my server do not provide a cookie. Are you certain that you reached
the page where your servers delivered this cookie so that the persistence
can work ? I suspect that you don't have the JSESSIONID cookie yet in your
case.
Willy
Re: What is a nice way to bypass the maintenance mode for certain IP's?
Hi Willy,
I have the following (stripped down) configuration:
---
defaults
log global
maxconn 8000
option redispatch
option allbackups
retries 3
stats enable
timeout http-request 10s
timeout queue 1m
timeout connect 10s
timeout client 1m
timeout server 1m
timeout check 10s
frontend default-http
bind :80
mode http
force-persist if TRUE
option httplog
use_backend
%[base,regsub(^www\.,,i),map_beg(/etc/haproxy/http-bases-to-backends.map,default)]
frontend default-https
bind :443 ssl crt /etc/ssl/haproxy
mode http
force-persist if TRUE
option httplog
option http-server-close
option forwardfor
reqadd X-Forwarded-Proto:\ https
reqadd X-Forwarded-Port:\ 443
use_backend
%[base,regsub(^www\.,,i),map_beg(/etc/haproxy/http-bases-to-backends.map,default)]
backend pieter-tomcat-tst
mode http
balance roundrobin
cookie JSESSIONID prefix nocache
redirect scheme https code 302 if !{ ssl_fc }
server pieter-tomcat-01t:8080 10.15.17.142:8080 check cookie s01
server pieter-tomcat-02t:8080 10.15.33.183:8080 check cookie s02
In defaults I have "option redispatch" and in the frontends "force-persist if
TRUE". But when I put both tomcat servers in maintenance mode I get a 503
served.
Why am I not getting access even though the servers are in maintenance mode?
Best regards,
Pieter Vogelaar
Op 19-02-18 14:04 heeft Willy Tarreau geschreven:
Hi,
On Mon, Feb 19, 2018 at 12:18:36PM +, Pieter Vogelaar wrote:
> Hi,
>
> At the moment if we set backends in maintenance mode, the servers can't be
> reached by anyone.
> Is it possible to still allow traffic from certain IP's (of the office
> network) so that testing can be done, before the backend is available to
the
> general public again?
Please take a look at "force-persist", it's designed exactly for what
you want to do.
Regards,
Willy
Re: http/2 PUT's without content-length fail to http 1.1 backend
On Thu, Mar 01, 2018 at 09:38:10AM +, Robert Samuel Newson wrote: > Yup, agreed, the frame-only transfers are only really implied in the spec > (8.1.2.6's, "A request or response that includes a payload body _can_ include > a content-length header field", my emphasis). The http 2 spec does > specifically prohibit the transfer-encoding: chunked header, again implying > that the framing mechanism subsumes it. In fact it's even worse for me : I identified I had to do it, as indicated by the comments on top of function h2_frt_transfer_data() which claim that when no C-L nor tunnel is found, chunks are emitted. But apparently relying too much on the checks I had on the paper-written RFC allowed me to completely forget about this part! I've checked if I had a temporary implementation in one of my previous dev branches but no, so I think I never wrote that code. The good point is that the code was written with this in mind, so I hope I won't face too big a surprise (and none of the usual "ah now I remember why"). > There are a few libraries (like https://github.com/go-kivik/couchdb) which > implement PUT without sending Content-Length, but other tools, like good old > curl, which do send it. Good to know, thanks for the links. Indeed, curl always used C-L. > The basic plan to transform to a chunked transfer encoding sounds right to > me, and I'll keep an eye out for commits, I'm happy to test it out. Thanks! Willy
Re: [PATCH] proxy-v2-options ssl-cipher,cert-sig,cert-key,authority
On Thu, Mar 01, 2018 at 11:21:15AM +0100, Emmanuel Hocdet wrote: > > I can merge it after applying the small changes above, unless you have > > a different idea. Just let me know. > > > Good for me. > Thanks. OK now merged. Thanks. Willy
Re: [PATCH] proxy-v2-options ssl-cipher,cert-sig,cert-key,authority
Hi Willy,
> Le 1 mars 2018 à 07:00, Willy Tarreau a écrit :
>
> Hi Manu,
>
> this series is giving me two build warnings :
>
> src/ssl_sock.c: In function 'ssl_sock_load_multi_cert':
> src/ssl_sock.c:3143:3: warning: ISO C90 forbids mixed declarations and code
> [-Wdeclaration-after-statement]
> src/ssl_sock.c: In function 'ssl_sock_load_cert_chain_file':
> src/ssl_sock.c:3215:2: warning: ISO C90 forbids mixed declarations and code
> [-Wdeclaration-after-statement]
>
> I could easily address them with this :
>
> @@ -3080,6 +3080,7 @@ static int ssl_sock_load_multi_cert(const char
> *path, struct bind_conf *bind_con
> while (node) {
> SSL_CTX *cur_ctx;
> char cur_file[MAXPATHLEN+1];
> + const struct pkey_info kinfo = { .sig =
> TLSEXT_signature_anonymous, .bits = 0 };
>
> str = (char *)container_of(node, struct sni_keytype,
> name)->name.key;
> i = container_of(node, struct sni_keytype,
> name)->keytypes;
> @@ -3140,9 +3141,8 @@ static int ssl_sock_load_multi_cert(const char
> *path, struct bind_conf *bind_con
> /* Update key_combos */
> key_combos[i-1].ctx = cur_ctx;
> }
> - struct pkey_info kinfo;
> - kinfo.sig = TLSEXT_signature_anonymous;
> - kinfo.bits = 0;
>
> /* Update SNI Tree */
> key_combos[i-1].order = ssl_sock_add_cert_sni(cur_ctx,
> bind_conf, ssl_conf,
> @@ -3207,9 +3207,7 @@ static int ssl_sock_load_cert_chain_file(SSL_CTX
> *ctx, const char *file, struct
> pem_password_cb *passwd_cb;
> void *passwd_cb_userdata;
> EVP_PKEY *pkey;
> - struct pkey_info kinfo;
> - kinfo.sig = TLSEXT_signature_anonymous;
> - kinfo.bits = 0;
> + struct pkey_info kinfo = { .sig = TLSEXT_signature_anonymous,
> .bits = 0 };
>
>#ifdef SSL_CTRL_SET_TLSEXT_HOSTNAME
> STACK_OF(GENERAL_NAME) *names;
>
> That made me wonder if we'd rather have an initialization constant for
> pkey_info, but it doesn't seem used a lot so it would probably only
> obfuscate the code.
>
> I can merge it after applying the small changes above, unless you have
> a different idea. Just let me know.
>
Good for me.
Thanks.
Manu
Re: http/2 PUT's without content-length fail to http 1.1 backend
Hi, Yup, agreed, the frame-only transfers are only really implied in the spec (8.1.2.6's, "A request or response that includes a payload body _can_ include a content-length header field", my emphasis). The http 2 spec does specifically prohibit the transfer-encoding: chunked header, again implying that the framing mechanism subsumes it. There are a few libraries (like https://github.com/go-kivik/couchdb) which implement PUT without sending Content-Length, but other tools, like good old curl, which do send it. The basic plan to transform to a chunked transfer encoding sounds right to me, and I'll keep an eye out for commits, I'm happy to test it out. Thanks! B. > On 1 Mar 2018, at 06:16, Willy Tarreau wrote: > > Hi Robert, > > On Tue, Feb 27, 2018 at 08:26:01PM +, Robert Samuel Newson wrote: >> Hi, >> >> I use haproxy (1.8.4) with http/2 support in front of a server that speaks >> http 1.1. This is working great with one exception. Several http/2 client >> libraries are sending PUT requests without sending the Content-Length header >> (as it' not strictly needed due to the framing). > > At first I thought this was not valid but in fact it obviously is since > it is the equivalent of chunked encoding for HTTP/1. Interestingly, just > like chunked uploads are not much documented in the HTTP/1 specs, this > frame-only transfer is never mentionned in the HTTP/2 spec and I totally > overlooked it. > >> The http 1.1 request issued >> to the backend is therefore malformed as the header is required there. >> >> I think the right thing here is for haproxy to convert the PUT to a chunked >> transfer request to the backend. > > Yes I think so as well. It will be a bit tricky though. From what I'm > imagining, we'll have to add "Transfer-encoding: chunked" if the HEADERS > frame doesn't carry the END_STREAM flag and there is no Content-length > header, then all DATA frames will have to be prefixed with a chunk size > and the frame carrying the ES flag will have to cause the final empty > chunk to be sent. This one will be a bit delicate I think, as we don't > want to lose it if the output buffer is full and we want not to miss the > event. > > Also we must not do this for the CONNECT method! > > I'm adding this to the todo list of fixes for H2. I don't promise to > have it by 1.8.5 though, but I'll try. > > Thanks! > Willy
