Closed
Bug 1142083
Opened 10 years ago
Closed 9 years ago
IDN Unicode domain redirect is broken in Firefox 36/37/38
Categories
(Core :: Networking: DNS, defect, P1)
Tracking
()
People
(Reporter: kestutis.itsolutions, Assigned: valentin)
References
()
Details
(Keywords: dev-doc-complete, site-compat, Whiteboard: [good first bug])
Attachments
(2 files, 3 obsolete files)
317.60 KB,
image/jpeg
|
Details | |
3.38 KB,
patch
|
mcmanus
:
review+
|
Details | Diff | Splinter Review |
User Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Firefox/38.0
Build ID: 20150311004633
Steps to reproduce:
1. Enter http://zymiausifotografai.lt
2. Believe that should be redirected to http://www.žymiausifotografai.lt/
Actual results:
You get 404 (problem loading page) 'Server not found' error:
Firefox can't find the server at www.%c5%beymiausifotografai.lt.
Expected results:
You should be redirected to http://www.žymiausifotografai.lt/
Appears url do not converts to IDN name:
http://www.xn--ymiausifotografai-wzd.lt
https://iwantmyname.com/domain-tools/idns/idn-punycode-converter?utf8=http%3A%2F%2Fwww.%C5%BEymiausifotografai.lt+&search=convert
It works well in Internet Explorer 11 and Google Chrome newest.
Reporter | ||
Updated•10 years ago
|
Severity: normal → blocker
Points: --- → 13
Priority: -- → P1
Whiteboard: [good first bug]
Reporter | ||
Comment 1•10 years ago
|
||
Bug report.
Reporter | ||
Updated•10 years ago
|
Version: 38 Branch → 36 Branch
Comment 2•10 years ago
|
||
I reproduced this with a local build and was able to fix it by commenting out a NS_EscapeURL call from nsHttpChannel.cpp:
nsresult
nsHttpChannel::AsyncProcessRedirection(uint32_t redirectType)
{
...
// make sure non-ASCII characters in the location header are escaped.
nsAutoCString locationBuf;
if (NS_EscapeURL(location, -1, esc_OnlyNonASCII, locationBuf))
location = locationBuf.get();
Obviously the issue is that the host part of a URI should not be escaped using URL-encoding. That is causing the hostname to be incorrect (having %c5%be, etc.) in the subsequent request.
Does anyone know if this escaping is actually needed? In NewURI(), a nsStandardURL is constructed from the location; does that class handle Unicode URIs already?
Comment 3•10 years ago
|
||
Good catch, both of you. Let me needinfo jduell, and see if he can sort this out.
Flags: needinfo?(jduell.mcbugs)
Comment 4•10 years ago
|
||
This smells like something Valentin ought to know how to fix.
Assignee: nobody → valentin.gosu
Comment 5•9 years ago
|
||
Valentin, any thoughts here? If you don't know we can find someone else.
Flags: needinfo?(jduell.mcbugs) → needinfo?(valentin.gosu)
Assignee | ||
Comment 6•9 years ago
|
||
(In reply to Jason Duell [:jduell] (needinfo? me) from comment #5)
> Valentin, any thoughts here? If you don't know we can find someone else.
Yes, I've been looking into this.
Just commenting NS_EscapeURL triggers an assertion in NSS, so that's probably not good.
This will be fixed by bug 1023468 in which we start doing percent decoding for hostnames (a very requested feature).
Depends on: 1023468
Flags: needinfo?(valentin.gosu)
Assignee | ||
Comment 7•9 years ago
|
||
This is a patch to make sure we don't regress this feature. Once bug 1023468 lands, IDN domain redirect should work.
Assignee | ||
Comment 8•9 years ago
|
||
It might still be a while until we manage to land hostname percent decoding, so this a simple fix just for this one bug
Attachment #8623617 -
Flags: review?(mcmanus)
Assignee | ||
Comment 9•9 years ago
|
||
This test still has a slight problem - my guess is that there is a problem in how httpd.js handles non-ascii headers.
Assignee | ||
Updated•9 years ago
|
Attachment #8622783 -
Attachment is obsolete: true
Updated•9 years ago
|
Attachment #8623617 -
Flags: review?(mcmanus) → review+
Comment 10•9 years ago
|
||
Comment 11•9 years ago
|
||
Status: UNCONFIRMED → RESOLVED
Closed: 9 years ago
status-firefox41:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla41
Assignee | ||
Comment 12•9 years ago
|
||
Attachment #8624913 -
Flags: review?(mcmanus)
Assignee | ||
Updated•9 years ago
|
Attachment #8623623 -
Attachment is obsolete: true
Updated•9 years ago
|
Attachment #8624913 -
Flags: review?(mcmanus) → review+
Assignee | ||
Comment 13•9 years ago
|
||
Awaiting a green inbound in order to land the test.
Keywords: checkin-needed
Comment 14•9 years ago
|
||
Keywords: checkin-needed
Comment 15•9 years ago
|
||
Updated•9 years ago
|
Keywords: dev-doc-needed,
site-compat
Updated•9 years ago
|
Depends on: CVE-2015-7195
Comment 17•9 years ago
|
||
This is now unfixed on beta and aurora as it was backed out elsewhere.
Status: RESOLVED → REOPENED
status-firefox42:
--- → affected
status-firefox43:
--- → affected
Ever confirmed: true
Resolution: FIXED → ---
Updated•9 years ago
|
Flags: needinfo?(valentin.gosu)
Comment 18•9 years ago
|
||
Posted the site compatibility doc for reference: https://www.fxsitecompat.com/en-US/docs/2015/idn-urls-are-not-redirected-properly/
[Tracking Requested - why for this release]: See Comment 17.
Comment 19•9 years ago
|
||
Valentin, tomorrow, we are going to build beta 9. I guess this is going to be hard to get a fix, correct?
Release Note Request (optional, but appreciated)
[Why is this notable]: regression
[Suggested wording]: URLs containing a Unicode-format Internationalized Domain Name (IDN) are not redirected properly, leading to a Server Not Found error.
[Links (documentation, blog post, etc)]:
relnote-firefox:
--- → ?
Updated•9 years ago
|
status-firefox44:
--- → affected
tracking-firefox44:
--- → +
Assignee | ||
Comment 20•9 years ago
|
||
(In reply to Sylvestre Ledru [:sylvestre] from comment #19)
> Valentin, tomorrow, we are going to build beta 9. I guess this is going to
> be hard to get a fix, correct?
The fix will likely be a bit complex, and definitely not suitable for beta.
This was also talked about in bug 439616, but it hadn't reached a conclusion.
I'll try to find a smarter way to fix this.
Flags: needinfo?(valentin.gosu)
See Also: → 439616
Comment 21•9 years ago
|
||
OK, then, firefox 42 is ship with this bug. Please try to provide a fix for fx 43.
Added to the list of know issues in 42.
Assignee | ||
Updated•9 years ago
|
Attachment #8623617 -
Attachment is obsolete: true
Assignee | ||
Comment 22•9 years ago
|
||
Assignee | ||
Comment 23•9 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/18b0d63d9f06d849a8358e5acff33f7fc70250f8
Bug 1142083 - Add test for IDN Unicode domain redirect r=mcmanus
Comment 24•9 years ago
|
||
bugherder |
Status: REOPENED → RESOLVED
Closed: 9 years ago → 9 years ago
status-firefox45:
--- → fixed
Resolution: --- → FIXED
Valentin, does this need to be uplifted to Beta43 and Aurora44?
Flags: needinfo?(valentin.gosu)
Assignee | ||
Comment 26•9 years ago
|
||
The patch contains only the test cases. The actual fix is in bug 412457.
Since this is a fairly large change, and the IDN redirect has been an issue for multiple years, I would rather let it ride the trains.
Flags: needinfo?(valentin.gosu)
(In reply to Valentin Gosu [:valentin] from comment #26)
> The patch contains only the test cases. The actual fix is in bug 412457.
> Since this is a fairly large change, and the IDN redirect has been an issue
> for multiple years, I would rather let it ride the trains.
Thanks Valentin. In that case, we will wontfix this for FF44.
Comment 29•9 years ago
|
||
Wontfix for 43. Sounds like we should also consider adding a release note for the fix for 45.
Flags: needinfo?(sledru)
Comment 30•9 years ago
|
||
Yes, added to the release notes with "URLs containing a Unicode-format Internationalized Domain Name (IDN) are now properly redirected" as wording for 45 (marked as fixed)
Flags: needinfo?(sledru)
You need to log in
before you can comment on or make changes to this bug.
Description
•