5 ms·

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`, a

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 https://curlie.io

kjsthree 7y ago
> 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?
- Arnavion 7y ago
  The examples show that the headers are printed by default, so writing them to stderr is the correct behavior.
  - kjsthree 7y ago
    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?
    - unilynx 7y ago
      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..
    - Arnavion 7y ago
      >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.
    - poitrus 7y ago
      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 ;)
- rochacon 7y ago
  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
  - poitrus 7y ago
    I get that sometimes too. It should be fixable without having to send headers to stdout.
- andreareina 7y ago
  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.
Seirdy 7y ago
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 https://github.com/eliangcs/http-prompt [1]: https://github.com/c-bata/go-prompt https://github.com/c-bata/go-prompt [2]: https://github.com/prompt-toolkit/python-prompt-toolkit https://github.com/prompt-toolkit/python-prompt-toolkit
- riquito 7y ago
  If the API is really the same you don't need an alternative, just an option to use curlie instead
mixmastamyk 7y ago
Never experienced slowness with it, what specifically is the problem?
- rochacon 7y ago
  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
  - mixmastamyk 7y ago
    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.
  - mixmastamyk 7y ago
    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.
- poitrus 7y ago
  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.
sk5t 7y ago
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).
jdnier 7y ago
From https://curlie.io/ 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.

kjsthree 7y ago

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

Arnavion 7y ago
The examples show that the headers are printed by default, so writing them to stderr is the correct behavior.
- kjsthree 7y ago
  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?
  - unilynx 7y ago
    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..
  - Arnavion 7y ago
    >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.
  - poitrus 7y ago
    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 ;)
rochacon 7y ago
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
- poitrus 7y ago
  I get that sometimes too. It should be fixable without having to send headers to stdout.
andreareina 7y ago
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.

Seirdy 7y ago

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 https://github.com/eliangcs/http-prompt [1]: https://github.com/c-bata/go-prompt https://github.com/c-bata/go-prompt [2]: https://github.com/prompt-toolkit/python-prompt-toolkit https://github.com/prompt-toolkit/python-prompt-toolkit

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

mixmastamyk 7y ago

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

rochacon 7y ago
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
- mixmastamyk 7y ago
  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.
- mixmastamyk 7y ago
  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.
poitrus 7y ago
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.

sk5t 7y ago

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).

jdnier 7y ago

From https://curlie.io/ 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.