Replace httpie with curl about varnish-book HOT 10 CLOSED

Really?
Who would not install httpie for their training environment? And why is "curl" better?

from varnish-book.

I love httpie, and would definitely encourage anybody to install it - both in training and production environments.

But certainly if the customer has a strict policy on their testing machines, and for example deploy standard server VMs to do the training on, it can certainly be a problem. But if it's packaged in EPEL (which I think it is? Thoug not sure?), I'm not sure if it's a bigger problem than installing Varnish itself?

from varnish-book.

The training requires local root.
If they can't install httpie in their training environment they figure out how to use curl on their own.

There is absolutely no need to suboptimize the book just because someone has a lame security policy.

from varnish-book.

I think a reasonable compromise would perhaps be to use httpie in the examples and such, but then include a small section of "here's how you do the most common things in curl as well" - for those that are stuck with it. But using httpie "inline".

from varnish-book.

We leave httpie in.
If somebody cares enough about this to contribute a little appendix on curl usage I'm sure pull requests would be pulled with a smile and a nice pat on the back. :-)

from varnish-book.

I'll wait until Dridi is back from vacation to comment on this issue. It is my understanding that he faced many problems with httpie while teaching at a customer's site.

from varnish-book.

In the Varnish 3 series of the Varnish Book, I used to get negative feedback on the GET command, because unlike curl they couldn't figure what the flags would mean.

For my first Varnish 4 training, the customer had decided to host the VMs used for training, and they use RHEL 6. Httpie couldn't be installed via EPEL and they eventually tried with pip but in the end it didn't work.

Fallback to curl, but looking at http commands they did not understand what was going on, especially the developers (it was a 3 days training including both courses). And there's a terrible UI decision in httpie that leads to confusion.

http -p hH --proxy=http:http://localhost sport.example.com/index.html

The --proxy option is confusion because:

• of the http:http: double scheme
• the very name "proxy"
• the impedance mismatch with HTTP

They first thought that they had to specify this to bypass their corporate proxy. Then they thought that doubling http: was a typo. And then they didn't understand the relationship between this and a Host: header.

If we keep httpie, we should for instance get rid of all --proxy options and simply follow the principle of lest astonishment.

http -p hH localhost/index.html Host:sport.example.com

Same result, a lot closer to reality. That is important during training to not confuse trainees, they already have a hard time with VCL.

Now why curl?

It doesn't pretty print the output, it doesn't have colors. But really when a trainee is on a windows laptop using putty, they have bad UX anyway. And it's not that hard to read one key:value per line.

It is more verbose:

http -p hH localhost/index.html Host:sport.example.com
# vs
curl --verbose --header Host:sport.example.com localhost/index.html
# vs
curl -v -H Host:sport.example.com localhost/index.html

Those are valid objections. Probably worth a tad bit more than $.02, maybe as much as $.5. :-)

I'll see if I can find the time to rewrite some of the httpie statements to be more in line with best practices. The use of --proxy is probably a bit distracting and should be placed.

I suggest we move along with the current toolset and at a later point, when we're happy with the rest of the content we can add curl examples alongside the httpie ones. As you say, curl is omnipresent and a well known tool. However, my personal option is that httpie is a lot more powerful (the native JSON support is very nice).
You might scoff at the color support in httpie, but for me it makes a bit of a difference. I've abandoned curl quite a bit of time ago.

from varnish-book.

@perbu I use httpie when I want to look at the payload itself, because color support becomes very useful there!

I still use curl for both interactive commands and scripting, so unless I'm interested in looking at the response body, I stick to it.

During the training, we rarely look at the body, and AFAIK there's no json involved. When we do care about the body, we use a proper browser.

from varnish-book.

Closed because this issue is a bit subjective and we better use our resources in more meaningful improvements for the book.

from varnish-book.