On Tue, Feb 26, 2019 at 12:37:11PM +0100, Tom wrote:
> Hi Jérôme
>
> Many thanks for your hint. This solved the initial problem. But there are
> other issues regarding http2:
>
> 1)
> When I enable "errorfile 503 /etc/haproxy/503.html" in the defaults-section,
> then haproxy comes not up and logs the following error:
> "Unable to convert message in HTX for HTTP return code 503."
So this means that this file doesn't parse as an HTTP message. Are you
certain it really is HTTP and is not just an HTML page ? Its name makes
me think it could possibly be just HTML.
> 2)
> When I enable removing the server-header from the backend with "rspidel
> ^Server:.*", then the haproxy-workers are terminating with Segmentation
> fault and the website via haproxy is not working:
> Feb 26 12:02:09 haproxy: [NOTICE] 056/120209 (31432) : New worker #1 (31433)
> forked
> Feb 26 12:02:12 haproxy: [ALERT] 056/120212 (31432) : Current worker #1
> (31433) exited with code 139 (Segmentation fault)
> Feb 26 12:02:12 haproxy: [ALERT] 056/120212 (31432) : exit-on-failure:
> killing every workers with SIGTERM
> Feb 26 12:02:12 haproxy: [WARNING] 056/120212 (31432) : All workers exited.
> Exiting... (139)
Then we have a bug here. {req,rsp}{,i}{add,rep,del} are a very old API
from haproxy 1.1. I know that Christopher suffered quite a bit when
porting it to HTX. At each release I swear we'll deprecate it in favor
of the much cleaner, reliable and faster http-{request,response} ...
rules, but each time I forget.
> 3) When I enable "http2_push_preload on;" on the nginx (because nginx wants
> to push images etc.) then the website is not working and I have the
> following entries in the haproxy-log:
> Feb 26 12:04:50 localhost haproxy[31691]: srcip=1.1.1.1:56146
> feip=10.10.10.10:443(http-in,http-in~,1) beip=-:-(http-in,0)
> serverip=-:-(<NOSRV>) <BADREQ> 1/1/0/0/0 0/0 requests=11 resptime=-1
> bytesread=0 status=0 tsc=PR-- sslv=TLSv1.2 ms=114
> Feb 26 12:04:50 localhost haproxy[31691]: srcip=1.1.1.1:56146
> feip=10.10.10.10:443(http-in,http-in~,1) beip=10.10.10.10:38632(server1,0)
> serverip=10.20.20.20:443(webserver1) GET /auth HTTP/1.1 1/1/0/0/0 0/0
> requests=10 resptime=-1 bytesread=0 status=-1 tsc=SD-- sslv=TLSv1.2 ms=114
This is very strange. We don't support push, but push is a negotiation,
so there is no reason for push responses to be sponatenously emitted by
nginx if not invited to do so! Or maybe it fails on the settings frame
because nginx announces an incorrect value (the standard allows only 0
or 1) ? You can check this on your test environment by making haproxy
die when this happens by applying this change :
diff --git a/src/mux_h2.c b/src/mux_h2.c
index 5ae2297a0..348bf0b0c 100644
--- a/src/mux_h2.c
+++ b/src/mux_h2.c
@@ -1501,6 +1501,7 @@ static int h2c_handle_settings(struct h2c *h2c)
case H2_SETTINGS_ENABLE_PUSH:
if (arg < 0 || arg > 1) { // RFC7540#6.5.2
error = H2_ERR_PROTOCOL_ERROR;
+ abort();
goto fail;
}
break;
If it dies then it means such an invalid value was advertised.
Thanks,
Willy
