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