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