IPv6: PAC: isInNet function needs to support new addressing

NEW
Unassigned

Status

()

P5
normal
18 years ago
a year ago

People

(Reporter: benc, Unassigned)

Tracking

(Blocks: 1 bug, {helpwanted})

Trunk
Future
helpwanted
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [necko-would-take][proxy])

(Reporter)

Description

18 years ago
From bug 58030

------- Additional Comments From timeless@mac.com 2001-01-15 07:55 -------
+"function isInNet(ipaddr, pattern, maskstr) {\n"+
this _definitely_ doesn't look ipv6 friendly. :-(

Possible issues:

1- decision on whether we need a new function call or can make use of the
exsiting paratmeters)
2- support for the actual IPv6 addressing data types.

Comment 1

18 years ago
qa to me. 
QA Contact: tever → benc

Updated

18 years ago
Target Milestone: --- → mozilla0.9.3

Comment 2

18 years ago
-->PAC bugs to Jussi
Assignee: neeti → jpm

Updated

18 years ago
QA Contact: benc → pacqa

Comment 3

18 years ago
Serge, can you take a look at these PAC issues? Thanks - Jussi-Pekka
Assignee: jpm → serge

Comment 4

18 years ago
Doesn't look like this is getting fixed before the freeze tonight.
Pushing out a milestone.  Please correct if I'm mistaken.
Target Milestone: mozilla0.9.3 → mozilla0.9.4

Comment 5

17 years ago
this is an enhancement, removing TM.
Target Milestone: mozilla0.9.4 → ---

Updated

17 years ago
Blocks: 79893

Updated

17 years ago
Blocks: 136898

Comment 6

17 years ago
moving to future, enhancement requests will be reviewed at a later date
Status: NEW → ASSIGNED
Priority: -- → P5
Summary: IPv6 + PAC: isInNet function needs to support new addressing → [RFE]IPv6 + PAC: isInNet function needs to support new addressing
Target Milestone: --- → Future

Updated

17 years ago
Severity: enhancement → normal

Comment 7

16 years ago
I respectfully request that the status of this bug be reconsidered.  I believe
that it is a full-fledged bug, not a request for enhancement.

I am currently running Mozilla 1.1a on Tru64 UNIX V5.1B.  Mozilla is intended to
be my primary browser on my workstation.  However, this bug is preventing my
proxy configuration from working, forcing me to constantly diddle with the proxy
configuration myself or fall back to Netscape Navigator 4.7x.

It took me a long time to identify the issue, but eventually I was able to
determine that dnsResolve(hostname) was returning an IP address in the format
"::ffff:15.1.2.3".  This breaks isInNet, since convert_addr is splitting on ".",
and the first part thus becomes "::ffff:15", not a valid integer.  As a result,
isInNet() incorrectly returns false.

Note that this is not an issue on Netscape Navigator 4.7x.  Thus, this behavior
is a regression from previous behavior.  It is currently inhibiting my ability
to use Mozilla.

I would respectfully request that if the owner of this bug disagrees with my
assessment, that he say so, so that at least I know that my comments have been
addressed.  I will wait for the owners response, instead of changing the status
of the bug myself (which would probably be annoying for the owner).

Thank you.
(Reporter)

Comment 8

16 years ago
4xp.
putting into the triage queue w/ helpwanted.
Assignee: serge → new-network-bugs
Status: ASSIGNED → NEW
Keywords: 4xp, helpwanted
QA Contact: pacqa → benc

Updated

16 years ago
Target Milestone: Future → ---

Comment 9

16 years ago
future
Target Milestone: --- → Future

Comment 10

16 years ago
[RFE] is deprecated in favor of severity: enhancement.  They have the same meaning.
Severity: normal → enhancement

Updated

16 years ago
Summary: [RFE]IPv6 + PAC: isInNet function needs to support new addressing → IPv6 + PAC: isInNet function needs to support new addressing

Comment 11

16 years ago
I'm sorry, but I'm still wondering why this is a RFE/enhancement bug.  I believe
it to be a bug in isInNet that is forcing me to revert to NN4 in some cases.

Comment 12

16 years ago
okay.
Severity: enhancement → normal

Comment 13

16 years ago
There is no explict support for IPv6 in the original specs. This is  "4xp", so
the fact that Comm somewhat does this correctly (and that this is to some degree
a product-level regresssion) is marked w/ that keyword.

Updated

15 years ago
Blocks: 223403

Updated

15 years ago
Summary: IPv6 + PAC: isInNet function needs to support new addressing → IPv6 + PAC2: isInNet function needs to support new addressing

Comment 15

15 years ago
bobbell: 

I think Darin fixed the function so that it would stop breaking isInNet (it now
only returns IPv4 addresses).

Please let me know if this is fixed, if so, mark this RESOLVED/FIXED.
No longer blocks: 223403
Depends on: 191715
Summary: IPv6 + PAC2: isInNet function needs to support new addressing → IPv6: PAC: isInNet function needs to support new addressing

Comment 16

15 years ago
I personally haven't seen this recently.  I think my configuration changed, but
I'd say to go ahead and mark this FIXED.  I can't do so because I'm not the
submitter.

Comment 17

11 years ago
This is still not really fixed.  isInNet should fully support IPv6 addresses or some new function should be added which does.  IMHO, the use of 'mask' is pretty IPv6 unfriendly.  Prefixes (i.e. addr/bits ala 192.168.43.0/24) is better suited for both IPv4 and IPv6.

Comment 18

9 years ago
As noted in Bug 242352, MS has already introduced additions for IPv6:

http://blogs.msdn.com/wndp/archive/2006/07/18/IPV6_WPAD_for_WinHttp_and_WinInet.aspx
Whiteboard: [necko-would-take]

Updated

2 years ago
Whiteboard: [necko-would-take] → [necko-would-take][proxy]
You need to log in before you can comment on or make changes to this bug.