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

Curl, 17 years old today

daniel.haxx.se

Post reply on HN
Print view View original

61–70 of 100 posts

Re: Curl, 17 years old today

#61

Post by ams6110 »

leni536 wrote: post #19
nailer wrote: post #17

And still better than wget, which only does http 1.0 and this has problems due to lacking a 'host' header. Curl just works.

> And still better than wget, which only does http 1.0 and this has problems due to lacking a 'host' header. Well I had to check, but this is not true at all: $ nc -l -p 9999 GET / HTTP/1.1 User-Agent: Wget/1.15 (linux-gnu) Accept: */* Host: localhost:9999 Connection: Keep-Alive Also wget can recursively mirror webpages and there are nice options to carefully select contents you want to download. It's quite dated tho…

wget to make a static copy of a site is the one thing I use it for. It's awesome. I tend to reach for curl first in most other cases, for one thing it's included in the "minimal" RHEL installation so I can pretty much depend on it always being there, whereas wget is extra.

Re: Curl, 17 years old today

#62

Post by DenisM »

artpar wrote: post #23
escherize wrote: post #11

I love curl so much. I just learned that you can 'copy to curl command' from the chrome inspector's network panel by right clicking on any request!! I want to make a library that reads the curl command (and maybe request syntax?) and outputs a function that will do that command.

https://shibukawa.github.io/curl_as_dsl/

So many languages supported, but no plain C?

Re: Curl, 17 years old today

#64

Post by gobengo »

josephpmay wrote: post #46

It's slightly weird to me that I am older than Curl and Wget. They always seemed like Unix Monoliths to me; I had just assumed they had always existed.

THIS. I have the exact same feelings. Same with the 'Kubuntu is 10 years old' link on the homepage. I think we just grew up at the perfect time!

Re: Curl, 17 years old today

#66

Post by twerquie »

cmg wrote: post #52
laurent123456 wrote: post #51

Earlier quoted context omitted.

Curl is great and all but I don't think this quote makes much sense. Are there examples of services that would, for example, load in a browser but not through curl? I'd think it's rather the opposite since you can through pretty much anything at curl and it will work.

Anything that requires JavaScript to fetch and display content.

Yeah, building web apps this way is a fad. I predict everyone will go back to full page reloads and server-rendered content.

/s

Re: Curl, 17 years old today

#67

Post by TazeTSchnitzel »

artpar wrote: post #23
escherize wrote: post #11

I love curl so much. I just learned that you can 'copy to curl command' from the chrome inspector's network panel by right clicking on any request!! I want to make a library that reads the curl command (and maybe request syntax?) and outputs a function that will do that command.

https://shibukawa.github.io/curl_as_dsl/

Of course for PHP, you can also just use the curl bindings ;)

Re: Curl, 17 years old today

#68

Post by TazeTSchnitzel »

laumars wrote: post #22
wging wrote: post #2

I'm surprised it's so new. And wget is only a year older... what did people use before then?

Sometimes just plain telnet . It wasn't pretty, but it worked: $ telnet 80 GET / It should be noted that the above isn't a strict HTTP request header, it's missing quite a lot of detail, but it works as an example.

Add two newlines and that is a perfectly valid HTTP/0.9 request.

Re: Curl, 17 years old today

#69

Post by Millennium »

VMG wrote: post #53
cmg wrote: post #52

Earlier quoted context omitted.

Anything that requires JavaScript to fetch and display content.

Well somebody tell Google and Facebook, they're probably missing out on a lot of revenue because of their broken websites.

Website != API. A cleverly-written API can exist in the same space as a Website (even the same URLs, if you differentiate by things like Accept: headers), but they're not the same thing.

It's perfectly acceptable for Websites to include, and even require the use of, JavaScript. It's also perfectly acceptable to offer a JavaScript client for your API. In fact, you pretty much have to do that if you want your Website to work with the API anyway. What's not OK is for an API to require downloading and using additional JavaScript while the API is being used.

As a contrived (and somewhat ludicrous) example, let's say that I queried "http://foo.com/bars" for some kind of collection. It's OK to return the collection. It's even OK to use an HTTP redirect if the collection actually resides elsewhere: HTTP 302, perhaps, with a Location of "http://foo.com.bazes". What's not OK is to return a line of JavaScript reading "window.location = 'http://foo.com/bazes';" which might work for the browser, but wouldn't work for most other clients.

Post reply on HN