69059 - Proxy-Authentication info is not being associated with proxy or realm

Status: VERIFIED DUPLICATE of bug 49032

(Core :: Networking: HTTP, defect)

Description

[Bob McElrath]

When using Proxy-Authenticate, mozilla is associating the name and password
(Basic authentication) with the host requested.  i.e. 
	Mozilla requests http://<host>/ 
	Proxy sends auth challenge using the Proxy-Authenticate header:
		Proxy-Authenticate: BASIC realm="FilterProxy"
	Mozilla pops up a dialog box that says:
		"Enter username for <realm> at <host>"
	Authentication proceeds normally.

Under certain circumstances Mozilla will "lose" the authentication information. 
(i.e. proxy connection times out and proxy re-sends authorization challenge the
next time mozilla requests a URL, for a *different* host).  Mozilla does not use
the previously entered name and password (for the same realm, same proxy,
different host in above example), but instead prompts the user again for name
and password.

The correct behavior would be to associate the authentication information with
either the realm or proxy host/port, and continue to send that authorization as
long as the same proxy is being used.  Instead mozilla will only *not* re-prompt
for the password if the same host is used for the request (after proxy
connection timeout).  However, I think this is the action of the Password
Manager, rather than the Networking component.

It is possible that I have implemented this portion of the HTTP/1.1 spec
incorrectly (though I have checked several times and I think I've got it right),
so I would appreciate enlightenment if mozilla is behaving correctly.  Netscape
4.7x, Konqueror do not have this problem.  Can someone verify this using Squid
or some other proxy that uses HTTP/1.1 and Proxy-Authorization?

I have seen this on linux with all versions in recent memory (0.7-0.8 nightlies)

Comment 1

[Keyser Sose]

*** This bug has been marked as a duplicate of 49032 ***

Comment 2

[benc]

qa to me.
The dialog problem was cosmetic and addressed in bug 60588, but the real problem
here was proxy-auth not being sticky to the proxy server connection.