101–105 of 105 posts
Earlier quoted context omitted.
> add a robots.txt Which bots will then ignore.
I didn't expect I'd get to use this so soon. Obligatory canned advisory: https://www.felesatra.moe/blog/2026/06/19/robots
Earlier quoted context omitted.
well-known is for programmatic access, it either namespaces something you’re told to look for (e.g. various types of domain markers) or it lets you discover a feature / endpoint. In the latter case you just probe, for instance if you’re a password manager and you have a password for site A you hit A/.well-known/change-password and if they returns something you can surface a change password link to your user. The one…
Thank you, that it is part of OIDC provider discovery spec explains a lot. That said, I still find it very bizzare that it's so hard to find a tangible example to see how it is in practice. The rfc has none. Another spec including the use of it has none. In the end only completed service provider/implementers show it. Before programmatic access happens, it needs to be written by a human. Yet the whole thing feels so…
1. User enters hostname (or comes in from a QR code or TXT record or whatevs)
2. Client requests GET https:///.well-known/
3. This either redirects to the canonical base path of the service, which then can be queried itself for instances, or it directly returns a JSON/XML/whatever array of instances of the service on this server, and their respective base paths
This is a lot better than assuming the service must be the document root (forcing service discrimination into the hostname) or assuming it can always have // as a base path.
"This Web site requires a more modern browser to operate securely; please upgrade your browser." Alternative, no SNI required https://web.archive.org/web/20260619061625if_/https://mnot.n...
https://www.ietf.org/archive/id/draft-stein-tls-ech-consider...