Live data from Hacker News

So You Want to Define a Well-Known URI

mnot.net

41–50 of 105 posts

Re: So You Want to Define a Well-Known URI

#41

I'm not sure I like ` https://domain.com/.well-known/robots.txt ` any better frankly

Whoever decided it would be a good idea for ".well-known" to be a "hidden" directory is a complete fool. All it does is provide the opportunity for confusion, misconfiguration, skipped backups, missed git check-ins, forgotten updates and more. Literally the only people a folder like that is hidden from is the whoever is managing the web server. Sure, if everyone knows what they're doing, it's not a problem. But we al…

I think the blog author is the one who wrote the original RFC. To be fair to him, there once was a time web servers were more commonly thought of as truly being remote directories of files you can view or link to, not just domains the browser hides the rest of, and dotfiles would commonly act like dotfiles in local file listings. Nowadays, the assumption is if you go to the base URL it should only ever serve the default page and if you try to go to a directory it should throw an error. Well, unless you're one of those ancient sites like https://ftp.mozilla.org/

I'm not saying it's good or bad how things turned it, but the choice of a dotfile for this sure did not pan out well as the web went the exact opposite direction it would have been relevant in.

Re: So You Want to Define a Well-Known URI

#42
post #37

Earlier quoted context omitted.

Giving a markdown version of a page seems like an interesting choice instead of just embedding a schema marked up one

Every page on code.claude.com has a markdown version available by just appending ".md", and Claude Code knows about it. E.g: https://code.claude.com/docs/en/overview and https://code.claude.com/docs/en/overview.md

After some consideration, I also applied this convention to every site I build - including content negotiation: Clients can either send an Accept header with their preference, or append an explicit extension (.md|.markdown for Markdown, .json for JSON API responses, or .html for the human HTML page). Together with the content negotiation part, it feels very much like HTTP was intended to work - especially the fact that API clients, AI agents, and humans all use the same URLs, but get the content in the shape they need.

Re: So You Want to Define a Well-Known URI

#43

I'm not sure I like ` https://domain.com/.well-known/robots.txt ` any better frankly

Whoever decided it would be a good idea for ".well-known" to be a "hidden" directory is a complete fool. All it does is provide the opportunity for confusion, misconfiguration, skipped backups, missed git check-ins, forgotten updates and more. Literally the only people a folder like that is hidden from is the whoever is managing the web server. Sure, if everyone knows what they're doing, it's not a problem. But we al…

The main point of consideration here probably was how to avoid conflicts with URLs of existing sites, not exactly people who aren't able to serve an endpoint with a dot within its path...

Re: So You Want to Define a Well-Known URI

#44
post #8

Why are they so specific? Why password-reset instead of a more generic link tree? Why discord domain verification instead of domain-verifications with a dynamic list on entries? Seems like a waste of time. I would just define my own spec outside of well known for my use case.

> Why discord domain verification instead of domain-verifications with a dynamic list on entries? The TXT record itself is already a dynamic list of entries. It's far simpler and easier to iterate through the list and compare the start of each value with your search string until you find "discord domain verification" directly than it would be to do anything else. Example: ;; ANSWER SECTION: ycombinator.com. 300 IN TX…

Domain verifications leak information that they shouldn't - it should be "random key.domain.com in TXT randomkey"

Re: So You Want to Define a Well-Known URI

#45
post #8

Why are they so specific? Why password-reset instead of a more generic link tree? Why discord domain verification instead of domain-verifications with a dynamic list on entries? Seems like a waste of time. I would just define my own spec outside of well known for my use case.

> Why discord domain verification instead of domain-verifications with a dynamic list on entries? The TXT record itself is already a dynamic list of entries. It's far simpler and easier to iterate through the list and compare the start of each value with your search string until you find "discord domain verification" directly than it would be to do anything else. Example: ;; ANSWER SECTION: ycombinator.com. 300 IN TX…

Having all those TXT records at the domain apex like that makes the TXT query reply huge, which affects, for instance, every mail recipient who merely wants to check the SPF record. This is a bad pattern to follow.

Re: So You Want to Define a Well-Known URI

#47
post #42
post #37

Earlier quoted context omitted.

Every page on code.claude.com has a markdown version available by just appending ".md", and Claude Code knows about it. E.g: https://code.claude.com/docs/en/overview and https://code.claude.com/docs/en/overview.md

After some consideration, I also applied this convention to every site I build - including content negotiation: Clients can either send an Accept header with their preference, or append an explicit extension (.md|.markdown for Markdown, .json for JSON API responses, or .html for the human HTML page). Together with the content negotiation part, it feels very much like HTTP was intended to work - especially the fact th…

I've done this off and on for various sites over the years too, and probably should be more consistent about it. A number of sites do or used to do some variation of this, and I wish it was more widespread. E.g. Reddit will serve up a json version of a sub-dreddit if you do /r/subreddit.json

Re: So You Want to Define a Well-Known URI

#48

No, in fact I don't. But this post wouldn't be of any help anyway. It feels like it's about nothing, there is no substance, just stating some obvious facts. Without examples that lead to some real recommendations, this whole expertise claimed by the author is of no use.

> expertise claimed by the author

The author is on record as trying to remove HTTP 418 "I'm a teapot" support from NodeJS, which resulted in backlash and Python adding support for it.

https://en.wikipedia.org/wiki/Hyper_Text_Coffee_Pot_Control_...

Re: So You Want to Define a Well-Known URI

#49

Earlier quoted context omitted.

I would say acme-challenge is one of the most used ones. How else would one get SSL certificates today

DNS TXT challenge for example. Also better because you can get wildcard certs.

Also, DNS-PERSIST-01 seems to be coming soon for Let's Encrypt, which should allow even people that can't easily dynamically update their DNS records to get wildcard certs. I assume this might become more widely used than HTTP-01 challenges.

Re: So You Want to Define a Well-Known URI

#50

No, in fact I don't. But this post wouldn't be of any help anyway. It feels like it's about nothing, there is no substance, just stating some obvious facts. Without examples that lead to some real recommendations, this whole expertise claimed by the author is of no use.

> expertise claimed by the author The author is on record as trying to remove HTTP 418 "I'm a teapot" support from NodeJS, which resulted in backlash and Python adding support for it. https://en.wikipedia.org/wiki/Hyper_Text_Coffee_Pot_Control_...

Not many people could have gotten that done. Sounds like expertise to me.
Post reply on HN