@rin @NEETzsche

> can't guess who is a browser by ua

Firemen have to connect lengths of hose together, and they are trained to have one hold the hose and turn his head away, while the other does the connecting. This is because if they're both looking, they'll both move the hose around, and it will take longer to connect than if one holds still, and even if you're trying to hold still, you'll involuntarily move to "help". (Also it saves additional time because if they make eye contact when connecting their hoses, they always stop to say "nohomo".) So if a UA asks for the thing that exists at a given URL, you should give it that thing instead of trying to guess what it actually wants; if the client tries to guess and the server also tries to guess, that the client and the server are at odds.

Anyway, UA-based content transformation was discovered to be a bad idea in the 90s, it is still a bad idea for the same reason it was back then.

> everyone who opens the link in the browser should get a 406?

See, the problem starts when you're trying to detect whether the UA is a browser or not and deciding what to display based on a bad guess (any guess is bad), but most browsers will include "*/*" in the Accept: header anyway. You go down the priority list, match it against what you can send back, and show them the best match for that (though the UA can't rely on that). If it's a redirect, you can't vary that based on the Accept header; a 200 has to be a 200, a 301 means that resource is elsewhere. The entire idea is that this is a resource, it's at this URL, and the server will pass back a representation of that resource. (It's also supposed to be a 405 with an Allow header if they try to use a method not supported by that resource, so "GET /inbox" shouldn't just pass back index.html and "POST /objects/whatever" shouldn't 404.)