At first I thought, what is so unfriendly about cURL? Then I saw the screenshot that shows a comparable cURL request behind the HTTPie request and I'm convinced.
Isn't the HTTpie command simpler because it uses defaults for the content type and charset? If Curl did the same (not sure why it should because not everything is JSON/UTF-8), the command would be about as short as the HTTPie one.
This is probably different for different people, but I find myself constantly looking up the right flag for controlling a part of a request with curl even though I use it a lot. Having the command line be smarter about interpreting which argument is which seems like a productivity gain to me.
Determining the type of an argument by looking up the presence of ':', '=', or '==' is brilliant. I liked it.
It can also be used to replace Wget, which not only breaks a multibyte filename sometimes, but also requires the --content-disposition option to handle the Content-Disposition header.
I'd just wrap a simple program around curl to improve its argument passing complexity if that's your pain point but I wouldn't go on rewriting an HTTP client.
Curl is a very mature code base by now and that's something to appreciate. It handles all the edge cases well and has dealt with all the mess that you'll discover over time.
Httpie doesn't come close to Curl in terms of features. Its selling points are colourised output (using pygments) and (slightly) better json formatting. Here's an unobstructed side by side comparison for the same request: http://i.imgur.com/Bj2wRkq.png
While it won't replace Curl, it can prove quite useful while testing APIs.
I haven't looked at any code, but I would strongly suspect that it's because either HTTPie or python-requests is using a plain dictionary instead of an ordered dictionary under the hood.
That would appear to be a bug to me. When you want to see the headers of such a transaction you want to see them in the order in which they left the server.
I checked the server and it looks like CURL has it right.
Colorizing is one thing, reordering is quite another, debugging tools should show the situation with as much fidelity as possible.
The order in which header fields with differing field names are received is not significant. However, it is "good practice" to send general-header fields first, followed by request-header or response-header fields, and ending with the entity-header fields.
Yes, if you're implementing a client or server, you should not depend on the order of the headers. Completely separately, when I have a command line client for debugging, I want to see the request and response exactly as they were sent/received, respectively.
> Instances of the same path and name will overwrite each other, with the latest instance taking precedence. Instances of the same path but different names will add additional mappings.
> When sending cookies to a server, all cookies with a more specific path mapping should be sent before cookies with less specific path mappings. For example, a cookie "name1=foo" with a path mapping of "/" should be sent after a cookie "name1=foo2" with a path mapping of "/bar" if they are both to be sent.
Requests might but that's irrelevant. Requests is built on top of urllib3 which is built on top of httplib which does use a plain dict. Also the relevant RFC says order is irrelevant.
I seem to spend my every waking moment reporting defects for HTTP APIs. HTTPie's interface is far more intuitive than cURL's, and pretty-printed responses are a kindness not just for me but for the people who have to read the bug reports, too.
jq is awesome, particularly if you need to filter or otherwise process JSON, but the great part about httpie is that it works with just about everything so you don't have to remember a different filter chain for each type of content.
It uses pygments which means you also get nested formatting for e.g. CSS or JavaScript inside an HTML document.
Somehow I used to hate curl because I began using it through the PHP Curl extension,which has the most horrible API(no,the other API for HTTP requests in PHP is even worse, it creates adhoc variables,yes variables can appear like that in PHP which leads to "variable name collisison"... ).
But with time,using it in the shell it happened to be quite powerfull for testing apis.
HTTPie coloring is a plus,does it work with XML too?
This is one of the little known gems I recommend often.
the readability difference is just amazing for me.
On that note for those of us having to use Windows at the workplace there are a few things that make life easier:
I came across this last week, a colleague wanted to open up an X window on his Fedora VM, shown in his windows box. SmarTTY just worked ootb, it was pretty amazing!
Another one - crossplatform http interception proxy like Fiddler - called mitmproxy. It has a great feature - it can transparently handle https traffic.
I've had it installed on a bunch of corporate boxes and never used it and I'm not sure if anyone used it.
Even though it's a bit crash happy on windows and the gtk file picker sucks on windows for my uses meld was the most useful(at least now they have a packaged version for windows - http://sourceforge.net/projects/meld-installer/ - so you don't have to package it yourself). It's simple, good looking, highlights the difference between 2 slightly modified lines, has support for comparing directories, and allows in-place editing.
Try the proxy in Burp Suite. The free edition lets you do most of what you can do in Fiddler. More powerful in some ways, rougher around the edges in other ways.
Charles Web Proxy? Not free, but I've been using it very reliably on all platforms for at least 3 years now. :) A nicely polished bit of software. Free 30 min "trial mode" and no-cost upgrades, if it helps. Otherwise I've also used mitmproxy, or for some things, the Net panel of Chrome Dev Tools.
I've been looking forward to having WinMerge on Linux for so long. I haven't found a good alternative on Linux which can do quick side-by-side comparison just by pasting from clipboard.
The sessions, the wget-like download mode, the binary detection, the upload capabilities... there is a lot to like here. I will definitely be checking this out. Thanks for posting!
As a python dev, I use pip all the time. My first thought was, "nice, just use pip." I appreciate your comment because it helps remind me that people approach problems from different frames of mind.
Tried it just now and I see non-ascii characters messed up, while curl shows that page fine. Probably there's some case-specific reason for that, but still…
78 comments
[ 3.1 ms ] story [ 163 ms ] threadIt can also be used to replace Wget, which not only breaks a multibyte filename sometimes, but also requires the --content-disposition option to handle the Content-Disposition header.
Curl is a very mature code base by now and that's something to appreciate. It handles all the edge cases well and has dealt with all the mess that you'll discover over time.
While it won't replace Curl, it can prove quite useful while testing APIs.
I checked the server and it looks like CURL has it right.
Colorizing is one thing, reordering is quite another, debugging tools should show the situation with as much fidelity as possible.
4.2 Message Headers
The order in which header fields with differing field names are received is not significant. However, it is "good practice" to send general-header fields first, followed by request-header or response-header fields, and ending with the entity-header fields.
> When sending cookies to a server, all cookies with a more specific path mapping should be sent before cookies with less specific path mappings. For example, a cookie "name1=foo" with a path mapping of "/" should be sent after a cookie "name1=foo2" with a path mapping of "/bar" if they are both to be sent.
http://curl.haxx.se/rfc/cookie_spec.html
Or would you like the body to always appear whole regardless of transfer type?
In the readme: https://github.com/jakubroztocil/httpie#colors-and-formattin...
In the code: https://github.com/jakubroztocil/httpie/blob/master/httpie/o...
It uses pygments which means you also get nested formatting for e.g. CSS or JavaScript inside an HTML document.
But with time,using it in the shell it happened to be quite powerfull for testing apis.
HTTPie coloring is a plus,does it work with XML too?
1) Chocolatey (package manager)
2) HTTPie
3) ConEmu (Shell)
4) gow (Unix command line utilities in Windows)
5) WinMerge (win diff)
6) TortiseSVN
7) SourceTree (git)
Makes day to day stuff much smoother....
- kitty (ssh client, fork of putty) - visualwget (wget gui) - dsynchronize (dir sync)
I can vouch for the rest too....ConEmu especially is very very nice.
Even though it's a bit crash happy on windows and the gtk file picker sucks on windows for my uses meld was the most useful(at least now they have a packaged version for windows - http://sourceforge.net/projects/meld-installer/ - so you don't have to package it yourself). It's simple, good looking, highlights the difference between 2 slightly modified lines, has support for comparing directories, and allows in-place editing.
http://bliker.github.io/cmder/
and of course Emacs for Windows
$ pip install --upgrade pyopenssl pyasn1 ndg-httpsclient
It was not too tricky