[wp-trac] [WordPress Trac] #15936: IPv6 literal support in multisite broken

[WordPress Trac]

#15936: IPv6 literal support in multisite broken
--------------------------------------+-------------------------
 Reporter:  jmdh                      |       Owner:  jeremyfelt
     Type:  enhancement               |      Status:  accepted
 Priority:  normal                    |   Milestone:  5.4
Component:  Networks and Sites        |     Version:  3.0
 Severity:  major                     |  Resolution:
 Keywords:  has-patch has-unit-tests  |     Focuses:  multisite
--------------------------------------+-------------------------

Comment (by jeremyfelt):

 Replying to [comment:47 emaildano]:
 > I just want to clarify the term "IPv6 literal". Would that account for
 this example?
 >
 > `2001:0db8:85a3:0000:0000:8a2e:0370:7334`

 Good call on the clarification. We've been talking a lot about port
 numbers, but that's a side effect of supporting IPv6. From that RFC
 amendment, the following should be valid:

 {{{
 http://[FEDC:BA98:7654:3210:FEDC:BA98:7654:3210]:80/index.html
 http://[1080:0:0:0:8:800:200C:417A]/index.html
 http://[3ffe:2a00:100:7031::1]
 http://[1080::8:800:200C:417A]/foo
 http://[::192.9.5.5]/ipng
 http://[::FFFF:129.144.52.38]:80/index.html
 http://[2010:836B:4179::836B:4179]
 }}}

 Would it make sense to split port handling and IPv6 handling into two
 separate tickets? We have closed things like #42993 as duplicates, but the
 handling is probably different enough.

 * To support ports, we need to allow `:` once in the domain (excluding
 anything in `[]`)
 * For IPv6, we need to allow multiple `:` within `[]`
 * We can use `Requests_IPv6::check_ipv6()` to actually validate the format
 of the IPv6 address.

 I've added a few extra test conditions in [attachment:"15936.5.diff"] to
 help show what I think is expected once this is all done.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/15936#comment:48>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform