On 4/11/22 12:16, Shawn Heisey wrote:
Two different browsers have the same problem, so I am currently
speculating that it's an issue with haproxy or apache. I think I can
install nginx without too much trouble ... I have almost no experience
with it, so I get to learn something new.
Followup:
I changed the backend to talk to nginx instead of apache. It still
throws a 400 when the POST is done via http/3. It was an adventure
trying to figure out how to allow POST requests in nginx. The 400
appears to be coming from haproxy. There is nothing in the logs on
apache or nginx for those errors.
Here is a screenshot of the backend traffic from that POST seen in
wireshark. 192.168.1.200 is the machine with haproxy, 192.168.1.165 is
the raspberry pi running nginx.
https://www.dropbox.com/s/h2d8b6xmgpvphfb/Screenshot%20from%202022-04-11%2012-49-05.png?dl=0
What I see there is that haproxy sends the POST, nginx sends an ACK, and
then haproxy resets the connection. Am I interpreting that correctly?
This is the matching entry from the haproxy log:
Apr 11 12:47:08 - haproxy[1486593] 192.168.1.219:36723
[11/Apr/2022:12:47:05.189] web be-raspi2-81/legolas 3053/0/1/-1/3053 400
206 - - CHVN 1/1/0/0/0 0/0 {raspi2.elyograg.org} "POST / HTTP/3.0"
I noticed the frontend (web) is missing the ~ character in that log
entry. That is probably related to the fact that ssl_fc is not set for
HTTP/3 connections.
An astute observer will notice that the backend says 81 while the packet
capture shows port 82. This is because I changed the port number on the
server to point to nginx instead of apache, but did not rename the
backend. My use of nginx is temporary, only using it to eliminate
Apache as the problem. I know how to configure Apache; it would take me
forever to fully switch to nginx.
Thanks,
Shawn
