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

HTTP CONNECT does not continue after 204 response from proxy #1859

Closed
ljwagerfield opened this issue Sep 4, 2017 · 4 comments
Closed

HTTP CONNECT does not continue after 204 response from proxy #1859

ljwagerfield opened this issue Sep 4, 2017 · 4 comments

Comments

@ljwagerfield
Copy link

ljwagerfield commented Sep 4, 2017

As per RFC-7231 (4.3.6) curl should treat all 2xx responses as "tunnel established".

Any 2xx (Successful) response indicates that the sender (and all inbound proxies) will switch to tunnel mode immediately after the blank line that concludes the successful response's header section

In this instance curl isn't handling 204 correctly: it responds by ending the connection.

I did this

curl -v --proxytunnel -x http://localhost:8080 http://localhost:8081/

I expected the following

* Connected to localhost (::1) port 8080 (#0)
* allocate connect buffer!
* Establish HTTP proxy tunnel to localhost:8081
> CONNECT localhost:8081 HTTP/1.1
> Host: localhost:8081
> User-Agent: curl/7.55.1
> Proxy-Connection: Keep-Alive
>
< HTTP/1.1 204 No Content
<
* Proxy replied No Content to CONNECT request
* CONNECT phase completed!
> GET / HTTP/1.1
> Host: localhost:8081
> User-Agent: curl/7.55.1
> Accept: */*

What actually happened

* Connected to localhost (::1) port 8080 (#0)
* allocate connect buffer!
* Establish HTTP proxy tunnel to localhost:8081
> CONNECT localhost:8081 HTTP/1.1
> Host: localhost:8081
> User-Agent: curl/7.55.1
> Proxy-Connection: Keep-Alive
>
< HTTP/1.1 204 No Content
<
* Received HTTP code 204 from proxy after CONNECT
* CONNECT phase completed!
* Closing connection 0
curl: (56) Received HTTP code 204 from proxy after CONNECT

curl/libcurl version

curl 7.55.1 (x86_64-apple-darwin16.7.0) libcurl/7.55.1 OpenSSL/1.0.2l zlib/1.2.8 nghttp2/1.25.0
Release-Date: 2017-08-14
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp smb smbs smtp smtps telnet tftp
Features: AsynchDNS IPv6 Largefile NTLM NTLM_WB SSL libz TLS-SRP HTTP2 UnixSockets HTTPS-proxy

operating system

macOS 10.12.6

bagder added a commit that referenced this issue Sep 4, 2017
Reported-by: Lawrence Wagerfield
Fixes #1859
@bagder
Copy link
Member

bagder commented Sep 4, 2017

Thanks, can you try out my simple fix in #1860 and tell us if it works ?

bagder added a commit that referenced this issue Sep 4, 2017
Added test 1904 to verify.

Reported-by: Lawrence Wagerfield
Fixes #1859
@ljwagerfield
Copy link
Author

Yes that fixes it 👍

However, it does report the following:

> CONNECT localhost:80 HTTP/1.1
> Host: localhost:80
> User-Agent: curl/7.56.0-DEV
> Proxy-Connection: Keep-Alive
>
< HTTP/1.1 204 No Content
<
* Proxy replied OK to CONNECT request

This is quite pedantic, but the server didn't reply OK to the CONNECT request, it replied No Content.

Maybe it would be less misleading to replace OK with SUCCESS, or even better the actual status code (e.g. 200 or 204), although I appreciate that may require more of a code change.

@bagder
Copy link
Member

bagder commented Sep 5, 2017

It is "OK" in the sense that all 2xx codes are various forms of OK. But I agree that adding the actual response code instead of the "OK" string there is even more useful. I'll do that and merge this!

@bagder bagder closed this as completed in 3130414 Sep 5, 2017
@bagder
Copy link
Member

bagder commented Sep 5, 2017

Thanks!

@lock lock bot locked as resolved and limited conversation to collaborators May 6, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Development

No branches or pull requests

2 participants