Hacker News Reader

Comment by rochacon | Hacker News Reader

HTTPie is amazing, but I grew tired of it being "slow", slower than some of my services response times at least.

Migrated to Curlie [1], `alias http=curlie`, and been happy with it since. Same API, better performance and access to full `curl` flags.

[1] https://curlie.io

View on HN

From https://curlie.io/

> If you like the interface of HTTPie but miss the features of curl, curlie is what you are searching for. Curlie is a frontend to curl that adds the ease of use of httpie, without compromising on features and performance. All curl options are exposed with syntax sugar and output formatting inspired from httpie.

So curlie is curl. Thanks for this.

Can confirm; I switched to curlie a long time ago and haven't looked back.

It would be interesting to create an alternative to `http-prompt` [0], using curlie and go-prompt [1] instead of HTTPie and `prompt_toolkit` [2], respectively.

[0]: https://github.com/eliangcs/http-prompt

[1]: https://github.com/c-bata/go-prompt

[2]: https://github.com/prompt-toolkit/python-prompt-toolkit

If the API is really the same you don't need an alternative, just an option to use curlie instead

Curlie seems very nice, but I'm a little concerned about your advice to alias http(ie) to curlie as they are strongly very much not interchangeable ("-a" means something entirely different between the two).

Never experienced slowness with it, what specifically is the problem?

For one-off runs it doesn't feel slow, but it gets more noticeable if you're running it in a loop or against a server you know is fast (i.e. local Go server), but consider this output as an example (running from an AWS server):

  # time http google.com >/dev/null 2>&1
  real 0m0.337s
  user 0m0.259s
  sys 0m0.036s
  
  # time curlie google.com >/dev/null 2>&1
  real 0m0.042s
  user 0m0.011s
  sys 0m0.005s
  
  # time curl google.com >/dev/null 2>&1
  real 0m0.039s
  user 0m0.009s
  sys 0m0.004s

Ok, sounds like a problem with Python’s startup speed. They have been improving it little by little but not sure how far they’ll get.

One other thing is that httpie is typically an interactive tool. If I were hitting services in a loop I’d just write a Python/requests script to do it rather than bash+httpie.

Author here: the main driver for writing curlie was not about the slowness of httpie but about all the features I was missing from curl. As curlie is just a wrapper on top of curl, you get all the great options of curl like http/2, http/3 support, advanced TLS options etc.

> Like curl but unlike httpie, headers are written on stderr instead of stdout.

What’s the thinking here? If I ask for the headers, wouldn’t I want that on stdout?

The examples show that the headers are printed by default, so writing them to stderr is the correct behavior.

Writing by default is logically followed by stderr? I just don’t follow.

Asking a program for info and then getting that info on stderr seems really bizarre to me.

Is this some historical UNIXism?

A lot of command line tools send debugging output to stderr so you can build a pipe/redirect output and still see the debug and error outputs.

You could consider headers to be some sort of debug prints..

>Asking a program for info and then getting that info on stderr seems really bizarre to me.

The info that you're asking the program for is the response body. You're using `curl` / `curlie` primarily to get the response body and then pipe it to the rest of the command. The headers are ancillary.

If the headers were the info you were asking for, eg when running `curl -D -`, then yes they should get printed to stdout. That is not the case being considered here.

It's convenient to have stdout only returning the body so you can work with it without having to remove the header. With curl, if you pass the -v, you get headers on stderr too.

When headers are specifically requests with -i for instance, I agree curlie should print them on stdout. PR accepted ;)

IDK, that is one of the things that annoys me to be honest, because sometimes headers get written after the body into the output (idk why, but guess some buffering and/or parsing+formating lag).

I almost forked it to get both outputs into stdout haha

I get that sometimes too. It should be fixable without having to send headers to stdout.

Most of the time when I do any further processing (save to file, pipe to other tools, etc) I'm interested in the response body. The headers are a useful diagnostic, and things like cookies are useful to save, but those don't typically belong in the same stream: I can't do the same things to the headers as I can the body, and so including both in the same stream will tend to reduce my options for downstream processing. If I actually do want them both in the same stream I can redirect stderr to stdout.

Reply on news.ycombinator.com