Openssl command s_client always says 400 Bad Request

According to https://bz.apache.org/bugzilla/show_bug.cgi?id=60695 my command was:

openssl s_client -crlf -connect www.pgxperts.com:443

where -crlf means, according to help of the openssl command,

-crlf - convert LF from terminal into CRLF

Then I could input multiline commands and no "bad request" as response after the first commandline any more.

OK had the same thing myself and took a while to figure out.

I can't find a way to send multiple lines in the request when using s_client interactively. It always sends the request immediately as soon as you've entered the first line. If someone knows how to get around this then please let me know!

Edit: I see Wei He has posted the way to do this - use the -crlf flag but leaving this answer here as an alternative method.

In the meantime, as jww suggested, you have to use echo for this:

echo -e "GET / HTTP/1.1\r\nHost: example.com\r\n\r\n" | openssl s_client ...

The next issue is that by default openssl closes the connection when the input file closes. Which is does immediately when using echo like this. So you don't get time to see the response and instead just see the DONE output! :-(

You can add a sleep to the echo command to get around this (note the brackets are important):

(echo -e "GET / HTTP/1.1\r\nHost: example.com\r\n\r\n"; sleep 10) | openssl s_client ...

Or, better than that, you can use the -ign_eof option to leave the connection open:

echo -e "GET / HTTP/1.1\r\nHost: example.com\r\n\r\n" | openssl s_client -ign_eof ...

Or better yet, if you're only concerned with the HTTP responses then use the -quite option which hides most of the TLS noise and also sets that -ign_eof option for you:

echo -e "GET / HTTP/1.1\r\nHost: example.com\r\n\r\n" | openssl s_client -quiet ...

You can issue a GET request with OpenSSL:

openssl s_client -quiet -connect cdn.sstatic.net:443 <<eof
GET /stackexchange/js/universal-login.js HTTP/1.1
Connection: close
Host: cdn.sstatic.net

eof

Note that you can also use "HTTP/2", but be careful because some servers (e.g. github.com) do not support it.