Curl is just the hobby
daniel.haxx.se
daniel.haxx.se
I think people mostly don't know about Curl and PUT requests, it probably would be a huge waste of money to advertize like this in the wild. Not that I don't think ads are a huge waste in general.
TL;DR on 'why pay to put a curl request on an ad' is what you all have already said -- (1) unique concentration of tech in SF; and (2) to specifically engage software engineers. More on each...
(1) We wouldn't have run this ad in Sydney, or New York, or LA. SF definitely has an uniquely tech-oriented culture, and in particular has lots of startups in our ideal customer persona (ICP) at Stytch - in this case, engineers building B2B SaaS apps.
But in addition to the people who live in SF, even more software engineers visit the city for conferences, or events, or to fundraise. For example, while our ads are up over the next month, SF will host Stripe Sessions and POSTCon (two entire conferences focused around APIs), plus RSA (security focused).
(2) And although even with that, only a small segment of the pop will understand the ads, those people might be intrigued enough to actually look at them - and our ultimate goal is to get more engineers to look at our code & our docs. Another perk is that engineers can't use ad blockers if the ad is on a bus shelter :)
So that was a bit of the thinking for us - on why SF & why a PUT request on a billboard. We're also making the physical ads into an anchor for a 'marketing moment' for Stytch -- so pair offline ads with digital marketing, as well. So if we're successful, maybe you'll see more on that, soon.
I guess it just makes sense sometimes to do weird targeted public ads in specific areas?
I take it you haven't had the pleasure of driving thru Philadelphia. Some say you can even see skyscrapers behind the sea of lawyer ads.
This one got stuck in my mind: https://www.sfgate.com/local/article/anh-phoong-iconic-billb...
I’m glad WA banned them.
Google's {First 10-digit Prime in Consecutive Digits of e}.com ad is a classic in this genre (https://www.hanshq.net/eprime.html)
I occasionally see tech/API ads on the London Underground. You often see ads for all sorts of niches that would probably be smaller than developer and developer-adjacent people.
Just wondering, if the resource ID is known, I thought PUT is the recommended method? We usually use POST for creating a new resource for which you don't know an ID yet.
It's a (C)reate in CRUD, not an (U)pdate.
POST - Create, GET - Retrieve, PUT - Update, DELETE - Delete
CREATE /xxx
READ /zzz
UPDATE /yyy
DELETE /abcd
POST - Create, GET - Retrieve, PUT - Upsert, DELETE - Delete, PATCH - Update
Some APIs us PUT for creating items and let the clients specify the ID. If the IDs are UUIDs, the risk of creating duplicates is so slim that it's neglectable, and if that should happen, it's easy for the client to call again with a different ID. The real advantage of this approach is that if the API call times out, the client can just PUT again without having to fear creating a duplicate record. Recovering from a create with POST that has timed out can be pretty difficult because it can happen that the record was created just fine, but the internet connection died before the OK response reached the client.
The RFC 9110 (and also the old 2616) clearly state PUT is idempotent while POST isn't.
9.3.4 PUT
"The fundamental difference between the POST and PUT methods is highlighted by the different intent for the enclosed representation. The target resource in a POST request is intended to handle the enclosed representation according to the resource's own semantics, whereas the enclosed representation in a PUT request is defined as replacing the state of the target resource. Hence, the intent of PUT is idempotent and visible to intermediaries, even though the exact effect is only known by the origin server."
9.2.2 Idempotent Methods
"Idempotent methods are distinguished because the request can be repeated automatically if a communication failure occurs before the client is able to read the server's response. For example, if a client sends a PUT request and the underlying connection is closed before any response is received, then the client can establish a new connection and retry the idempotent request. It knows that repeating the request will have the same intended effect, even if the original request succeeded, though the response might differ."
- POST: Perform resource-specific processing on the request content.
- PUT: Replace all current representations of the target resource with the request content.
I interpret this as the only immediate side-effect of PUT is supposed to be replacing the target resource with the request content. Everything else is POST, but that does not mean that we can't use POST for everything. Thus, JSON via PUT is not inherently odd at all. Calling a random API using PUT with JSON arguments that executes some code other than replacing a resource, would be odd.
I do think, though, that PUT may very well implicitly create a resource, if the name of that resource is the argument to the put. That is just something that's rather odd, as, often, the server has authority over the names of new resources.
I find PUT particularly helpful, as, given these constraints, I assume that PUT is idempotent; POST is not.
Recommended for what purpose?
The set of recommendations I'm familiar with is:
GET: requests without side effects
POST: requests with side effects
PUT: never use
other: never use
POST gets special treatment from browsers for various security risks. Otherwise, methods don't differ. You can use PUT as part of an effort to feel like you and your server have a secret code, but it's fundamentally the same thing as doing `GET /path/to/resource/put`.See the note here: https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods/GE...
https://datatracker.ietf.org/doc/draft-ietf-httpbis-safe-met...
Meanwhile, POST is generally not considered safe to repeat in case of failure, because the client/proxy does not know where exactly the failure happened and if thus the processing has been already done or not.
But if this is really your concern, you should also be using PUT to create new database records. In principle, those requests are safer to repeat than updates are, since the database will ignore repeated inserts and apply repeated updates. (Though as far as I can tell this only matters if your update adjusts a value rather than setting it outright.)
I don't get it. Isn't an idempotent effect still an effect?
> you should also be using PUT to create new database records.
If the client is free to define the identity, then I do. But if the resource gets e.g. an ID from Postgres sequence, then I need to use POST, because repeated call would create duplicates.
Join us at Stytch (https://stytch.com/careers) if you have a strong opinion so you can decide whether this should be a POST or PUT :)
While it's not my business, I still wonder how this business looks like. Is curl sponsored? If so, is this a common thing for foundational tools alike?
> Just don’t send me private emails about the open source projects I participate in – unless you want to pay for commercial and private support!
So it's support basically, I suppose.
Some sponsorship is through opencollective, which includes transparent information about donations: https://opencollective.com/curl#category-BUDGET
So opencollective has it at $280k USD since sometime in 2018, not bad, that's like half of what the average Googler makes in 1 year (except spread over 5 years).
You can also see there hadn't been many big single donations in 2020 from this post: https://daniel.haxx.se/blog/2020/01/03/curl-receives-10k-usd...
MBA: they must be making 10B$/year?
Engineer: no, this is just a hobby
It's like giving to charity and then being aggravated that it was used to generate lots of money, you can't retroactively change your mind. Although they can always stop updating curl if it is that bad for them.
You are right, but I wanted to show current mindset. Redis, ElasticSearch, Mongo, HashiCorp stack were also FOSS and landscape is changing. Same could have happened to cURL
Once upon a time, even economists thought that automation could make food, shelter, and routine health care too cheap to meter; in such a world would we then be interacting with each other —as the XIX aristocracy did?— chiefly via shared interests and hobbies?
Lagniappe: https://cepr.org/voxeu/columns/downton-abbey-effect-british-...
If he does it without pay but asks afterwards for pay commensurate with delivered value, how much should he be paid?
Who pays it?
That's aggravating. What's the workaround?
edit0: Chrome made more progress, then collided with Vodafone's shitty approximation to infrastructure which is known unsolvable.
edit1: Magic: https://web.archive.org/web/20240422091821/https://daniel.ha...
We are in trouble when some organisation manages to kill archive.org
Most security scanning software will ding any site that doesn't use HSTS
You're probably the target of a MITM attack. Or you've done something weird, like taking a job with an employer that MITMs your web traffic then refusing to install their MITM certificates.
[1] https://www.ssllabs.com/ssltest/analyze.html?d=daniel.haxx.s...
They were complaining that their battery life on their phone just got decimated recently and kept dying over and over. I believe I was helping to troubleshoot, so I had them turn on airplane mode, he flipped it and complaining of something else annoying happening and saying oh yeah my phone airplane mode doesn't work, I still get internet. I was totally baffled, it was all very weird to me.
A little bit of time later that person got busted as a part of a big local drug bust. I'm assuming that's how they tap phones.
It seems Firefox notices this and refuses to contact the site, and Chrome notices this and lets me override, but generally I don't see this failure mode. I wonder what is significant about this particular website.
I unsportingly separate work hardware from personal, no idea if my employer's likely MITM nonsense would have the same behaviour.
Learned something today, albeit with details missing. Oh and Vodafone employee if you're reading this? None of your tech works for shit.
Encrypted transit but you might be talking with the hacker on the other end == worthless.
And with plaintext transit you cannot prove integrity during transit AND also not prove talking with the proper endpoint.
In short: Browser really is warning you that something is fishy. Don’t shoot the messenger.
Firefox makes you fix the root problem.
> That's aggravating. What's the workaround?
Are you aware that you’re possibly being impacted by some kind of MITM attack?
I've been using their CityFibre backed broadband in the UK for about 3 years and really can't complain - £32/month for 900mbit synchronous (which mostly actually lives up) and 4g backup.
I had to call them to remove the "child safe" filters when I first got it, but that's been the case for every ISP or phone provider I've used in the last 20 years. I also run my own DNS which might help, as I've seen others complain about that, but other than those two it's been impressively ignorable.
Discussed on this very site for example back in 2022: https://news.ycombinator.com/item?id=31248250