[HN Gopher] Append data to the url query
___________________________________________________________________
Append data to the url query
Author : soheilpro
Score : 66 points
Date : 2022-11-10 12:59 UTC (10 hours ago)
(HTM) web link (daniel.haxx.se)
(TXT) w3m dump (daniel.haxx.se)
| cdelsolar wrote:
| curl is amazing. I thought I'd read somewhere that it's on Mars.
| kh1 wrote:
| When I use curl, it's mostly when I need to check header or to
| trace requests in the network, for which I just use -vvv. Simple
| one-off stuff.
|
| So I wonder how much demand there actually is for advanced
| features like this. When I need to make POST requests with
| queries and data, I would just use python because I most likely
| need to process the response (parse html, store json output to
| database, etc.).
|
| Adding advanced features are nice, but IMO this might lead to
| over-engineering and it might be hard to maintain down the line.
| chrsig wrote:
| > Adding advanced features are nice, but IMO this might lead to
| over-engineering and it might be hard to maintain down the
| line.
|
| curl's not exactly a new project -- this is 'down the line' for
| it.
|
| I personally welcome the change. I wont use it often, but when
| I will, I'll be quite happy that it's there. There are a number
| of other features I'd give up in it's stead.
| silverwind wrote:
| curl inferring the HTTP method from options is just bad design.
| It should have always been explicit via `-X`, but weirdly enough
| it sometimes warns when using that option.
|
| Also, it seems some curl behaviours live in the past where only
| GET and POST verbs exists, ignoring others like PUT and PATCH.
| chrsig wrote:
| They didn't live in the past when implemented :)
|
| Backwards compatibility is a wonderful thing, but leads to
| anachronisms 20 years later.
|
| `-X` exists for anyone that doesn't want curl's divination
| pmoriarty wrote:
| Daniel Stenberg, curl's lead developer, made a good tutorial
| video[1] on curl, focusing on advanced use of its HTTP options.
|
| Here are some org-format notes I took on curl, mostly from the
| contents of that video: [2]
|
| [1] - https://www.youtube.com/watch?v=I6id1Y0YuNk
|
| [2] - https://paste.grml.org/plain/3559
| jrochkind1 wrote:
| > This is curl's 249th command line option
| nickcw wrote:
| This made me smile!
|
| And also $ rclone help flags . | grep "^ *--"
| | wc -l 665
|
| (yes rclone has a command to grep its flags `rclone help flags
| <regex>`!)
| ape4 wrote:
| The article says the new option replaces the -G option. But, of
| course, for compatibility they cannot remove -G.
| ainar-g wrote:
| Almost quarter of a thousand. Yay!
|
| That does raise an interesting question though. If one wanted
| to create a command-line tool (or, rather, toolset) as
| comprehensive as curl, but with a much smaller API surface, how
| would they go about it? Sure, some of these flags are just
| shorthands, and some of them could be removed entirely (-o -
| stdout redirection), but that still leaves a lot of options.
| jrochkind1 wrote:
| Curl is really really big on backwards compatibility, which I
| don't mean to critisize.
|
| If you were starting over from scratch even trying to make it
| curl-like, you could probably trim down the options
| substantially.
|
| The OP is in fact an example of a new option that can more-
| or-less cover the same functionality as some old options,
| plus more, but the old options remain.
| mmh0000 wrote:
| Ah. But -o is useful.
|
| What if I'm running curl directly without a shell (e.g. in a
| container). How else would I save the output to a file?
| thih9 wrote:
| wget ;)
| bombcar wrote:
| On some systems without wget I have to alias wget to curl
| -o or whatever it is.
| tyingq wrote:
| Curl supports a lot of crazy stuff that adds command line
| options, like IMAP/LDAP/POP3/SMTP means adding --login-
| options, --mail-auth, --mail-from, --mail-rcpt-allowfails,
| --mail-rcpt. If you read the man page, you'll find other
| flags that aren't really central to a http(s) fetch tool,
| like ftp, tftp.
| pjc50 wrote:
| How would you keep it there? You'd have to spend a lot of
| effort discouraging feature requests.
| danuker wrote:
| You don't need to discourage them. Just ignore them.
|
| Perhaaps take a look at the most popular ones every now and
| then, but a free software project owes the world nothing.
| thih9 wrote:
| In theory yes.
|
| In practice I assume (I have no practical experience)
| that as the project gets larger the number of involved
| parties grows. And suddenly you need to balance interests
| of not just you but also the community, contributors,
| large users, sponsors and possibly more.
| pablobaz wrote:
| I wonder will they have a party when they hit 250?
| danuker wrote:
| I would do it at 256
| UI_at_80x24 wrote:
| Wow. Every time I've tried to dig into the man pages to find an
| option that I need it's been overwhelming; and now I know why!
|
| This is one seriously under appreciated piece of code, and I am
| so grateful that it exists.
| bpoyner wrote:
| They changed the curl man page in the last year so that all
| options have 'see also' recommendations. The documentation is
| amazing.
|
| https://twitter.com/bagder/status/1460867775690387457
| csours wrote:
| I thought this was going to be about base64 encoded json query
| param(s) - instead of posting base64 or making a bunch of
| different params, do a GET with one param of base64 encoded json.
| Easy for the client, easy for the server, easy to share, only
| downside that I see is that it makes things a bit obtuse for
| users, but an extension or browser affordance could fix that.
| rpastuszak wrote:
| If you're into this stuff, you might enjoy my "Twitter as a CDN
| tool", here's pong in a single Tweet:
| https://twitter.com/rafalpast/status/1316836397903474688
|
| > Easy for the client, easy for the server, easy to share, only
| downside that I see is that it makes things a bit obtuse for
| users
|
| There are more downsides:
|
| - processing and creating payload can be harder are you're
| passing plaintext w. ca. 30% size increase on average
|
| - base64-encoded assets (e.g. SVGs) would cause a huge
| performance drop in WebKit (this probably has improved since
| the last time I ran benchmarks).
|
| - since you're encoding content and not its location, you can't
| easily update the underlying resource (hence to update my
| version of Pong, I'd need to create a new unique URL). IIRC
| IPFS suffers (used to?) from a similar issue
|
| - not an issue now, but still was 1-2 years ago: some browsers
| would allow only for 2 or 4kb of text in URL
| csours wrote:
| Hah, that Twitter thing is neat.
|
| > not an issue now, but still was 1-2 years ago: some
| browsers would allow only for 2 or 4kb of text in URL
|
| Yes, I had in mind smaller payloads, things that would have
| been query params on a GET
| r_c_a_d wrote:
| Yes, I think this is how Wordle did the migration to NY Times
| without losing game history. The original site did a redirect
| to nytimes.com/something/wordle?data=X where X was the game
| history. Quite clever, I thought.
___________________________________________________________________
(page generated 2022-11-10 23:01 UTC)