4 ms·

Right, which is why putting this file under .well-known is a small inconvenience. It's increasingly common for server configurations to have a reverse proxy ro

Right, which is why putting this file under .well-known is a small inconvenience. It's increasingly common for server configurations to have a reverse proxy routing requests to internal containers or servers. Things like SSL renewals are often handled by the reverse proxy (because reasons [1]), so those requests don't get routed to the internal hosts by default. Site-specific stuff, like this file, probably belongs in the site's root directory. This is a bit bike-shedding though. It's only a small aggravation to work around. [1]: Because you want to automate as much of the configuration as possible, so when a new hostname is added to a container or internal server, an SSL certificate just magically happens for it. This requires changes to the reverse proxy's configuration, and that's not something you want the internal containers doing, so it falls to the proxy to handle these itself. Letting the containers handle their own SSL setup means you have to have some kind of privileged communications channel from the container up to the reverse proxy, which is undesirable.

remram 6y ago
The problem is when there starts to be many "site-specific stuff". It's easy to remember not to route .well-known to user-generated content in your app. It's less easy to remember a list of endpoints, like robots.txt, security.txt, and so on. And what when that list grows? What if you already have a user called "security.txt" (or whatever the next one is)? This is why a .well-known prefix is valuable.
- kortex 6y ago
  Right. This seems like a good pattern to have. Much like app/framework specific config, I much prefer to have everything under ~/.local/ than a myriad of ~/.foo dotfiles. It's only one endpoint to route, and you don't need to change configs each time you add some new static file. IMHO, index.html and favicon should be the only files living at top level, and I guess robots.txt since that's a de facto standard (and soon to be actual standard iirc)
  - styfle 6y ago
    It would be great to move robots.txt to .well-known instead. Same with favicons, although you can specify an arbitrary path to most favicons using index.html

remram 6y ago

The problem is when there starts to be many "site-specific stuff". It's easy to remember not to route .well-known to user-generated content in your app. It's less easy to remember a list of endpoints, like robots.txt, security.txt, and so on. And what when that list grows? What if you already have a user called "security.txt" (or whatever the next one is)? This is why a .well-known prefix is valuable.

kortex 6y ago
Right. This seems like a good pattern to have. Much like app/framework specific config, I much prefer to have everything under ~/.local/ than a myriad of ~/.foo dotfiles. It's only one endpoint to route, and you don't need to change configs each time you add some new static file. IMHO, index.html and favicon should be the only files living at top level, and I guess robots.txt since that's a de facto standard (and soon to be actual standard iirc)
- styfle 6y ago
  It would be great to move robots.txt to .well-known instead. Same with favicons, although you can specify an arbitrary path to most favicons using index.html