Open Bug 149103 Opened 22 years ago Updated 2 years ago

HTTP auth does not populate user field

Categories

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

defect

Tracking

()

Future

People

(Reporter: benc, Unassigned)

References

()

Details

(Whiteboard: [necko-would-take])

From bug 81110: Ignore examples from before, ftp is pretty much off (and never coming back) at packetgram.com... STEPS: 1- Configure to use "FTP Proxy" (actually URL proxy over HTTP) 2- Connect to an FTP server and force auth (by having a username in your ftp URL) OBSERVED: receive username + password dialog EXPECTED: since the username is already in the URL, the dialog should be pre-populated. confirmed this works in 4xp
Keywords: 4xp
I have no time to work on mozilla at the moment, so dougt is taking over FTP open ftp bugs -> him
Assignee: bbaetz → dougt
Target Milestone: --- → mozilla1.3alpha
do we have any similar problems with HTTP?
Target Milestone: mozilla1.3alpha → Future
I don't know. I thought that username:password was not allowed in http:// URLs but some people think it is. This is probably an RFC 1738 vs. RFC 2396 kind of debate. Andreas+Darin: can you recall any bugs/design desicions about that?
username:password is allowed in http but not recommended. We support it in urls 100%. My guess, this is a problem in the population of the dialog.
I realized I could test this by typing a propery constructed URL, and the problem is indeed the HTTP auth dialog.
Assignee: dougt → darin
Component: Networking: FTP → Networking: HTTP
QA Contact: benc → httpqa
Summary: Proxy/FTP - FTP-level auth (really HTTP) does not populate user field → HTTP auth does not populate user field
hmm, for http:// and https:// we strip out the username:password from the URL before sending it as the HTTP request-URI, but we _do not_ do this if the URL has some other scheme such as ftp://.
Assignee: darin → nobody
Whiteboard: [necko-would-take]
Priority: -- → P5
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.