IndieAuth spec: may/should/must (or not?) canonicalize "www." (lack thereof)

[tantek]

May/should/must (or not) an IndieAuth implementation canonicalize "www." in front of a domain name, remove it, equate it with it not being there?

Worthy of at least an informative FAQ or best practices guidance based on existing implementations and experience.

[Zegnat]

Currently www.indieauth.net and indieauth.net do not even resolve to the same website. I don’t think the spec should make any assumptions as to whether the www. subdomain is required or not. This could probably lead to unforeseen problems in the future.

What might be interesting is whether www.example.com and example.com count as “the same domain” for profile URL purposes. E.g. if I login with www.example.com and on the verification step the endpoint tells the client that the canonical profile URL (me property in the response) is example.com, should the client accept this? As written the answer is probably no. But in actual use I might tend towards yes…

[aaronpk]

I would not want to make any assumptions about www and no-www being the same identity URL. However there is probably a note we could add about how to handle the case where the user enters www.example.com and it actually is a 301 redirect to example.com, so clients should use the end URL as the identity URL. Need to figure out how to phrase that.

[Zegnat]

Need to figure out how to phrase that.

Hmm… Maybe specify that a User Profile URL MUST be a resolvable URL, and for URL Canonicalization that the client MUST resolve the specified URL by following permanent redirects (the Location fields of HTTP 301 and 308 responses)?

[aaronpk]

It turns out that due to the security requirements of limiting clients accepting resulting me URLs to matching domains as what the user entered, there is an important step clients must do with regards to following redirects of what the user enters. I added some text to describe this, as well as a bunch of examples.

https://indieauth.net/spec/#redirect-examples

[Zegnat]

@aaronpk was there a reason for only documenting behaviour specifically for HTTP 301 and 302, and not 307 and 308?

[aaronpk]

HTTP 307 and 308 indicate that the client should use the same HTTP method when making the request to the new location. e.g. if a client POSTs to a form and gets back a 307, it should POST the same data to the new location. Whereas if browsers get back a 302 when POSTing a form, they'll redirect to the new location and make a GET request. Since IndieAuth only deals with GET requests when discovering and resolving these URLs, 307/308 don't really apply.