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
