You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The spec describes "inserting "/.well-known/" and the well-known URI suffix between the host component and the path component". I know why you're specifying that, and indeed, the reasons are discussed in the Compatibility Notes section at https://www.rfc-editor.org/rfc/rfc8414.html#section-5 . However, in practice, in multitenant systems, while the tenant will likely have write access to https://example.com// and can put a .well-known resource there, it likely will not have write access to https://example.com/ and so cannot put a .well-known resource there.
At a minimum, I'd describe the problem and say that, in practice, most implementations using paths will need to put the .well-known resource at the end of the path,.
P.S. There's a chance that Mark Nottingham and will update the .well-known RFC to explicitly allow this. I plan to talk to him about it at IETF in London next week.
The text was updated successfully, but these errors were encountered:
The spec describes "inserting "/.well-known/" and the well-known URI suffix between the host component and the path component". I know why you're specifying that, and indeed, the reasons are discussed in the Compatibility Notes section at https://www.rfc-editor.org/rfc/rfc8414.html#section-5 . However, in practice, in multitenant systems, while the tenant will likely have write access to https://example.com// and can put a .well-known resource there, it likely will not have write access to https://example.com/ and so cannot put a .well-known resource there.
At a minimum, I'd describe the problem and say that, in practice, most implementations using paths will need to put the .well-known resource at the end of the path,.
P.S. There's a chance that Mark Nottingham and will update the .well-known RFC to explicitly allow this. I plan to talk to him about it at IETF in London next week.
The text was updated successfully, but these errors were encountered: