Hi Bruno,
Wow, I've been working in this area for more than a decade, and this is
the first bug I've seen on the HttpURLConnection when using URL's with
literal IPv6 addresses.
That said, I think your points are valid. I created the following bug to
track this issue:
https://bugs.openjdk.java.net/browse/JDK-8027308
We just past ZBB [1] for JDK8, so I'm not sure that a fix for this issue
will make JDK8 FCS, but I would suspect that the changes would be
suitable for an Update release, 7uXX or 8uXX for example.
-Chris.
[1] http://openjdk.java.net/projects/jdk8/milestones#Zero_Bug_Bounce
On 25/10/2013 02:38, Bruno Harbulot wrote:
Hello,
I've been trying to use HttpURLConnection to connect to a web server
using its IPv6 link-local address.
There are two issues with this:
- HttpURLConnection work with URLs with the official % syntax (only the
informal one) for the scope ID (normally required for link-local addresses).
Indeed, http://[fe80::a00:27ff:aaaa:aaaa%eth0]/ (for example) can be
used to send a request, but http://[fe80::a00:27ff:aaaa:aaaa%25eth0]/
will not send a request at all ("java.net.SocketException: Network is
unreachable...").
The difference is in the encoding of % (which separates the actual IP
address from the scope ID).
RFC 6874 (Section 2) says, "According to URI syntax [RFC3986], "%" is
always treated as an escape character in a URI, so, according to the
established URI syntax [RFC3986] any occurrences of literal "%" symbols
in a URI MUST be percent-encoded and represented in the form "%25"."
- HttpURLConnection sends the scope ID in the Host header, i.e. "Host:
[fe80::a00:27ff:aaaa:aaaa%eth0]" instead of "Host:
[fe80::a00:27ff:aaaa:aaaa]".
Unfortunately, this doesn't seem to be allowed by RFC 4007, and this
causes Apache Httpd to return a 400 error status.
(There are more details in this Apache Httpd issue:
https://issues.apache.org/bugzilla/show_bug.cgi?id=35122#c4 )
The only workaround I've found was to set the Host header manually,
but this also requires enabling "sun.net.http.allowRestrictedHeaders".
These problems are present in the latest Java 7 release and in the Java
8 early release.
I'm not sure if this has already been reported or discussed. If not,
would it be possible to address it in future releases?
Best wishes,
Bruno.
