Hi Shawn,
On Mon, Apr 11, 2022 at 01:05:21PM -0600, Shawn Heisey wrote:
> 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?
Yes, but this alone could be caused by different reasons, it simply
indicates an abort from haproxy.
> 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"
"CH" here indicates a client error before the server responds. This most
likely indicates that some contents were not correctly decoded from the
request body, or that the end of request was mistaken for a client abort.
> 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.
Not for this one :-) For the logs there was an exact check for the
regular SSL transport layer. It's now fixed to check if the transport
layer supports SSL. This one, as well as the ssl_* sample fetch functions
were now fixed in latest git if you're interested.
> 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.
I think that the QUIC team will soon ask you to enable traces on the QUIC
layer, but I'll let them follow up ;-)
Cheers,
Willy
