583170 - Handling IPv6 literal address differently to other browsers.

Status: RESOLVED FIXED

(Core :: Networking, defect)

Description

[alick.buckley]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US) AppleWebKit/534.3 (KHTML, like Gecko) Chrome/6.0.472.11 Safari/534.3
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-AU; rv:1.9.2.8) Gecko/20100722 Firefox/3.6.8

When using a IPv6 literal address, for example
http://[de67::314:5fff:fe52:83e0]:4555/test.html
The document.domain and location.hostname are missing the [ ] brackets.
Opera, Chrome and Safari have [] brackets.
IE8 has [] brackets for the document.domain and no brackets for the location.hostname

alert ( document.domain ) ;
alert ( window.location.hostname ) ;


Reproducible: Always

Steps to Reproduce:
1. Create simple HTML page
2. Include alert ( document.domain ) ;
3. Include alert ( window.location.hostname ) ;
4. Load the page using IPv6 literal address
http://[de67::314:5fff:fe52:83e0]:4555/test.html
Actual Results:  
de67::314:5fff:fe52:83e0
de67::314:5fff:fe52:83e0


Expected Results:  
[de67::314:5fff:fe52:83e0]
[de67::314:5fff:fe52:83e0]


Also consider the scenario where some JavaScript might use the
document.domain = document.domain call to loose the same origin policy for cross port access. IE 8 does not handle this document.domain = document.domain for IPv6 literal domain.

Comment 1

[Patrick McManus [:mcmanus]]

is tihs already FIXED?

Comment 2

[Valentin Gosu [:valentin] (he/him)]

window.location.hostname works correctly, but document.domain is still missing the brackets.

Comment 3

[Valentin Gosu [:valentin] (he/him)]

Attachment: Handling IPv6 literal address differently to other browsers

Comment 4

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 8716531 [details] [diff] [review]
Handling IPv6 literal address differently to other browsers

r=me, but please check to make sure the spec defines this behavior (and file spec bugs if not), and add a web platform test if possible...

Comment 5

[Valentin Gosu [:valentin] (he/him)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/79c33b6de3d80802d00282f8c897ce7c93b194ea
Bug 583170 - Handling IPv6 literal address differently to other browsers r=bz

Comment 6

[Valentin Gosu [:valentin] (he/him)]

(In reply to Boris Zbarsky [:bz] from comment #4)

> r=me, but please check to make sure the spec defines this behavior (and file
> spec bugs if not),
https://html.spec.whatwg.org/multipage/browsers.html#relaxing-the-same-origin-restriction

> and add a web platform test if possible...
It seems difficult to add a test for this that works both locally and online (especially since w3c-test.org doesn't have an IPv6 address), but I'll give it a shot.
Filed web-platform test bug: https://github.com/w3c/web-platform-tests/issues/2570

Comment 7

[Boris Zbarsky [:bzbarsky]]

> https://html.spec.whatwg.org/multipage/browsers.html#relaxing-the-same-origin-restriction

Right, what this spec says is:

  The domain attribute on Document objects must be initialised to the document's
  domain, if it has one, and the empty string otherwise. If the document's domain
  starts with a U+005B LEFT SQUARE BRACKET character ([) and ends with a
  U+005D RIGHT SQUARE BRACKET character (]), it is an IPv6 address;
  these square brackets must be omitted when initialising the attribute's value.

and the getter is defined as:

  On getting, the attribute must return its current value

So per current spec, document.domain should return a string _without_ the square brackets.  Which is why we need a spec bug, which you should file.

Things get even worse when setting document.domain, afaict (e.g. is the input expected to include the [] or not, when it's exactly compared to the current value); sorting this out should be part of the spec bug.

Comment 8

[Valentin Gosu [:valentin] (he/him)]

(In reply to Boris Zbarsky [:bz] from comment #7)
> > https://html.spec.whatwg.org/multipage/browsers.html#relaxing-the-same-origin-restriction
> 
> Right, what this spec says is:
> 
>   The domain attribute on Document objects must be initialised to the
> document's
>   domain, if it has one, and the empty string otherwise. If the document's
> domain
>   starts with a U+005B LEFT SQUARE BRACKET character ([) and ends with a
>   U+005D RIGHT SQUARE BRACKET character (]), it is an IPv6 address;

I initially read this part to be referring to the getter, and the fact that an IPv6 address would be enclosed in brackets.

>   these square brackets must be omitted when initialising the attribute's
> value.

And that the setter should omit the brackets for an IPv6 address.
> 
> and the getter is defined as:
> 
>   On getting, the attribute must return its current value
> 
> So per current spec, document.domain should return a string _without_ the
> square brackets.  Which is why we need a spec bug, which you should file.

I filed a spec bug: https://github.com/whatwg/html/issues/670

Comment 9

[Boris Zbarsky [:bzbarsky]]

> I initially read this part to be referring to the getter

Uh... it's just talking about the internal attribute value.

> And that the setter should omit the brackets for an IPv6 address.

This is talking about initializing the internal value, not the setter.  The setter is way lower.

I just realized I have a question about the spec that landed here, also.  Does it handle `document.domain = document.domain` on an IPv6 page correctly (i.e. without throwing)?  It seems like it might now that we include the square brackets, but was this tested?

Comment 10

[Valentin Gosu [:valentin] (he/him)]

(In reply to Boris Zbarsky [:bz] from comment #9)
> Does it handle `document.domain = document.domain` on an IPv6 page correctly
> (i.e. without throwing)?  It seems like it might now that we include the
> square brackets, but was this tested?

Yes, it works without throwing.

Comment 11

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/79c33b6de3d8