Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

“I Could Rewrite Curl”

daniel.haxx.se

Post reply on HN
Print view View original

111–120 of 193 posts

Re: “I Could Rewrite Curl”

#111

Post by mckirk »

WORMS_EAT_WORMS wrote: post #105
eps wrote: post #44

Earlier quoted context omitted.

> SMB Woah. This is genuienly impressive.

As someone who fell into the category of: > "Most folks I know don't even know about the other protocols curl supports and have only interfaced with curl through its http." Just curious if you could elaborate on this one specifically and why you found it especially interesting.

SMB is... not very straightforward. I needed to reverse engineer it once to write an exploit, and it's difficult to properly formulate even basic requests, let alone the more complex stuff the protocol supports.

Re: “I Could Rewrite Curl”

#112

Post by spamizbad »

parhamn wrote: post #30

Let's be honest here. Curl to 98% of people is http/1 requests with some post params and maybe json body, with some custom headers. Most language standard libs (which might be using libcurl) can facilitate writing that relatively quickly. And probably with a more 'modern' CLI. Curl though, is a very wide breadth project. It currently supports the following protocols: DICT, FILE, FTP, FTPS, GOPHER, HTTP, HTTPS, IMAP,…

Why even get mad at curl? If you hate curl and all you want is a simple http/1 client just spend a few minutes to write a Python script w/requests that takes verbs and payloads from the command line rather than make the curl author's day shitty.

Re: “I Could Rewrite Curl”

#113

Post by oxfordmale »

parhamn wrote: post #30

Let's be honest here. Curl to 98% of people is http/1 requests with some post params and maybe json body, with some custom headers. Most language standard libs (which might be using libcurl) can facilitate writing that relatively quickly. And probably with a more 'modern' CLI. Curl though, is a very wide breadth project. It currently supports the following protocols: DICT, FILE, FTP, FTPS, GOPHER, HTTP, HTTPS, IMAP,…

Curl has been a life safer for me when I had to interact with a legacy third party server. The Python request model was regularly hanging when making requests to this server, whereas I never observed these issues with curl. Curl appears to be better at dealing with such legacy edge cases as it has been around for more than two decades.

Re: “I Could Rewrite Curl”

#114

Post by hawkesnest »

It seems like the correct response for these "reimplementation" types of criticism is to encourage the person to do so and share the results.

I have, for personal gratification, attempted (with varied success) to reimplement several utilities. The experiences were quite eye-opening, seeing how well designed the "standard" utilities are, and identifying new ways to improve my code.

Re: “I Could Rewrite Curl”

#115

Post by jeffrwells »

parhamn wrote: post #30

Let's be honest here. Curl to 98% of people is http/1 requests with some post params and maybe json body, with some custom headers. Most language standard libs (which might be using libcurl) can facilitate writing that relatively quickly. And probably with a more 'modern' CLI. Curl though, is a very wide breadth project. It currently supports the following protocols: DICT, FILE, FTP, FTPS, GOPHER, HTTP, HTTPS, IMAP,…

This begs the question of why all of these protocols should be in one library, instead of one each.

If a project is only going to ever use http, why would I need to bundle in all of the others?

Genuinely curious what the advantages are

Re: “I Could Rewrite Curl”

#116

Post by rkangel »

krick wrote: post #68
parhamn wrote: post #30

Let's be honest here. Curl to 98% of people is http/1 requests with some post params and maybe json body, with some custom headers. Most language standard libs (which might be using libcurl) can facilitate writing that relatively quickly. And probably with a more 'modern' CLI. Curl though, is a very wide breadth project. It currently supports the following protocols: DICT, FILE, FTP, FTPS, GOPHER, HTTP, HTTPS, IMAP,…

True. I'm kind of surprised (again) by Daniel after 20 years of maintaining curl being so salty about "people not appreciating the achievement". Yes, for overwhelming majority of users curl in 2021 is just a simple http/https request client. And, yes, in 2021 that could be written over a weekend with a better CLI, mainly because most of the languages already have all important stuff implemented in a [standard] librar…

> I'm kind of surprised (again) by Daniel after 20 years of maintaining curl being so salty about "people not appreciating the achievement"

You're surprised by him being salty? I can't imagine what it's like to be on the receiving end of the water torture of people continually belittling the work you have done over 20 years and given to the community.

Re: “I Could Rewrite Curl”

#117

Post by Tomte »

With one of the comments I immediately thought "this is HN". And I was right.

But on a second look I'm quite certain it wasn't the wording or the sentiment, but the beige background color that I hadn't consciously noticed before.

Re: “I Could Rewrite Curl”

#118

Post by jsjohnst »

slooonz wrote: post #84
thrower123 wrote: post #22

Earlier quoted context omitted.

I wonder what percentage of attempts to rewrite curl in modern languages end up eventually just calling code from libcurl if you trace down through their standard libraries far enough?

What standard library uses curl for HTTP ? AFAIK, none of Go, Python or Node does.

Many of the commonly used Ruby HTTP gems use libcurl under the hood.

Re: “I Could Rewrite Curl”

#119

Post by bluehatbrit »

bryanrasmussen wrote: post #54
Hippocrates wrote: post #10

Just a little tangent but I think everyone should know cURL… not postman, not httpie or any other more “friendly” tool. cURL is the standard, pre-installed, do-everything, scriptable tool to interact with web APIs. I could say mostly the same stuff about knowing Bash. It separates the barely effective from hyper-effective individuals on simple day to day (programming) tasks.

>Just a little tangent but I think everyone should know cURL… not postman, not httpie or any other more “friendly” tool. 5 years ago I was partner in a startup, we got some money from government right about the time I said I have to take a few months off to do consulting and make some money, my partner said I want to use money to make app I said no for various reasons but he went ahead and did app. So I was helping t…

I've often jokingly said to people "curl or it didn't happen" suggesting they send me a single curl command I can run to re-produce it. However, every time someone's actually provided a curl command over a postman file, it's either showed it's not a bug or I've found the bug within minutes of running the command.

I'm a fan of postman for some things, it sure is easier to modify and re-run http requests over and over in some cases. But on the whole if you're trying to debug an issue, dropping down to curl solves so many problems and is pretty easy to share with anyone no matter their OS for the most part.

Re: “I Could Rewrite Curl”

#120

Post by rad_gruchalski »

dkarl wrote: post #106
parhamn wrote: post #30

Let's be honest here. Curl to 98% of people is http/1 requests with some post params and maybe json body, with some custom headers. Most language standard libs (which might be using libcurl) can facilitate writing that relatively quickly. And probably with a more 'modern' CLI. Curl though, is a very wide breadth project. It currently supports the following protocols: DICT, FILE, FTP, FTPS, GOPHER, HTTP, HTTPS, IMAP,…

A question that arises out of this is, should the 90% use cases be handled by a small, simple tool, or by the tip of the iceberg of a large, complex tool such as curl? I can see the advantages of standardizing on a complex, powerful tool for simple use cases. For one thing, it may be the only way to standardize: simple versions are too easy to write, and therefore you get dozens of competitors, none of whom are popul…

> A question that arises out of this is, should the 90% use cases be handled by a small, simple tool, or by the tip of the iceberg of a large, complex tool such as curl?

But nobody is forced to use curl? People use it because it’s convenient, shoot them selves in the foot and then lash out at the author the tool for their own choices. Where’s the fault?

Post reply on HN