74246 - nsHTTPChannel::Authenticate always opens a new transport

Status: RESOLVED FIXED

(Core :: Networking: HTTP, defect, P3)

Description

[Daniel van der Zee]

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.

Comment 1

[Daniel van der Zee]

Sorry, wrong component.

Comment 2

[neeti]

-->http

Comment 3

[Darin Fisher]

zee: nice work in tracking this down!

Comment 4

[Darin Fisher]

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.

Comment 5

[Darin Fisher]

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

Comment 6

[Samir Gehani]

adt: nsbeta1-

Comment 7

[Darin Fisher]

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.