Hi Pieter,
On Sat, Jan 26, 2019 at 09:04:06PM +0100, PiBa-NL wrote:
> Today ive given it another shot. (connecting to mail.google.com).
> Is there a way in haproxy to directly 'manipulate' the h2 headers? Setting
> h2 header with set-header :authority didn't seem to work.?
No, these ones are pseudo-headers and are meant for the protocol, we
must not (and cannot) manipulate them. In fact you manipulate them
differently. For example, ":method" is the method. ":status" is the
status, ":path" is the path. So you act on them using the respective
rules.
> See attached some logs a packetcapture and a vtc that uses google's servers
> itself.
Thanks for this, I'm going to take a look at these.
> It seems google replies "Header: :status: 400 Bad Request" But leaves me
> 'guessing' why it would be invalid,
Interesting case.
> also the 'body' doesn't get downloaded
> but haproxy terminates the connection, which curl then reports as missing
> bytes..
This could be related to the lack of content-length in the error messages
but at least we should see the equivalent of chunked data. I'll take a look
at these too.
> There are a few differences between the 2 get requests, authority
> and scheme.. But i also wonder if that is the actual packet with the issue,
> H2 isnt quite a simple as H1 used to be ;).
No, and I'm missing a lot of debugging facilities in this area. I started
to make it possible to perform lower-layer captures so that we can dump
raw H2 frames on the CLI because right not it's really a pain.
> Also with "h2-client-mail.google.vtc" the first request succeeds, but the
> second where the Host header is used fails. I think this shows there is a
> 'need' for the :authority header to be present? Or i mixed something up...
It's very possible.
> p.s.
> Wireshark doesnt nicely show/dissect the http2 requests made by vtest,
> probably because for example the first magic packet is spread out over
> multiple tcp packets, is there a way to make it send them in 1 go, or make
> haproxy 'buffer' the short packets into a bigger complete packets, i tried
> putting a little listen/bind/server section in the request path, but it just
> forwarded the small packets as is..
I'm surprised you get it over multiple packets, because it's extremely small
(24 bytes) so I really don't understand how that's possible. Or maybe it
first sends the preface, then sends the settings, and this is what upsets
wireshark ? You could cheat with a TCP proxy in haproxy. Just force a small
delay before processing incoming data, this will leave time to more data to
come and the output will contain the aggregated bytes :
listen splice-data
mode tcp
bind :5555
tcp-request inspect-delay 300
tcp-request content accept if WAIT_END
server next 1.1.1.1:5555
You may even explicitly wait for the minimum amount of data needed :
listen splice-data
mode tcp
bind :5555
tcp-request inspect-delay 10s
tcp-request content accept if { req.len gt 24 }
server next 1.1.1.1:5555
Willy
