I recently encountered a certain security appliance (BlueCoat) which requires that all connections to the internet must be proxied through it (hello there, man-in-the-middle) and accordingly uses a special SSL certificate to intercept all traffic.
This prevented the normal operation of Git, even though the appropriate http.proxy and http.sslCAInfo properties were set to make sure that the SSL connection itself works.
Using the environment variable GIT_CURL_VERBOSE=1, we found that when using git clone, a HTTP 407 (Proxy authentication required) occurs. Git fulfils this authentication properly and at the end of this, the appliance returns a HTTP 200 with a cookie header Set-Cookie.
Git then will connect to the target server, but without the cookie, leading to a HTTP 401.
The solution for this is to set the git configuration option http.saveCookies=true
Question:
Is it actually permitted by the RFC standards that an intermediate proxy adds cookies?
Anthony Rich asked the same question to the http-state mailing list but without any response. He did note that in
RFC 2965 HTTP State Management Mechanism, 3.5 Caching Proxy Role it says:
Proxies MUST NOT introduce Set-Cookie2 (Cookie) headers of their own
in proxy responses (requests).
However, the superseding RFC 6265 doesn't mention this anymore at all.
Best Answer
HTTP cookies are a hot mess. There is no real standard; the RFC, for what it's worth, merely attempts to document what actual user agents are doing.
In any case, the RFC you probably want to read is RFC 7235, which specifies that proxies are supposed to send a Proxy-Authenticate header with the 407 status to request authentication information, and user agents receiving this are supposed to retry the request with a Proxy-Authorization header containing the authentication information for the proxy.
A number of challenge/response methods could be used to supply this information; the most widely used being "basic" (RFC 7617) as pretty much everything that speaks HTTP implements it.
The IANA maintains a registry of known HTTP authentication schemes. As a general rule they use the HTTP headers named previously, or they are noted to be noncompliant. None use cookies for authentication.
Whether it's allowed for a proxy to add or change cookies, I can't say. The RFCs really don't seem to be very clear on this point. It's certainly unexpected behavior, especially for authentication. And BlueCoat has a long history of being mediocre in quality...