net/http: get for literal ipv6 address url doesn't follow redirection on ipv6-only transport environment

[mikioh]

theoretically the root cause must be golang.org/issue/8453, but file a separate issue
for safety. for now workaround would be having a custom transport like the following:

tr := &http.Transport{
        Dial: (&net.Dialer{DualStack: true}).Dial,
}
client := http.Client{Transport: tr}
resp, err := client.Get(fmt.Sprintf("http://[2404:6800:4004:802::1011]:80/")

[bradfitz]

Comment 1:

I have no clue what this bug is trying to say.
In particular, what is "or some ipv6 transition mech enabled environment"?
Please write a complete description with examples.

Owner changed to @mikioh.

Status changed to WaitingForReply.

[mikioh]

Comment 2:

when we run attached on ipv6 enabled, ipv6-only transport environment, we will have
network is unreachable error because of issue #8453.
fetch from www.google.com, 2404:6800:4004:807::1013 failed: Get http://www.google.com/:
dial tcp 74.125.235.83:80: network is unreachable
because, when the server returns 301 or 302 and the response contains non-literal ip
address location,  current net.Dial variants prefer ipv4 transport unconditionally and
never attempts other a/aaaa records as described in issue #8453.
> what is "or some ipv6 transition mech enabled environment"?
never mind, i misconfigured dns64+a/aaaa filter.

Attachments:

1. http.go (882 bytes)

[mikioh]

Comment 3:

Status changed to New.

Attachments:

1. http.go (800 bytes)

[mikioh]

Comment 4:

fwiw,
> what is "or some ipv6 transition mech enabled environment"?
i mean, a environment which is deployed either ipv4-ipv6 translation techniques such as
nat64/xlat464/ds-lite/map-t or ipv4-ipv6 tunnelling techniques such as 6rd/4rd/map-e. in
any case control plane bridging stuff btw web and ip, dns and/or dns64, is pretty
important.

[griesemer]

Comment 5:

Labels changed: added repo-main.

[rsc]

Not sure what the status is here, but Brad, Mikio replied to your questions.

[mikioh]

#8453 will fix this together, but please keep this open for now. Perhaps we need a test case that runs http.Get/http.Client.Get for www.google.com over only IPv6 transport.

[gopherbot]

CL https://golang.org/cl/8768 mentions this issue.