TG: Programming: Indy Components -- Dead?

Home - Programming - Indy Components -- Dead?

Internet Direct, or Indy, is an open source library of components for building servers and clients of every possible networking protocol. I've used it for the last 25 years on a varieyt of projects. I've donated to the project because it's played such a huge role in my career, and I've recommended it to anyone doing Delphi development. It's high performance, thread safe, and standards compliant.

Now, when I originally posted this, I said some things that may have come across as unkind and ungrateful. So let's try this again.

Or, if you just want to know how it ended, skip to the bottom.

Indy doesn't support TLS 1.3 after all this time, and the branch that supposedly implements support is stuck as a pull request for over a year. That's not only surprising, but it nearly sunk a project I'd put an awful lot of time into.

I estimated the project in part based on the knowledge that I would be using Indy to do simple HTTP requests against a web service. Nothing fancy at all. Three API calls consisting of one GET request and two POST requests. I estimated it for a week, and I thought I'd have a little time to spare for gotchas. Boy was I wrong.

I and two of the client's developers struggled for days to get the customization software to be able to talk to their service. It never did get past the SSL handshake, and the fault lay entirely in the fact that everything in the service stack assumed TLS 1.3 was the minimum supported encryption.

In the end, in a desperate, all-night, programming session, I stitched in support for using the NetHTTP components that come with Delphi's VCL. I have a ton of concerns about using NetHTTP for high volume, multi-threaded, asynchronous projects, but this isn't one of those, so we should be fine. It's doesn't feel fine, though. It's like driving an Indy race car -- no pun intended -- and then finding out on race day that the only tires that will fit the car are out-dated and disqualifying, so you have to drive a Volkswagen instead. So you pop-pop-pop around the circuit, and you know you'll finish the course, but it's ... not cool.

In the hopes that Indy will get that PR pushed through, I made the library to use a configurable option. We'll see what happens...

UPDATE October 12th, 2023

Remy Lebeau responded to my request for a possible ETA on when the TLS 1.3 PR would land, basically saying that there is no ETA and recommending that I use the PR instead. So I pulled the PR, thanked Remy for his advice, and attempted to install and use it. Which turned into an hours-long fiasco. Look, I've been using Delphi since it came out as a beta called AppBuilder, and before that Borland Pascal 5 and 7, and before that Turbo Pascal 3. So I'm no dummy when it comes to this line of products, and I can't get this damned thing to just load the SSL 1.1.1 libraries and work with TLS 1.3. In fact -- this is probably because I'm stuck on Delphi Seattle because I'm cheap and I don't want to pay thousands of dollars to Embarcadero to do what I can do for free with any other compiler -- I can't even get the breakpoints to line up with the code. Yes, I regenerated the DCP files when I rebuilt the BPLs, but it still isn't working. And now... as I type this... Delphi locked up while I was stepping through the misaligned code.

[much profanity]

Okay, so here's the deal. I'm going to kill Delphi's process, and then I'm going to go mow the yard. Because I need a f***ing break...

[mowing sounds]

And I'm back. Here's what finally worked. I deleted the Indy DCUs under Embarcadero\Studio\17.0\lib. All of them. Then I fixed the Tools | Options | Library path to point to the correct directories for the Indy components, because I have them installed in a different directory in an area where I put all my components. Cleaned and rebuilt the Indy BPLs, exited Delphi and started it back up. Basically scorched earth, take no chances. Then I was able to debug and step through the loading of the SSL library.

Turns out, even with all that, it does NOT load Open SSL 1.1.1. I dropped Open SSL 1.0.2 DLLs back into the directory and then hit a REST server that had TLS 1.3 using an TIdHTTP object with an OpenSLL IO handler, and it worked. Not explicitly; there are still no options in the designer for the IO handler for selecting TLS 1.3. But if you're simply connecting with the default settings, it works.

It finally [more profanity] worked.

So a million thank yous to Remy for the Indy library, and thank you Mezen, whoever you are, for doing the work of getting Indy working with TLS 1.3. You guys [just a bit more light profanity] rock.

And I'll keep checking back in from time to time to see if Indy gets the love it deserves and that PR, with the design time updates, finally lands.

UPDATE July 25th, 2024

I was about to add another entry to this site when I realized I never updated this page with the final outcome. Two more projects suddenly started failing when my customers updated their network to use TLS 1.3 certs, and I had to sit down one weekend and switch all my stuff over to a different set of components. For SFTP, I used the TChilkatSFTP class from Chilkat. For HTTP connections I switched to Delphi's System.Net components, specifically TNetHTTPClient, which worked right out of the box. For the low volume of vanilla requests I needed to make, TNetHTTPClient was just fine. I also updated the test tools we use in-house to default to TNetHTTPClient but with the configuration switch to allow testing with Indy as well. I would welcome an up-to-date version of Indy that supports all the protocols in use today, but until that happens at least I can get my job done without losing weeks, and business relationships, trying to convince the current version of Indy to work.