That breaks significant assumptions of the WWW. Specifically, it means that devices have different addresses when accessed by different hosts, which breaks all hyperlinks the Server may send back, unless the User Agent also sends the scope ID to the Server. However, the scope ID is meant to be meaningful only in the context of the host that originated it, so RFC6874, which introduced this concept officially in URLs, prohibits sending it.

Overall, this means that, in practice, WWW on IPv6 does not support link-local addresses. This is especially true given that none of the major browsers support them.

On POSIX systems (including MacOS), just 'fe80::1' doesn't work. You need something like fe80::1%eth0. The 'eth0' is in general unknown, because it is the name of the outgoing interface, which varies from OS to OS and even between Linux distributions.

Then in URLs you have the question whether it is 'http://[fe80::1%eth0]' or 'http://[fe80::1%25eth0]' ('%'s escaping). And by and large browsers have decided that the whole '%eth0' is complex from a security point of view, so they don't support it.

In some cases Windows does allow just a 'fe80::1'. But I don't know under what circumstances.

The URL you have in parentheses with a zone name is not supported by Chrome:

https://bugs.chromium.org/p/chromium/issues/detail?id=70762

In general, zone support is spotty. Many networking libraries do not handle it at all.

Sounds like Chrome is broken.

It's not supported in any browser, so good luck using it on the web. Even more, the semantics for such a URL as defined by RFC6784 means that common HTTP features like redirects can't work: client sends a request to http://[fe80::6%7], the User Agent sends a request to server with "Host: http://[fe80::6]", and receieves a 302 response with "Location: https://[fe80::6]" . What can client do next?