我最近遇到了一个特定的安全设备（BlueCoat），它要求所有到Internet的连接都必须通过它来代理（你好，中间人），并相应地使用特殊的SSL证书来拦截所有的stream量。
这阻止了Git的正常操作，即使设置了适当的http.proxy和http.sslCAInfo属性来确保SSL连接本身正常工作。
使用环境variablesGIT_CURL_VERBOSE=1 ，我们发现使用git clone ，会发生HTTP 407（需要代理身份validation）。 Git正确地完成了这个authentication，最后，设备返回一个带有Cookie头部Set-Cookie的HTTP 200。
然后Git将连接到目标服务器，但没有 cookie，导致HTTP 401。
解决方法是设置gitconfiguration选项http.saveCookies=true
问题： RFC标准是否允许中间代理添加Cookie？
Anthony Rich 向http-state邮件列表提出了同样的问题，但没有任何回应。 他确实注意到了
RFC 2965 HTTP状态pipe理机制，3.5高速caching代理angular色它说：代理不能在代理响应（请求）中引入自己的Set-Cookie2（Cookie）头。
然而， 取代的RFC 6265完全没有提到这一点。
HTTPcookies是一个混乱。 没有真正的标准; RFC的价值仅仅是试图logging实际的用户代理正在做什么。
在任何情况下，你可能想读的RFC是RFC 7235 ，它指定代理应该发送一个带有401错误的代理 – authentication头来请求authentication信息，并且接收到这个代理的用户代理应该重试请求包含代理的身份validation信息的代理授权标头。
可以使用一些质疑/响应方法来提供这些信息; 最广泛使用的是“基本”（ RFC 7617 ），几乎所有说HTTP的实现它。
IANA维护已知的HTTPauthenticationscheme的registry 。 作为一般规则，他们使用先前命名的HTTP标头，或将其标记为不合规。 没有使用cookies进行身份validation。
无论是否允许代理添加或更改Cookie，我都不能说。 RFC在这一点上似乎并不十分清楚。 这肯定是出乎意料的行为，尤其是对于身份验 BlueCoat在质量上有着悠久的历史