Closed
Bug 240754
Opened 21 years ago
Closed 21 years ago
Escape dots in the username and password when canonicalizing URIs
Categories
(Core :: Networking, defect)
Core
Networking
Tracking
()
RESOLVED
FIXED
mozilla1.7final
People
(Reporter: darin.moz, Assigned: darin.moz)
References
()
Details
(Keywords: fixed1.7)
Attachments
(1 file)
1.73 KB,
patch
|
dougt
:
review+
dveditz
:
superreview+
asa
:
approval1.7+
|
Details | Diff | Splinter Review |
Escape the username and password when canonicalizing URIs
This bug is about implementing option 2d from jruderman's proposal here:
http://bugzilla.mozilla.org/show_bug.cgi?id=122445#c68
Assignee | ||
Comment 1•21 years ago
|
||
ok, this patch makes it so that we always escape '.' when it appears in either
the username or password portion of a URI.
Assignee | ||
Updated•21 years ago
|
Attachment #146324 -
Flags: superreview?(dveditz+bmo)
Attachment #146324 -
Flags: review?(dougt)
Assignee | ||
Updated•21 years ago
|
Severity: normal → major
Status: NEW → ASSIGNED
Flags: blocking1.7?
Target Milestone: --- → mozilla1.7final
Comment 2•21 years ago
|
||
Comment on attachment 146324 [details] [diff] [review]
v1 patch
sr=dveditz
Attachment #146324 -
Flags: superreview?(dveditz) → superreview+
Updated•21 years ago
|
Attachment #146324 -
Flags: review?(dougt) → review+
Does this affect the diplay of URL's in various places where we call unescape? I
think status bar and bookmarks do that...
Assignee | ||
Updated•21 years ago
|
Attachment #146324 -
Flags: approval1.7?
Assignee | ||
Updated•21 years ago
|
Summary: Escape the username and password when canonicalizing URIs → Escape dots in the username and password when canonicalizing URIs
Assignee | ||
Comment 4•21 years ago
|
||
> Does this affect the diplay of URL's in various places where we call unescape? I
> think status bar and bookmarks do that...
no, places that unescape before showing a username and password would be
unaffected. in those cases, we need another solution. this patch just helps
whenever a raw URI is shown.
Assignee | ||
Comment 5•21 years ago
|
||
actually, there are two functions on nsITextToSubURI that are used to unescape
URIs and URI segments for display in the UI: unEscapeURIForUI, and
unEscapeNonAsciiURI. if unEscapeNonAsciiURI is used, then dots will remain
escaped. unEscapeNonAsciiURI is intended to help in cases where the escaped
non-ASCII text is best displayed as localized text. it looks like
unEscapeNonAsciiURI is not used much.
Assignee | ||
Comment 6•21 years ago
|
||
fixed-on-trunk for 1.8 alpha
Status: ASSIGNED → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
Comment 7•21 years ago
|
||
Comment on attachment 146324 [details] [diff] [review]
v1 patch
a=asa (on behalf of drivers) for checkin to 1.7
Attachment #146324 -
Flags: approval1.7? → approval1.7+
Assignee | ||
Comment 8•21 years ago
|
||
fixed1.7
i went ahead and checked this patch in on the trunk even though it is going to
be overwritten by dveditz's patch for bug 157354. i figure this way he doesn't
have to deal with a separate patch for the trunk and 1.7 branch.
Keywords: fixed1.7
Updated•21 years ago
|
Flags: blocking1.7?
Darin:
Should I bother to test for this, or is it completely over-written by the other
bug fix?
Assignee | ||
Comment 10•20 years ago
|
||
> Should I bother to test for this, or is it completely over-written by the other
> bug fix?
no need, i think. however, this patch would still be exercised in other places
where URIs may be shown to the user.
You need to log in
before you can comment on or make changes to this bug.
Description
•