19313 - More checks for URIs

Status: RESOLVED DUPLICATE of bug 906714

(Core :: Networking, defect, P5)

Description

[Ben Bucksch (:BenB)]

Reproduce.
Feed NS_NewURI with wild URLs, like <http://###>, <http://())>, <http:%%%%> or
<mailto:/@/> (w/o anglebrackets).
Actual result:
It reports success.
Expected result:
Failure.

Comment 1

[Ben Bucksch (:BenB)]

*** Bug 7176 has been marked as a duplicate of this bug. ***

Comment 2

[Ben Bucksch (:BenB)]

*** Bug 20079 has been marked as a duplicate of this bug. ***

Comment 3

[Ben Bucksch (:BenB)]

Tever, I heard, gagan were on vacation. Can you reassign to someone appropriate?

Comment 4

[Warren Harris]

Weird corner cases. Low priority.

Comment 5

[Ben Bucksch (:BenB)]

I know, I will be flooded with flames, if " ---@--- " or so is turned into a
mailto link.

Comment 6

[Ben Bucksch (:BenB)]

In BETA, that is.

Comment 7

[Ben Bucksch (:BenB)]

You're propably right, but it's a MUST for final.

Comment 8

[leger]

Bulk move of all Necko (to be deleted component) bugs to new Networking

component.

Comment 9

[Andreas Otte]

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.

Comment 10

[Ben Bucksch (:BenB)]

This bug is not about the browser.

Comment 11

[Gagan]

andreas?

Comment 12

[Ben Bucksch (:BenB)]

Assuming "RTM" keyword is for nominating "must be fixed in stable release"-bugs.

Comment 13

[Andreas Otte]

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.

Comment 14

[Andreas Otte]

Attachment: First cut ...

Comment 15

[Andreas Otte]

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?

Comment 16

[Andreas Otte]

Attachment: second cut ...

Comment 17

[Andreas Otte]

Okay, the above extended patch also handles mailto urls, but it comes down to
what we allow as usernames and/or hostnames/domains.

Comment 18

[Ben Bucksch (:BenB)]

Comments about mailto parser in bug #32442 "More checks for mailto URLs".

Comment 19

[Andreas Otte]

-> M16

Comment 20

[Warren Harris]

Moving to M17 which is now considered part of beta2.

Comment 21

[Andreas Otte]

Attachment: current version of check function, host only

Comment 22

[Andreas Otte]

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.

Comment 23

[Andreas Otte]

Opps .. the original url was http://www.wörterbuch.nu.

Comment 24

[Chris Waterson]

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...

Comment 25

[Andreas Otte]

I'm not going anywhere here because of bug 31225, moving to M18 for now. 

Comment 26

[Andreas Otte]

back to gagan for reassignment, my time schedule is getting worse, I have to
stop sitting on this bug.

Comment 27

[Ben Bucksch (:BenB)]

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?

Comment 28

[Daniel Veditz [:dveditz]]

Adding nsbeta3 keyword to bugs which already have nsbeta3 status markings so 
the queries don't get all screwed up.

Comment 29

[Gagan]

per new rules, not critical for rtm

Comment 30

[benc]

mass move, v2.
qa to me.

Comment 31

[Ben Bucksch (:BenB)]

I wonder, why bug 32442 doesn't block this one yet.

Isn't it time to do something for this bug now?

Comment 32

[Max Kanat-Alexander]

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

Comment 33

[Ben Bucksch (:BenB)]

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.

Comment 34

[benc]

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

Comment 36

[John Drinkwater (:beta)]

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?

Comment 37

[Firefox Bug Husbandry Bot]

Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258