Menu

#555 IPv6 RFC 2732 addrs are not fully supported

closed-accepted
http (206)
2
2015-01-10
2005-12-01
Anonymous
No

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..

Discussion

  • Daniel Stenberg

    Daniel Stenberg - 2005-12-01

    Logged In: YES
    user_id=1110

    The second case works if you disable "globbing" with -g.

     
  • Daniel Stenberg

    Daniel Stenberg - 2005-12-01
    • status: open --> open-accepted
     
  • Daniel Stenberg

    Daniel Stenberg - 2005-12-01

    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.

     
  • Dan Fandrich

    Dan Fandrich - 2005-12-01

    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.

     
  • Daniel Stenberg

    Daniel Stenberg - 2005-12-01

    Logged In: YES
    user_id=1110

    Yes, it fails with IPv6 numericals if -g isn't used.

     
  • Dan Fandrich

    Dan Fandrich - 2005-12-01

    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.

     
  • Dan Fandrich

    Dan Fandrich - 2005-12-02

    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.

     
  • Daniel Stenberg

    Daniel Stenberg - 2005-12-05

    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.

     
  • Daniel Stenberg

    Daniel Stenberg - 2005-12-05
    • priority: 5 --> 2
     
  • Daniel Stenberg

    Daniel Stenberg - 2005-12-12
    • status: open-accepted --> closed-accepted
     
  • Daniel Stenberg

    Daniel Stenberg - 2005-12-12

    Logged In: YES
    user_id=1110

    Added to the KNOWN_BUGS document

     
  • Godmar Back

    Godmar Back - 2009-12-08

    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.

     
  • Daniel Stenberg

    Daniel Stenberg - 2009-12-08

    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.