217765 - HTTP: does not always handle username+password from URL correctly

Status: RESOLVED FIXED

(Core :: Networking: HTTP, defect)

Description

[Darin Fisher]

HTTP: does not always handle username+password from URL correctly

(hard to come up with a good summary for this bug.. there are really several issues)

1- if we have a username+password in the URL, and we do not have an auth entry,
   then we cannot send credentials to the server because we don't yet have a 
   challenge.  however, if we have an auth entry, then we can look at the
   challenge and use that to recompute credentials based on the username+
   password found in the URL.  currently, however, we don't do that.  we wait 
   for another challenge.  this results in an extra round-trip that i think we 
   can avoid.  one point though: if the username in the URL matches the username
   in the auth cache, then it is probably wise to use the password from the
   auth cache since it is more likely to be correct (chances are good that it
   has already been tested against the server).

2- also, if we start out with no auth entry and we have a username+password in    
   the URL, then when we receive a challenge, we should populate the auth cache
   with an entry that has the username+password taken from the URL.  this is 
   something we were not doing before because we did not want to replace an
   existing auth entry.  i think we still do not want to replace an existing
   auth entry with username+password from the URL, but if there is no existing
   auth entry then we most certainly should add one to the cache.

attaching a patch that fixes these issues.

Comment 1

[Darin Fisher]

casey: this bug report is fallout from the discussion we had the other day.  i
did some testing based on what you told me and found some specific problems in
the code.  i've got a patch which should help.  please test it out if you get a
chance.  thx!

Comment 2

[Darin Fisher]

Attachment: v1 patch

Comment 3

[Darin Fisher]

this patch doesn't fix all of the problems related to username+password in URL,
but it does help with the issues i described above.

Comment 4

[Larry Eisen]

This should be blocking 1.5 ... rationale: This a regression from 1.4.  Username
and password from the URL were handled in 1.4 (even if it did not allow for a
changed username and/or password from the URL).     

Comment 5

[Matthias Versen [:Matti]]

Please don't set flags if you don't know what they mean.

Comment 6

[Casey Crabb]

Attachment: Version 2 : always cache the credentials sent

This is an updated version of the previous patch. It properly changes the
cached credentials to the URI specified credentials so that subsequent links
are authenticated with the new credentials. Updated comments to match
rationale.

Comment 7

[Darin Fisher]

Attachment: v2.1 patch

slightly revised patch.  fixed up some indentation and comments.

Comment 8

[Darin Fisher]

Comment on attachment 132090 [details] [diff] [review]
v2.1 patch

r=darin

Comment 9

[Darin Fisher]

ok, fixed-on-trunk