Reproduce. Feed NS_NewURI with wild URLs, like <http://###>, <http://())>, <http:%%%%> or <mailto:/@/> (w/o anglebrackets). Actual result: It reports success. Expected result: Failure.
*** Bug 7176 has been marked as a duplicate of this bug. ***
*** Bug 20079 has been marked as a duplicate of this bug. ***
Tever, I heard, gagan were on vacation. Can you reassign to someone appropriate?
Weird corner cases. Low priority.
I know, I will be flooded with flames, if " ---@--- " or so is turned into a mailto link.
In BETA, that is.
You're propably right, but it's a MUST for final.
Bulk move of all Necko (to be deleted component) bugs to new Networking component.
Is now reporting failure in a dialog box for the given urls. What remains is that it finally gives this box for the www.xxx.com version and not for the original xxx, which is a dup of bug 23019.
This bug is not about the browser.
Assignee: gagan → andreas.otte
Assuming "RTM" keyword is for nominating "must be fixed in stable release"-bugs.
One possible solution to this for nsStdURLs could be a matrix much like the escape-matrix in nsURLHelper which says which chars are valid in each part of an URI. Violating the matrix could result in an NS_ERROR_MALFORMED_URI error. SimpleURIs will be more complicated, each uritype will need different rules integrated into each parser.
The above is a first cut on a solution to this bug following the outline mentioned above. It currently only works only for detecting invalid chars in hostnames and it works only for nsStdURL-type URLs. It can be easily extended for other parts of an URL. Want to give it a try Ben?
Okay, the above extended patch also handles mailto urls, but it comes down to what we allow as usernames and/or hostnames/domains.
Comments about mailto parser in bug #32442 "More checks for mailto URLs".
Target Milestone: M15 → M16
Moving to M17 which is now considered part of beta2.
Target Milestone: M16 → M17
The problem with this bug is that we have to deal hostnames like http://www.ökobank.nu. Because of different encodings we end up with http://www.wÃ¶rterbuch.nu/ or http://www.w%F6rterbuch.nu/ . The last one is okay and will be accepted by the check-function, the first one is not. If the url is resolved from a link we get both versions, the last one seems to take effect and it works (on windows). If I type the url into the urlbar we only get the first version which is catched by the check-function. Why this difference? CCing Chris Waterson, who working on something similar before. See bug 31225 or http://www.nunames.nu/eu-lang-test.htm for a list of problem urls.
Opps .. the original url was http://www.wörterbuch.nu.
I don't know. What encoding does the URL bar use? If it's the platform encoding (probably would make the most sense -- allows cut-n'-paste from other apps, right?) then the URL bar code should probably be using that to encode strings before dispatching them to necko. I image what's happening right now is that it's UTF-8 encoding the string. cc'ing ftang, who probably remembers best what 4.x did. cc'ing ben goodger and law who are probably the ones that will need to fix this...
I'm not going anywhere here because of bug 31225, moving to M18 for now.
Target Milestone: M17 → M18
back to gagan for reassignment, my time schedule is getting worse, I have to stop sitting on this bug.
Assignee: andreas.otte → gagan
Status: ASSIGNED → NEW
We're looking painfully silly, if we "recognize" and link http:%%% or a%%%@%%% in TXT->HTML (e.g. Mailnews). If I understood it right, there is a working patch, which just waits for some very freaky i18n issue to be resolved. Can't we just clarify that, and then [adjust and] check in the patch, please?
Adding nsbeta3 keyword to bugs which already have nsbeta3 status markings so the queries don't get all screwed up.
per new rules, not critical for rtm
Whiteboard: [nsbeta3-] → [nsbeta3-][rtm-]
mass move, v2. qa to me.
QA Contact: tever → benc
I wonder, why bug 32442 doesn't block this one yet. Isn't it time to do something for this bug now?
Depends on: 32442
I see in comment 27, from three years ago, that there was 'almost a patch.' /Was/ there almost a patch? Is there still one? Is this bug still a going concern? Granted, it's minor, but there ought to be some filtering for invalid URLs. -M
Severity: normal → minor
I don't think it's minor. Claiming that <http://###> is a valid URI is just nonsense and has visible effects in the plaintext recognizer.
Severity: minor → normal
gagan shouldn't own this bug... Some of this sounds related to bug 140379. You guys know the guts better than I do, but I can justify that bug on more concrete terms
Assignee: gagan → darin
Assignee: darin → nobody
QA Contact: benc → networking
Target Milestone: Future → ---
How easy would this be to implement? Since HTML5 spec. has a smaller set of URIs for mailto: than spec, should this target for RFC 3986 and 3987, or HTML5?
Whiteboard: [nsbeta3-][rtm-] → [nsbeta3-][rtm[necko-would-take]
Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258
Priority: -- → P5
You need to log in before you can comment on or make changes to this bug.