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

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

Comments

Projects
None yet
2 participants
@ljwagerfield

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

http-proxy: treat all 2xx as CONNECT success
Reported-by: Lawrence Wagerfield
Fixes #1859
@bagder

This comment has been minimized.

Show comment
Hide comment
@bagder

bagder Sep 4, 2017

Member

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

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

http-proxy: treat all 2xx as CONNECT success
Added test 1904 to verify.

Reported-by: Lawrence Wagerfield
Fixes #1859
@ljwagerfield

This comment has been minimized.

Show comment
Hide comment
@ljwagerfield

ljwagerfield Sep 5, 2017

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.

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

This comment has been minimized.

Show comment
Hide comment
@bagder

bagder Sep 5, 2017

Member

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!

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 in 3130414 Sep 5, 2017

@bagder

This comment has been minimized.

Show comment
Hide comment
@bagder

bagder Sep 5, 2017

Member

Thanks!

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.