Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

HTTP/1.1 400 Bad Request: invalid header name #7705

Closed
T200proX7 opened this issue Sep 11, 2021 · 6 comments
Closed

HTTP/1.1 400 Bad Request: invalid header name #7705

T200proX7 opened this issue Sep 11, 2021 · 6 comments
Assignees
@bagder
Labels
connecting & proxies HTTP

Comments

@T200proX7
Copy link

T200proX7 commented Sep 11, 2021 •
edited

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
Copy link
Member

bagder commented Sep 11, 2021

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

@dfandrich
Copy link
Contributor

dfandrich commented Sep 11, 2021 via email

@T200proX7
Copy link
Author

T200proX7 commented Sep 11, 2021 •
edited 

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
Copy link
Author

T200proX7 commented Sep 11, 2021 •
edited

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
Copy link
Member

bagder commented Sep 11, 2021

Reproduced!

@bagder bagder self-assigned this Sep 11, 2021
bagder added a commit that referenced this issue Sep 11, 2021
@bagder
http_proxy: fix the User-Agent inclusion in CONNECT
7d59793 
It should not refer to the uagent string that is allocated and created
for the end server http request, as that pointer may be cleared on
subsequent CONNECT requests.

Added test case 1184 to verify.

Reported-by: T200proX7
Fixes #7705
bagder added a commit that referenced this issue Sep 11, 2021
@bagder
http_proxy: fix the User-Agent inclusion in CONNECT
2ddaed8 
It should not refer to the uagent string that is allocated and created
for the end server http request, as that pointer may be cleared on
subsequent CONNECT requests.

Added test case 1184 to verify.

Reported-by: T200proX7 on github
Fixes #7705
@bagder bagder mentioned this issue Sep 11, 2021
Closed
@T200proX7
Copy link
Author

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

bagder added a commit that referenced this issue Sep 13, 2021
@bagder
http_proxy: fix the User-Agent inclusion in CONNECT
4a8fa48 
It should not refer to the uagent string that is allocated and created
for the end server http request, as that pointer may be cleared on
subsequent CONNECT requests.

Added test case 1184 to verify.

Reported-by: T200proX7 on github
Fixes #7705
Closes #7707
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@bagder bagder

Labels
connecting & proxies HTTP
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

http_proxy: fix the User-Agent inclusion in CONNECT curl/curl
3 participants
@bagder @dfandrich @T200proX7