HTTP/3 getsockname Bad file descriptor

[Sergey Kandaurov]

> On 7 Oct 2020, at 06:02, Ryan Gould <ryanbgould at gmail.com> wrote:
> 
> hello all you amazing developers,
> 
> i found some old 2013 references to this error relating to SPDY, but have not seen anything recently.  i am building on a debian 9 box using the latest code from here: https://hg.nginx.org/nginx-quic using build instructions from https://quic.nginx.org/readme.html
> 
> i get the following errors when i use firefox nightly (82.0b8), Chrome/85, or when i use command-line curl (built using quiche):
> 
> 2020/10/07 04:35:04 [alert] 14263#0: *78 getsockname() failed (9: Bad file descriptor), client: X.X.X.X, server: example.com, request: "HEAD / HTTP/3"
> 2020/10/07 04:35:04 [alert] 14263#0: *78 getsockname() failed (9: Bad file descriptor) while sending response to client, client: X.X.X.X, server: example.com, request: "HEAD / HTTP/3"

Thank you for your report.
This is a (known) issue related to how connections are used
in the ngx_http_v3_module.

> i dont know if it is related, but i am also not having any success getting 0-RTT or passing the QUIC test (but HTTP/3 passes) on https://www.http3check.net/
> 
> otherwise, firefox and chrome think they are using HTTP/3 successfully.

This one is unrelated to alerts.  Using 0-RTT requires support in clients.
I am not aware of HTTP/3 0-RTT support in curl (though, it supports HTTP/3).
You may want to try 0-RTT with different clients such as ngtcp2 or kwik.
It should also be explicitly enabled on server with "ssl_early_data on".

-- 
Sergey Kandaurov