8 ms·
Here's an unnecessary use of curl: curl perdu.com You can use netcat instead, HTTP is easy to write and read: nc perdu.com 80 <<< 'GET / HTTP/1.1'$'\r\n'
by rpigab 4y ago
Here's an unnecessary use of curl:
curl perdu.com
You can use netcat instead, HTTP is easy to write and read:
nc perdu.com 80 <<< 'GET / HTTP/1.1'$'\r\n''Host: perdu.com'$'\r\n''Connection: close'$'\r\n\r\n'
Inspired by https://fasterthanli.me/articles/the-http-crash-course-nobody-asked-for https://fasterthanli.me/articles/the-http-crash-course-nobod...
- woodruffw 4y agoYou probably don’t ever actually want to do that, except as a demonstration to someone who doesn’t know how HTTP works. (It also doesn’t support TLS or any version of HTTP other than 1.1, whereas curl can negotiate a newer version.)
- jfoutz 4y agoyou've blown chunked transfer encoding, which is a client MUST https://www.rfc-editor.org/rfc/rfc2616#section-3.6 https://www.rfc-editor.org/rfc/rfc2616#section-3.6 If you control both ends, no big deal. If you're just working out some protocol, no big deal. I love simple toy solutions to problems, especially when understanding the problem space. But this is going to fall apart under any sort of pressure.
- rpigab 4y agoThis was a joke to poke fun at people who comment "unnecessary use of cat", but yeah, it's bad on many levels. However, in many simple cases, it will produce a valid response, since http server implementations are often extremely lenient. But I'd never use it because curl is truly everywhere.
- jstanley 4y agoThat's not the same at all, because the nc example dumps the response headers to stdout and the curl example does not. It's more similar to "curl -i perdu.com", except (on my system? maybe it's non-default) curl colourises the header names when output to a TTY, and prints a progress report to stderr when output to a non-TTY.
- deleted 4y ago[deleted]
- anthk 4y agoCurl supports parsing.
- sph 4y agoLooking forward to you doing TLS by hand with netcat.