Closed Bug 74246 Opened 19 years ago Closed 16 years ago
HTTPChannel::Authenticate always opens a new transport
If my understanding of the way authentication works is correct, a "401 access denied" server response is handled in the following way: - Create an instance of nsIAuthenticator - if required pop-up a dialog box for user/pass combination - Let nsIAuthenticator create a "WWW-Authenticate" header - build a new nsHTTPChannel with the same request data plus the "WWW-authenticate" header - bind the ResponseDataListener from the current channell to the new channell A side effect of this is that the second, authenticated, request calls nsHTTPHandler::RequestTransport before the the active nsHTTPChannel is done with the connection. The second request is *always* on a different nsSocketTransport than the first one. I am running into problems while implementing NTLM authentication, NTLM authenticates a single TCP connection using a series of requests (2, actually) on the same TCP connection. Since my nsNTLMAuthenticator gets a new nsSocketTransport for each step of the handshake, it fails consistently. Please feel free to mark this thing 'future', I would appreciate some hints on how I could fix this. If I can find the time, I'll have a shot.
Sorry, wrong component.
Component: Networking → Networking: HTTP
Assignee: neeti → darin
zee: nice work in tracking this down!
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.0
much has changed in http since this bug was filed, but it is still relevant b/c we still have the same problem. however, now it will be much much easier to solve this problem.
NTLM support is not targeted for mozilla1.0, and the work to support this probably could happen on the 1.0 branch, so i'm not going to rush to get this in for 1.0. -> future
Target Milestone: mozilla1.0 → Future
this bug has been fixed for a while actually. an authenticator can specify that it is CONNECTION_BASED. the patch for bug 159015 fixed this.
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.