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

Curl is just the hobby

daniel.haxx.se

Post reply on HN
Print view View original

51–60 of 90 posts

Re: Curl is just the hobby

#51

Post by Nextgrid »

talkin wrote: post #37
JonChesterfield wrote: post #21

Earlier quoted context omitted.

You don't see why Firefox refusing to connect would be annoying? I don't care whether the blog about curl is encrypted in transit or not and I do care about a forced change to chrome to see the content.

Common misconception, but Https / TLS provides a combination of gaurantees, and the one cannot work without the other: 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 messenge…

I think his complaint is that HSTS also prevents the user from overriding it and Firefox is complying, which I agree is a bit annoying.

Re: Curl is just the hobby

#52

Post by ascar »

andrewfromx wrote: post #43
sublinear wrote: post #12

Earlier quoted context omitted.

Auth requests are for a new session ID, not a new user ID. It's a (C)reate in CRUD, not an (U)pdate. POST - Create, GET - Retrieve, PUT - Update, DELETE - Delete

how can you leave out PATCH? POST - Create, GET - Retrieve, PUT - Upsert, DELETE - Delete, PATCH - Update

It's not part of RFC 9110, so why should it be included?

Re: Curl is just the hobby

#53

Post by KptMarchewa »

antsar wrote: post #45
KptMarchewa wrote: post #14

Earlier quoted context omitted.

I've travelled to SF (from Poland) and this has struck me too, together with lawyer ads.

> lawyer ads 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.

Nope, just NYC and California.

This one got stuck in my mind: https://www.sfgate.com/local/article/anh-phoong-iconic-billb...

Re: Curl is just the hobby

#54

Post by dools »

vermilingua wrote: post #6

Off topic but I find it wild that SF has API ads on bus shelters. Is that unusual/right in a dev hotspot, or have I been well underestimating just how intrinsic the tech culture is there? (I’m an Australian, so I guess my question applies to the US as much as SF)

Twilio famously had billboards that just said “ask your developer” in SF

Re: Curl is just the hobby

#55

Post by janaagaard »

sublinear wrote: post #12
throwaway_4228 wrote: post #8

> I would personally perhaps protest against the use of PUT for POSTing JSON, but nobody asked me. 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.

Auth requests are for a new session ID, not a new user ID. It's a (C)reate in CRUD, not an (U)pdate. POST - Create, GET - Retrieve, PUT - Update, DELETE - Delete

The difference between PUT and POST is weather the command is idempotent or not.

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.

Re: Curl is just the hobby

#56

Post by eptcyka »

thaumasiotes wrote: post #44
eptcyka wrote: post #38

Earlier quoted context omitted.

PUT's can have request bodies, GETs can not.

Incorrect; GET requests are free to have bodies. See the note here: https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods/GE...

Also see the first row in the table on that page.

Re: Curl is just the hobby

#57

Post by gryn »

vermilingua wrote: post #6

Off topic but I find it wild that SF has API ads on bus shelters. Is that unusual/right in a dev hotspot, or have I been well underestimating just how intrinsic the tech culture is there? (I’m an Australian, so I guess my question applies to the US as much as SF)

I saw ads recruiting devs for a bank or something on the metro here in paris. It was a weird thing that caught me off guard but they kinda make sense since a lot of working people use public transport here. Maybe it's the same reasoning here?

Re: Curl is just the hobby

#58

Post by ascar »

janaagaard wrote: post #55
sublinear wrote: post #12

Earlier quoted context omitted.

Auth requests are for a new session ID, not a new user ID. It's a (C)reate in CRUD, not an (U)pdate. POST - Create, GET - Retrieve, PUT - Update, DELETE - Delete

The difference between PUT and POST is weather the command is idempotent or not. 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 P…

Aren't you basically describing that you want idempotency?

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."

Re: Curl is just the hobby

#59

Post by [deleted] »

hkwerf wrote: post #13
throwaway_4228 wrote: post #8

> I would personally perhaps protest against the use of PUT for POSTing JSON, but nobody asked me. 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.

According to RFC 9110: - 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 PU…

[deleted]

Re: Curl is just the hobby

#60

Post by ascar »

plextoria wrote: post #30
sublinear wrote: post #12

Earlier quoted context omitted.

Auth requests are for a new session ID, not a new user ID. It's a (C)reate in CRUD, not an (U)pdate. POST - Create, GET - Retrieve, PUT - Update, DELETE - Delete

PUT can be used for Create too, if the user ID is generated by the client

According to the RFC's PUT can be used to create a resource as long as the request has a clear target. That doesn't necessarily mean an ID, but just some kind of identifier (composite key, hash of content, url, etc.). When a create instead of update happens the server should respond with a 201 CREATED, which should indicate the location or identifier of the created resource.
Post reply on HN