-
Notifications
You must be signed in to change notification settings - Fork 23
1) How was curl4delphi created?
2) But there’s Indy in Delphi…
Curl4delphi was created for one private project that coped with a REST service. “Too clever” Indy “managed” to fail without apparent reason and (in older versions) hid 400/403 bodies without a chance to retrieve them (the service is rather verbose and leaves a clue what’s wrong). So curl.exe became a temporary solution for failed requests (those which didn’t fail still used Indy). In a weekend I wrote a wrapper for libcurl that later evolved into curl4delphi.
Of course, I didn’t discard Indy forever, and HMAC authentication for that service is taken from Indy.
Why does ICurl.Clone keep input/output/header streams in such a state?
Because streams are one-per-object. You should anyway recreate and replace everything that contains streams. Warning: including ICurlForm with file uploads — as cURL does not support Unicode, I’m forced to emulate it via TFileStream.
But cacert.pem can be at Unicode path…
A dependent library, OpenSSL, supports Unicode. cURL itself does not.
Why don’t you localize ICurlForm errors?
Because only one of them — not enough memory — is a programmer-independent runtime problem. The rest are programming overlooks.
In some languages (Java) there is a concept named checked exceptions. It mostly proved wrong (no one knows which exceptions the callback throws), but that’s not the matter. Every line that contains division can divide by 0, every line that allocates something can run out of memory, every line that uses operator[] can exceed the range. Such exceptions can not be checked by definition — and if they occur, the program is probably in a great trouble. All ICurlForm errors belong to this type, and, in my opinion, there’s no point to localize them.