http2 error: Invalid HTTP header field was received:

[Maxim Dounin]

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/