http2 error: Invalid HTTP header field was received:

[Johnatan Hallman]

Hello,

Yes your solution did work with version:

nginx version: nginx/1.18.0
built with LibreSSL 3.3.2

I removed http2 from all vhost effectively disabling it on the server and it works fine. I wonder if I even need it for anything :)

But as you said this might not even be an option in the future and this is an older nginx install anyway so it would be nice to have some option for these kind of situations in the future.

Thanks



------- Original Message -------
On Tuesday, May 23rd, 2023 at 6:18 PM, Maxim Dounin <mdounin at mdounin.ru> wrote:


> 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 at nginx.org
> https://mailman.nginx.org/mailman/listinfo/nginx