HTTP/1.1 400 Bad Request: invalid header name

[T200proX7]

Im using

curl 7.78.0 (x86_64-pc-linux-gnu) libcurl/7.78.0 OpenSSL/1.1.1l zlib/1.2.11 zstd/1.5.0 libidn2/2.3.2 libpsl/0.21.1 (+libidn2/2.3.0) libssh2/1.9.0 nghttp2/1.44.0
Release-Date: 2021-07-21
Protocols: dict file ftp ftps gopher gophers http https imap imaps mqtt pop3 pop3s rtsp scp sftp smb smbs smtp smtps telnet tftp 
Features: alt-svc AsynchDNS GSS-API HSTS HTTP2 HTTPS-proxy IDN IPv6 Kerberos Largefile libz NTLM NTLM_WB PSL SPNEGO SSL TLS-SRP UnixSockets zstd

I use curl in a golang application for a long time. The application is working on another computer running debian. I have tried to use it on the current computer (running Arch) and always receive the http error response message HTTP/1.1 400 Bad Request: invalid header name

I rechecked the application at the debian computer and even the command line itself. It is working fine with curl 7.52.1

The -v output of curl on the arch computer (with the obviously broken curl version) is:

* Closing connection 0
* TLSv1.3 (IN), TLS alert, close notify (256):
* TLSv1.3 (OUT), TLS alert, close notify (256):
* Issue another request to this URL: 'REQUESTED URL'
* Hostname proxyip was found in DNS cache
*   Trying proxyip:proxyport...
* Connected to proxyip (proxyip) port proxyport (#1)
* allocate connect buffer!
* Establish HTTP proxy tunnel to ip123454.hidden.host:443
* Proxy auth using Basic with user 'username'
> CONNECT ip123454.hidden.host:443 HTTP/1.1
> Host: ip123454.hidden.host:443
> Proxy-Authorization: Basic sdgasdgasdgdsgdg==
> (nil)Proxy-Connection: Keep-Alive
> 
< HTTP/1.1 400 Bad Request: invalid header name
< Content-Type: text/plain; charset=utf-8
< Connection: close

I guess the problem is because of (nil) in the header name Proxy-Connection.

The strange thing is, that i think a week ago? it was working fine on the arch computer. I cant remember so clearly right now.

[bagder]

Can you give us more details on how to reproduce this?

[dfandrich]

Can you show us the headers for the working version? How about the code that sets up the easy handle?

[T200proX7]

curl --http1.1 -s -S -L -H "Pragma: no-cache" -H "Cache-Control: no-cache" -H "Connection: close" -H "Accept: */*" -v -x "http://user:pass@proxyip:port" -H "Accept-Language: en-US,en;q=0.5" -H "User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:83.0) Gecko/20100101 Firefox/83.0" -H "Referer: https://www.myreferer.com" -H "Origin: https://www.myreferer.com" https://www.myreferer.com/file.mp4

[T200proX7]

On debian -> working one -> header:

* Curl_http_done: called premature == 0
* Closing connection 0
} [5 bytes data]
* TLSv1.2 (OUT), TLS alert, Client hello (1):
} [2 bytes data]
* Issue another request to this URL: 'REQUESTED URL'
* Hostname proxyip was found in DNS cache
*   Trying proxyip...
* TCP_NODELAY set
* Connected to (nil) (proxyip) port proxyport (#1)
Establish HTTP proxy tunnel to ip123454.hidden.host:443
* Proxy auth using Basic with user 'username'
> CONNECT ip123454.hidden.host:443 HTTP/1.1
> Host: ip123454.hidden.host:443
> Proxy-Authorization: Basic sdgasdgasdgdsgdg==
> User-Agent: curl/7.52.1
> Proxy-Connection: Keep-Alive
> 
< HTTP/1.0 200 OK
< 
* Proxy replied OK to CONNECT request

It seems there is a problem or at least a strange behaviour regarding the User-Agent in the proxy connection part (but not in the first connection).
On my debian machine curl sets the user agent for the proxy-connection to "curl/7.52.1"; on my arch machine curl does not set any user-agent - it seems that (nil) comes from the user agent and destroy the following header field name

Let me give you some more details:

1. Curl opens a connection to my proxy (both curl version same - user agent is given (curl/7.52.1 or curl/7.78.0)
2. Curl access the requested url over proxy and receive 302 Found with a Location (output looks same)
3. Curl access proxy again (on debian with user-agent and on arch with (nil) instead the user agent)

(I will update the header up of the arch proxy connection)

[bagder]

Reproduced!

[T200proX7]

Great - nice to hear. Thank you. Lets see when Arch receives the update.