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


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( <>)
and not sure which behavior should I choose and want some advices.


Wèi Cōngruì

Received on Monday, 29 January 2018 06:13:20 UTC