Hacker News Reader

Comment by sirn | Hacker News Reader

    $ curl -I news.ycombinator.com
    HTTP/1.1 200 OK
    Content-Type: text/html; charset=utf-8
    Cache-Control: private
    Connection: close

Keep in mind that this will fire a HEAD request to the server which, depending on web server you use in development, may not return the exact header you'd get with GET (IIRC, Jetty used to do this).

I like to use something like this in such situation:

    $ curl -s -D /dev/stderr news.ycombinator.com >/dev/null

View on HN

You can also use the -i option which prints out the headers and the response body (which is perhaps a bit too noisy).

    curl -i http://news.ycombinator.com

    curl -v https://github.com

which dumps everything. Including, handily, the HTTPS handshake.

I rarely find I use curl's -s without its -S, e.g. -sS. It seems curl's design is flawed in its definition of -s; perhaps it's historic and it was too late to change it.

The junk goes to stderr, so it won't impact anything but your screen when used from the command line. And sometimes (large transfers) you want that information. I think the default is sane. When you're using curl in a script you use -s, when you're using it interactively you want the diagnostics.

Yes, sometimes when it's a particularly large transfer I want a progress meter but I normally don't so it's in the way; perhaps when we all had modems. And from a script I'd still want to use -sS instead of -s because although the script is obviously checking curl's exit value the user wants to see curl's specific complaint before the script's own knock-on diagnostic.

    $ curl -s does.not.exist; echo $?
    6
    $ curl -sS does.not.exist; echo $?
    curl: (6) Couldn't resolve host 'does.not.exist'
    6
    $

Reply on news.ycombinator.com