> How exactly do you propose that wttr.in, which is not actually a process running on your machine (but a remote server), call isatty() on your machine?
This is not plaintext, this is ANSII garbage. If you're outputting HTML, you set the content type to text/html, so the client can interpret it. But the lack of an associated content type is not the problem, it's the blind assumptions about the capabilities of the client.
Thanks for clarifying. You're right! The output isn't actually text/plain. As someone who values standards, it is annoying to see control-code garbage when the content type claims to be text/plain. But wttr.in seems more like a fun novelty than a serious service and I suspect they don't pay much attention to standards. Still, I'm not sure that excuses saying one thing in the headers and delivering something else in the body.
That control codes are documented in a standard is orthogonal to the HTTP standard.
A terminal program should follow the terminal standard by all means. But a web service advertising one Content-Type but delivering another Content-Type is a violation of the web standards.
Agreed, but but what would the right content type even be? Afaik there's no `text/tty` or `text/with-control-characters` etc. On the other hand, using the generic `application/octet-stream` seems unnecessarily vague?
- curl sees that the standard output is a tty, consults $TERM, termcap, etc
- curl crafts an "Accept:" header, format to be specified
- server sees Accept and responds with appropriately encoded response; e.g. for text/plain it would just output preformatted text
As this is currently NOT a common use case (mostly fun toys, biggest use case is Github printing out a pride flag), the exact content type can be easily iterated on to standardise it.
For example, the most common cases (TERM=xterm or xterm-256color) could be specified in the standard and treated as abbreviations for the complete description of capabilities. The server can have those common cases built-in, but it should also be free to ignore any capabilities it doesn't understand and send out a conservative response. All of these smarts could be a part of a library or framework.
I made this up on the spot, it's not hard, because the entire stack is adequately layered. So just don't break those layers, m'kay?
That's exactly my point. You can't do that.
This is not plaintext, this is ANSII garbage. If you're outputting HTML, you set the content type to text/html, so the client can interpret it. But the lack of an associated content type is not the problem, it's the blind assumptions about the capabilities of the client.