Description
@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 8.1.2.2 (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?
http://tools.ietf.org/html/rfc7230 says:
One attempted solution was the introduction of a Proxy-Connection
header field, targeted specifically at proxies. In practice, this
was also unworkable, because proxies are often deployed in multiple
layers, bringing about the same problem discussed above.
As a result, clients are encouraged not to send the Proxy-Connection
header field in any requests.
In curl, I see:
lib/http.c: "%s" /* Proxy-Connection */
lib/http.c: !Curl_checkProxyheaders(conn, "Proxy-Connection:"))?
lib/http.c: "Proxy-Connection: Keep-Alive\r\n":"",
lib/http.c: "Proxy-Connection:", "keep-alive")) {
lib/http.c: * 'Proxy-Connection: keep-alive' line tells us the
lib/http.c: connkeep(conn, "Proxy-Connection keep-alive"); /* don't close */
lib/http.c: "Proxy-Connection:", "close")) {
lib/http.c: connclose(conn, "Proxy-Connection: asked to close after done");
lib/http_proxy.c: if(!Curl_checkProxyheaders(conn, "Proxy-Connection:"))
lib/http_proxy.c: proxyconn = "Proxy-Connection: Keep-Alive\r\n";
lib/http_proxy.c: "%s", /* Proxy-Connection */
lib/http_proxy.c: "Proxy-Connection:", "close"))
Thanks!