Status: Started Owner: [email protected] CC: [email protected], [email protected] Labels: Type-Bug Pri-2 OS-All Area-BrowserBackend
New issue 8325 by [email protected]: NTLM authentication to a proxy doesn't work if Privoxy sits in between http://code.google.com/p/chromium/issues/detail?id=8325 After I checked in our NTLM authentication code in r10667, igitur reported this problem in issue 6567#c23. He said (reordered by me for clarity): I use Privoxy on my office PC which forwards requests the company proxy, which in turn requires NTLM authentication. Privoxy itself isn't explicitly configured to require any sort of authentication. I looked at the traffic with Wireshark and it seems the full NTLM cycle isn't completed. I suspect that Privoxy may have rewritten some response headers from the proxy, so that Chromium thinks the connection is not keep-alive and opens a new connection for the second half of the NTLM cycle. This is done in HttpNetworkTransaction::PrepareForAuthRestart: bool keep_alive = false; if (response_.headers->IsKeepAlive()) { // If there is a response body of known length, we need to drain it first. if (content_length_ > 0 || chunked_decoder_.get()) { next_state_ = STATE_DRAIN_BODY_FOR_AUTH_RESTART; read_buf_ = new IOBuffer(kDrainBodyBufferSize); // A bit bucket read_buf_len_ = kDrainBodyBufferSize; return; } if (content_length_ == 0) // No response body to drain. keep_alive = true; // content_length_ is -1 and we're not using chunked encoding. We don't // know the length of the response body, so we can't reuse this connection // even though the server says it's keep-alive. } // We don't need to drain the response body, so we act as if we had drained // the response body. DidDrainBodyForAuthRestart(keep_alive); So we can try changing the outermost if test to: if (response_.headers->IsKeepAlive() || auth_handler_[target]->is_connection_based()) { Darin, do you know if this is what Firefox does? For connection-based auth schemes, does Firefox ignore any HTTP/1.1 "Connection: close" or "Proxy- Connection: close" response header? (Or equivalently, for HTTP/1.0 responses, does Firefox tolerate missing "Connection: keep-alive" or "Proxy-Connection: keep-alive" headers?) -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings --~--~---------~--~----~------------~-------~--~----~ Automated mail from issue updates at http://crbug.com/ Subscription options: http://groups.google.com/group/chromium-bugs -~----------~----~----~----~------~----~------~--~---
