Closed Bug 537381 Opened 15 years ago Closed 14 years ago

-1 as port number cause default port to be used, should fail to load

Categories

(Core :: Networking, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
Tracking Status
blocking2.0 --- final+

People

(Reporter: mayhemer, Assigned: mayhemer)

References

Details

(Whiteboard: [sg:low spoof])

Attachments

(1 file, 2 obsolete files)

This is a leftover from bug 479485 to be fixed.

We should add an is-positive (or even better is > 0) check for the port number.
blocking2.0: --- → ?
Flags: wanted1.9.2?
Flags: blocking1.9.2?
Whiteboard: [sg:low spoof]
blocking2.0: ? → beta1
Flags: wanted1.9.2?
Flags: wanted1.9.2+
Flags: blocking1.9.2?
Flags: blocking1.9.2-
blocking2.0: beta1+ → beta2+
Needs to be fixed before final, don't think it needs to be in a beta, though.
blocking2.0: beta2+ → final+
Attached patch wip 1 (obsolete) — Splinter Review
This is a work in progress patch.  I updated the test and went further and find out, that URL "http://foo.com:1234:80/bar" is correctly parsed and internally represented as "http://foo.com:1234/bar" - the ":80" from the port portion of the URL is read but then ignored.  nsCAutoString::ToInteger is responsible for that.

This is another example where we are completely failing to safely parse a string.  I would like to use something better for parsing here, like lexical analyzer. See [1].

[1] http://groups.google.ca/group/mozilla.dev.platform/browse_thread/thread/47bf5b4cb8203053
We could definitely use some better XPCOM parsing functions.

Note that the DOM no longer uses the ns(C)String::ToInteger gunk, since it just didn't do what the DOM needed.
(In reply to comment #3)
> We could definitely use some better XPCOM parsing functions.
Do you know about any?
The point was we should create some.  We don't have them now.
I'll simply update the patch to check the string is whole just numbers and then use ToInteger on it.  Simple and quick, but also very dirty.
Attached patch v1 (obsolete) — Splinter Review
- checking for only digits in the port string
- checking for positive value
Attachment #472477 - Attachment is obsolete: true
Attachment #474044 - Flags: review?(bzbarsky)
Comment on attachment 474044 [details] [diff] [review]
v1

>+++ b/netwerk/base/src/nsURLParsers.cpp
>+                const char* nondigit = NS_strspnp("0123456789", buf.BeginReading());

.get() please, since you actually want a null-terminated string.

r=me with that
Attachment #474044 - Flags: review?(bzbarsky) → review+
Updated, thanks for review.
Attachment #474044 - Attachment is obsolete: true
Attachment #474362 - Flags: review+
Comment on attachment 474362 [details] [diff] [review]
v1.1 [Check in comment 14]

http://hg.mozilla.org/mozilla-central/rev/8f65173dacb0
Attachment #474362 - Attachment description: v1.1 → v1.1 [Check-in comment 10]
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Depends on: 595525
Status: REOPENED → ASSIGNED
Attachment #474362 - Attachment description: v1.1 [Check-in comment 10] → v1.1 [Back out comment 11]
So, it looks like fixing bug 595525 will take some time, so I'll disable the failing test for now.  The test is nothing critical.
(In reply to comment #12)
> So, it looks like fixing bug 595525 will take some time, so I'll disable the
> failing test for now.  The test is nothing critical.

Taking back... it is not my test that is failing!
Comment on attachment 474362 [details] [diff] [review]
v1.1 [Check in comment 14]

http://hg.mozilla.org/mozilla-central/rev/491c6d05108f
Attachment #474362 - Attachment description: v1.1 [Back out comment 11] → v1.1 [Check in comment 14]
Status: ASSIGNED → RESOLVED
Closed: 14 years ago14 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: