Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
GitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
Is use of ancient Proxy-Connection header intentional? #633
@bagder, et al,
In migrating Google internal builds to Go 1.6 from Go 1.5, and we just noticed something odd with curl.
As background, Go 1.6 includes HTTP/2, and on by default.
One team reported 400 Bad Request errors from Google's GFEs (front end load balancers) when using http2. This is because a Go process via its included ReverseProxy was proxying a git request where libcurl set "Proxy-Connection: keep-alive" to the GFE, and the GFE implements RFC 7540 section 22.214.171.124 (no connection-specific header fields) and Go's included ReverseProxy removes hop-by-hop HTTP headers, but forgot to remove the ancient and never-standardized "Proxy-Connection" hop-by-hop header.
Go's bug is now fixed in golang/go@91911e3 but...
Is there any reason that libcurl still sends Proxy-Connection headers?
In curl, I see:
Thanks for digging this up!
Here's what I found when digging deep into our history: The header was added in May 2005 in commit 5d9fc28 and was explained (by me) here. The explanation there is not very detailed: "address (rare) problems with some proxies" and I can for the life of me not remember those details anymore.
Given the age of that change, the current RFC statement and the removal of this header from Firefox (back in 2012), I think we have a good argument to remove it from curl as well.
Pointed out by Eric Lawrence on twitter, Chrome still uses it: https://code.google.com/p/chromium/codesearch#chromium/src/net/http/proxy_client_socket.cc&q=kProxyConnection&sq=package:chromium&type=cs&l=49