Ideas to improve header visualization

[bl-ue]

Hello!

I have some ideas for improving the display of headers in HTTPie. Please let me know which ones you agree with and I'll see if I can implement them right away.

1. If the value of any header matches the RFC 2616 allowed date formats, add a parenthetic, colored message at the end of the header stating how long ago/how long from now the date is, e.g.:

   Date: Sun, 14 Feb 2021 18:47:43 GMT
   Expires: Tue, 16 Mar 2021 18:47:43 GMT  (30 days from now)

2. Color the values of the Cookie/Set-Cookie headers because developers frequently inspect them

3. Add a colored, parenthetic, formatted version of the value of Content-Length headers:

   Content-Length: 5934  (5.93 kB)

What do you think @jakubroztocil @Almad?

[jkbrzt]

@bl-ue I like your ideas. They add a nice human touch, which is an important principle behind httpie’s design.

To summarize, there’re two broader ideas here:

1. Provide deeper, header-specific syntax highlighting (e.g., for Cookie & Set-Cookie).
2. Humanize header data (e.g, lengths & dates).

Improving the syntax highlighting should be quite straightforward (please feel free to create a new issue for this).

Simply adding humanized versions of headers with data, though, would break backward-compatibility and also the current principle of not altering the message structure. So there’s some product design thinking on my part to be done here.

[bl-ue]

and also the current principle of not altering the message structure.

I wondered if there was something like that behind HTTPie. That's actually why I added two spaces before the parentheses, I know that's a great way to distinguish between the original text and the added text!

What would you do in that case? Add a --humanize option that adds humanization with a warning/info in the help that the output will not be the exact output?

Techinically, with colors, the output is already completely athwart the original, because the ANSI escape codes used to output color are not included in the HTTP spec :smile: but I know, you mean visually.

Improving the syntax highlighting should be quite straightforward (please feel free to create a new issue for this).

You mean to discuss/advertise this change?

[jkbrzt]

I wondered if there was something like that behind HTTPie. That's actually why I added two spaces before the parentheses, I know that's a great way to distinguish between the original text and the added text!

The idea is to make it easy for the user to copy the output and paste it, for example, into their API documentation. So although the spaces help visually, the extra output still breaks this use case.

What would you do in that case? Add a --humanize option that adds humanization with a warning/info in the help that the output will not be the exact output?

• The toggle should be based on --format-options (which I completely forgot about for a moment).
• Something like: --format-options headers.humanize:true.
• Additionally, we could introduce a more general --humanize as a shortcut similar to --sorted / --unsorted (which toggles both headers.sort:true and json.sort_keys:true).
• Separately decide what should the default be.

Techinically, with colors, the output is already completely athwart the original, because the ANSI escape codes used to output color are not included in the HTTP spec 😄 but I know, you mean visually.

You can still copy the output and paste it into your API documentation without any cleanup.

Improving the syntax highlighting should be quite straightforward (please feel free to create a new issue for this).

You mean to discuss/advertise this change?

The syntax highlighting improvement is a separate topic so it should have its own GitHub issue.