Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Curl is magic.

Every so often (less so in recent years) I come across a bad homespun implementation of an HTTP client embedded in a larger project. Usually, a few lines of code to open a socket and POST some data to a hard coded URL. I always replace these with curl, usually over the objections of the original programmer.

The problem with HTTP (v1) is that it seems very simple to write a cut down client. But your simple client better handle proxies, various encodings, chunked bodies, redirects, HTTPs (with all the machinery that implies), and a whole host of annoying little features that the client is not in control of.

"But I don't need to implement talking through a proxy, we don't use one"

You don't use one now, but in 6 months you might. Or your client's might install one without your knowledge.

It is actually pretty simple to write an HTTP server (I wouldn't advise it) because the server controls a lot of the conversation. But clients are best left to either the OS or curl.

Self-promotion time: https://sheep.horse/2019/3/using_libcurl_effectively_and_saf...



Exactly! Most people using CURL don't realize how good it actually is or how complicated HTTP can get.


Sometime people started using expect headers (with content length) for long posts and 100-Continue and curl just handled it before I heard of it (outside of like push type apps).




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: