W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2018

How to handle an IPv6 link-local address in the response Location header?

From: Wèi Cōngruì <crvv.mail@gmail.com>
Date: Fri, 26 Jan 2018 07:01:14 +0000
Message-Id: <CAPxZtjHf29s-b8M68uAcphpznbqBhjgfw0EYZHi__0DitE-i6Q@mail.gmail.com>
To: ietf-http-wg@w3.org
Hello,

I think the behavior is undefined and this is an uncommon scenario.

A client sends a request "http://[fe80::1%lo0]/" and gets a response like

 HTTP/1.1 302 Found
 Location: http://[fe80::1]/moved

The client wants to follow the redirection but the second request may fail
because this isn't a zone ID in the Location header.
The error will be "No route to host".

Zone ID is removed from the outgoing request as per RFC 6874,
so the server can't response a Location with zone ID.

I investigated some HTTP implementations and
there are some different behaviors.

Java selects a default zone for the request and the request will success.

cURL uses a key without zone ID to cache TCP connections,
so the second request uses the previous TCP connection and it will success.

Go and Python doesn't handle this and can't follow a redirection
to "http://[fe80::1]/moved".

There are other choices. The client can use the zone ID from the first
request for the second request. But I am reluctant to do this without
support from HTTP spec.

Or this can be ignored intentionally and make it fail.

I am working on fixing a Go issue(https://github.com/golang/go/issues/20669 <https://github.com/golang/go/issues/20669>)
and not sure which behavior should I choose and want some advices.

Thanks.

Best,
Wèi Cōngruì
Received on Monday, 29 January 2018 06:13:20 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 January 2018 06:13:26 UTC