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

Hi,

This is one known problem with RFC 6874, which explicitly forbids passing the client's zone ID to the server and effectively makes it impossible to use IPv6 link local URIs for any HTTP-based service that needs to return or redirect to absolute URIs (potentially with different URI schemes).

IPP (and CUPS) have long used the original IPv6 link local URI syntax (that was dropped after the URI WG dissolved) which did not have this restriction and used "+" as the zone delimiter in order to retain compatibility with RFC 3986/STD 66 (URI spec).  Sadly, the 6man WG decided not to preserve any of this, so we've had to issue separate guidance to IPP implementors that conflicts with RFC 6874.

The other method suggested by the 6man WG is to "remember" the zone ID used in the original request - that doesn't scale too well but is probably the best approach for handling simple redirections.


> On Jan 26, 2018, at 2:01 AM, Wèi Cōngruì <crvv.mail@gmail.com> wrote:
> 
> 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)
> and not sure which behavior should I choose and want some advices.
> 
> Thanks.
> 
> Best,
> Wèi Cōngruì

_________________________________________________________
Michael Sweet, Senior Printing System Engineer

Received on Monday, 29 January 2018 19:08:39 UTC