Recently support for RFC 2732 style IPv6 addresses was
added to the proxy option, but a non-proxy address
remains broken.
Also, it seems zone IDs are not properly parsed..
Bad zone parsing:
curl -x 'http://[fe80::2e0:81ff:fe28:d04c%eth2]:8080/'
http://moo/
curl: (5) Couldn't resolve proxy 'fe80'
No 2732 parsing on addreses:
curl -6 'http://[fe80::2e0:81ff:fe28:d04c]:8080/'
curl: (3) [globbing] illegal pattern or range
specification after pos 9
curl -V
curl 7.15.0 (i686-pc-linux-gnu) libcurl/7.15.0
OpenSSL/0.9.7e zlib/1.2.2 libidn/0.5.13
Protocols: tftp ftp gopher telnet dict ldap http file
https ftps
Features: IDN IPv6 Largefile NTLM SSL libz
It doesn't seem clear what the correct format is for a
zone ID in a URI should be WRT to escaping the %, but
at least firefox 1.0.4 requires the % be unescaped..
Logged In: YES
user_id=1110
The second case works if you disable "globbing" with -g.
Logged In: YES
user_id=1110
Where is that "%eth2" thing defined?
It is not mentioned in RFC2732 (AFAICS) and not in RFC2373
(which RFC2732 refers to in regard how the literal string
should look like between the brackets).
So, I would say that it seems curl _is_ RFC2732 compliant
but we might need to extend its compliance to some other
spec that defines the "%ethN" suffix.
Logged In: YES
user_id=236775
Note the second part of the bug report: curl doesn't seem to
handle numeric-format IPv6 addresses in the URL, even
without a zone ID. I just tried it myself with the same results.
Logged In: YES
user_id=1110
Yes, it fails with IPv6 numericals if -g isn't used.
Logged In: YES
user_id=236775
Sorry, missed your response about -g. That means that you
can't use the globbing feature at all with IPv6 numeric
hosts, which seems like an unfortunate workaround.
Logged In: YES
user_id=236775
I ran across this Internet-Draft that discusses the issue:
http://www.ietf.org/internet-drafts/draft-fenner-literal-zone-02.txt
It specifies the use of a plus sign instead of a percent
when specifying zone IDs in URLs to get around the problem
of percent signs being special.
Logged In: YES
user_id=1110
Ok, I consider this a low priority issue. If it bothers
someone bad enough, I'm sure that someone can make a patch
and send it to us.
If not, I'll just add this to the known bugs document in a
while and close this report.
Logged In: YES
user_id=1110
Added to the KNOWN_BUGS document
Why was this bug closed? curl 7.15.5 still doesn't provide a way to specify a zone id, contrary to documentation.
The documentation states (http://curl.linux-mirror.org/docs/manual.html )
Link local and site local addresses including a scope identifier, such as fe80::1234%1,
may also be used, but the scope portion must be numeric and the percent
character must be URL escaped.
However, this doesn't appear to work:
$ curl -g 'http://[fe80::215:c5ff:fef0:5af8%252]:9011/'
curl: (6) Couldn't resolve host '[fe80::215:c5ff:fef0:5af8%252]'
That's what should work based on the documentation.
The following variants don't work, either:
$ curl -g 'http://[fe80::215:c5ff:fef0:5af8%2]:9011/'
curl: (6) Couldn't resolve host '[fe80::215:c5ff:fef0:5af8%2]'
$ curl -g 'http://[fe80::215:c5ff:fef0:5af8%25eth0]:9011/'
curl: (6) Couldn't resolve host '[fe80::215:c5ff:fef0:5af8%25eth0]'
$ curl -g 'http://[fe80::215:c5ff:fef0:5af8%eth0]:9011/'
curl: (6) Couldn't resolve host '[fe80::215:c5ff:fef0:5af8%eth0]'
$ curl -g 'http://[fe80::215:c5ff:fef0:5af8+eth0]:9011/'
curl: (6) Couldn't resolve host '[fe80::215:c5ff:fef0:5af8+eth0]'
$ curl -g 'http://[fe80::215:c5ff:fef0:5af8+2]:9011/'
curl: (6) Couldn't resolve host '[fe80::215:c5ff:fef0:5af8+2]'
By comparison, 'ssh fe80::215:c5ff:fef0:5af8%2' and 'ssh fe80::215:c5ff:fef0:5af8%eth0' both work.
Can you clarify why this has remained a 'known bug' for so long - it makes it impossible to try out http over IPv6 in environments without site-local or global IPv6 addresses.
Thanks.
1 - curl 7.15.5 is VERY old and contains a LARGE number of bugs.
2 - you refer to a document to a site we don't run, control or appreciate
3 - we primarily make sure the docs for the current version is accurate, ancient versions we can't really bother about
4 - it was closed because nobody bothered about it and we instead mention in the KNOWN_BUGS file
5 - it remains in the KNOWN_BUGS document until someone fixes it. Fixes are not done by magic, someone actually has to step forward and do it. People tend to scratch their itches and I guess very few suffer from this itch.
6 - this issue is closed, if you really care about this feature you upgrade to 7.19.7 now, try that and if it still fails somehow, bring the issue to the mailing list and be prepared to do some of the work yourself.