Live data from Hacker News

Just Use Curl

justuse.org

101–110 of 154 posts

Re: Just Use Curl

#101

I've been using curl, like forever. I don't understand the preoccupation for using postman, et. al. -- why pay for something that literally requires a little bit of light RTFM?

Using curl, how would I send a collection of frequently used requests to a coworker? Plain text file?

They're put in git. You treat it like any other source. You might even have them as a set of shell scripts.

Re: Just Use Curl

#102
post #60
post #23

Using -X POST is often wrong as it "changes the actual method string in the HTTP request [... and] does not change behavior accordingly" (Stenberg, 2015). Although, it is correct for the article's mention of "Send POST requests"... just that typically people don't send POST requests out of the blue with no data.

I think you misinterpret the text you're quoting (but it's hard to tell since you didn't include a link). -X POST is not wrong, it's just superfluous when using other flags like -d where the method can be inferred. POST requests are often sent with no data (anything that is not idempotent should, unless there's another verb that could fit better).

Here's the article in question. [0] I think runxiyu is correct.

The author delves a bit more into the issue.

> One of most obvious problems is that if you also tell curl to follow HTTP redirects (using -L or --location), the -X option will also be used on the redirected-to requests which may not at all be what the server asks for and the user expected. Dropping the -X will make curl adhere to what the server asks for. And if you want to alter what method to use in a redirect, curl already have dedicated options for that named --post301, --post302 and --post303!

Per the man page (`man 1 curl`),

> The method string you set with -X, --request will be used for all requests, which if you for example use -L, --location may cause unintended side-effects when curl does not change request method according to the HTTP 30x response codes - and similar.

`-d` and `--data` will appropriately change the headers of their requests. Funnily, `--post301` and `--post302` which have a similar effect as `-X POST` are RFC 7231 compliant, browsers just don't do that. [2][3] This is so ubiquitous that the error codes 307 and 308 were added to support the original behavior of repeating the request verbatim at the target address. Compare the following:

    > nc -l -p 8080 -q 1  nc -l -p 8080 -q 1  nc -l -p 8080 -q 1 
What happens here:

1. In the 301 case with just `--data`, the request turns into a GET request when sent to the redirect.

2. In the 301 case with `-X POST`, the request stays a `POST` request, but doesn't send any data to the redirect.

3. Finally, in the case where the server returns a 308, we see the POST request is kept and the data is resent.

To further expand slightly on a different thing that might surprise some people, the data options will automatically set the content type by adding the header, `Content-Type: application/x-www-form-urlencoded`, as if sending form data from a browser. This behvaior can be overridden with a manual `-H`, `--header` argument (e.g., `-H 'Content-Type: application/json`).

Edit: cube00 pointed out that newer versions of curl than mine have `--json` which will do that automatically. [4]

[0]: https://daniel.haxx.se/blog/2015/09/11/unnecessary-use-of-cu...

[1]: https://www.rfc-editor.org/rfc/rfc7231

[2]: https://evertpot.com/http/301-moved-permanently

[3]: https://evertpot.com/http/302-found

[4]: https://news.ycombinator.com/item?id=45655409

Re: Just Use Curl

#103
post #52

Earlier quoted context omitted.

Not to mention saving headers, tokens, doing multiple requests using the results from the previous, etc. This guy would say "just use bash" and ignore the average user experience.

You can do all that in a shell script though

Of course you can, but shell scripting really fucking sucks.

One moment you have a properly quoted JSON string, the next moment you have a list of arguments, oops you need to escape the value for this program to interpret it right, but another program needs it to be double-escaped, is that \, \\, or \\\\? What subset of shell scripting are we doing? Fish? modern Linux bash, macOS-compatible bash? The lowest common denominator? My head is spinning already!

If I want to script something I'm writing Python these days. I've lost too much sleep over all the "interesting" WTF situations you get yourself into with shell scripting. I've never used Hurl but it's been on my radar and I think that's probably the sweet spot for tasks like this.

Re: Just Use Curl

#104

Earlier quoted context omitted.

> Not sure how some developers could be so allergic to the terminal, don't you already spend a lot of time there? Who says I'm allergic to the terminal? I already stated that I use curl. I could also ask why are some developers so allergic to any kind of UI. And they're very vocal about it. Just use whatever you want.

> Who says I'm allergic to the terminal? I already stated that I use curl. Preferring "a couple of clicks" vs "run one command" seems to indicate so, otherwise I'm not sure why'd someone would prefer the former instead of the latter.

I have dozens of collections with hundreds of requests, most sending complex payloads, all perfectly organised hierarchically. I'd rather use a collapsible UI for that, if you prefer to have hundreds of scripts in folders that's fine too.

Actually I don't even create those collections, we have OpenAPI/Swagger docs for all of our APIs and I just import them with a couple of clicks (which I'm sure there's a way to do with curl).

For the odd requests, and sharing requests with others? I use curl, no problem. I actually think I know it pretty well and very rarely need to look up any docs for it.

Re: Just Use Curl

#105
post #93

Earlier quoted context omitted.

curl may be outdated but at least it's a survivor. the alternatives (esp. the suspicious httpie grift) won't make it.

Can you define "the suspicious httpie grif"?

My guess would be they don't like the fact that httpie is branching out to paid (well currently still 0$) GUI desktop/web apps. The CLI still remains under open source under BSD so I think OP is just yelling at clouds here.

Re: Just Use Curl

#106
post #69

Does anyone have suggestions for when I need to use bearer auth and the token is super long? With curl I end up finding the command becomes hard to read, even taking advantage of backslashes. With Postman, it tidily hides the token out of the way on a separate tab and gets out of my way.

What i do is assign the token to a variable. I typically copy the secret to my clipboard, and then use the pbpaste command in macos terminal when assigning it to avoid secrets in my command history.

this.

A while ago I was working on a DSL to solve this exact issue (env switching, http requests + chained requests e.g. to an auth server to retrieve a token) - but I haven't had the time recently, and I moved jobs to a GraphQL shop, so it feels a bit more pointless now :D

Re: Just Use Curl

#107

I might get lit on fire for this, but I don't find manpages very easy to use. If want to quickly remember an option or argument order, I am met with a wall of text. Does anyone have tips for how to make it more useful? Maybe I could grep better for options? For example in the link, the author lists out common curl commands like making a POST request or adding a header. If you tried to look through the manpage for thi…

I actually completely agree. I am learning OpenBSD and the man pages are very good, but all too often I find myself reading them, beating my head against the wall, and then googling or using tdlr or gippity.

For example, I just was digging into BSD_auth and authenticate, and I don't know much about how auth works generally. I found it pretty tough to grok from the man page. I love the idea of learning everything from directly within the system and man pages, but I might just not be smart enough for that.

Re: Just Use Curl

#108

Earlier quoted context omitted.

Basically a shell script with a curl invocation in it, except you need to install extra software to execute it. Misses the point of the article.

I mean, the article did say: It doesn't need to render a fucking Chromium instance to make a web request. It doesn't depend on a service to run. It doesn't require an "Enterprise" subscription for basic features. So I'd say it meets all of the criteria except being on your machine already.

Their words, not mine; the first header: "It's already on your machine". We can belabor it, but the domain is 'justuse'. No room for 'except' [unless you're reasonable, of course].

The 'egregious' things are charging to share what will fit very well in SCM (preventing real automation)... and breaking due to Online First/only. It makes sense to require the endpoint I'm talking to. Why would Postman need AWS/us-east-1 [0] for a completely unrelated API? Joyful rent-seeking.

cURL, your suggestion (hurl), or HTTPie all make far more sense. Store what they need in the place where you already store stuff. Profit, for free: never go down. Automate/take people out of the button-pushing pattern for a gold star.

0: https://news.ycombinator.com/item?id=45645172

Re: Just Use Curl

#110

Earlier quoted context omitted.

Basically a shell script with a curl invocation in it, except you need to install extra software to execute it. Misses the point of the article.

I mean, the article did say: It doesn't need to render a fucking Chromium instance to make a web request. It doesn't depend on a service to run. It doesn't require an "Enterprise" subscription for basic features. So I'd say it meets all of the criteria except being on your machine already.

Yup. Article mentioned `jq` as well. That's an external tool (and so is cURL if we are all being honest here).
Post reply on HN