top | item 44591789

(no title)

klinch | 7 months ago

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?

discuss

order

rollcat|7 months ago

Here's my shot:

- 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?