Hello! On Tue, May 23, 2023 at 02:51:02PM +0000, Johnatan Hallman via nginx wrote:
> Hello List, > > I have a setup where I put an ancient host running a perl-cgi > app behind an nginx reverse proxy. > > The http reverse proxy works fine however if I try: > > curl -v --anyauth -k https://app.test.lan/cgi-bin/page.pl > > I get: > > http2 error: Invalid HTTP header field was received: frame type: > 1, stream: 3, name: [defined(%hash) is deprecated at page.pl > line 14.], value: [] > > However if I define http1.1 it works fine: > > curl -v --http1.1 --anyauth -k > https://app.test.lan/cgi-bin/page.pl > > I guess all modern browsers default to http2 these days so that > I can specify it for curl is not a big help. I need this to work > out of the box. > > I have read that Nginx with the listen 443 ssl http2; > directive will downgrade the connection to http1.1 automatically > if it's negotiated... otherwise my previous test wouldn't work > at all. > > What I have tried is adding this version directive into the > location: > > location / { > proxy_pass http://10.9.0.90/; > proxy_http_version 1.1; > } > > Makes no difference. Any idea how to fix this without touching > the original app or the original webserver. It looks like the original app returns an invalid HTTP header (or, more specifically, returns Perl warnings among the HTTP headers). This used to work, but with stricter header checking requirements in HTTP/2 it is rejected by the clients. Further, nginx itself will reject such invalid upstream responses starting with nginx 1.21.1, quoting CHANGES: *) Change: now nginx always returns an error if spaces or control characters are used in a header name. That is, with newer nginx version the only option is to actually fix the upstream server. With older nginx versions, you may try disabling HTTP/2 (that is, on the listen socket) as a temporary workaround, this will likely prevent (at least some) clients from rejecting such invalid responses. Note though that this is, uhm, a workaround, and proper solution is to fix the upstream server. -- Maxim Dounin http://mdounin.ru/ _______________________________________________ nginx mailing list nginx@nginx.org https://mailman.nginx.org/mailman/listinfo/nginx
