How can I get Delphi XE2 to talk to Google Calenda

Question

It's time for this question again, but this time with Delphi XE2.

I am using the Indy version 10.5.8.0 that ships with XE2, and I have tried four different versions of the SSL dlls. I have tried 1.0.x latest, and about 3 different 0.9.8 versions (e,h,x,....).

None of them works, when communicating to https:// urls at calendar.google.com. The author of the Delphi Google Calendar component at "Sync-components.com" ships his own binary openssl DLL runtimes that have no version information in it, but it seems to be a very small, very old version of SSL libs older than 0.9.8. The author of the component says only his private unversioned DLLs are known to work. I can't believe that. Surely at least one version of the openSSL dlls works well enough with Delphi XE2 to connect to Google Calendar.

In order to get his custom ancient DLL to load into Indy 10 in Delphi XE2, he modifies IdSSLOpenHeaders.pas method Load, like this, at the end:

 function Load: Boolean;
 begin
   /// ... lots of stuff
   //Result := (FFailedFunctionLoadList.Count = 0); // original.
   Result := (FFailedFunctionLoadList.Count <= 18); // changed to.
 end;

Of course, the component that I am evaluating does not work in XE2, but I suspect it's the brokenness of either (a) this particular snapshot of Indy 10 that ships with XE2, or (b) the fact that the World of SSL DLLs is a veritable hell of "broken for you but works for me" different versions.

What do I have to do to get an SSL connection to Google Calendar, using Indy (or any other delphi component library with SSL support), in Delphi XE2?

Alternatively, if anyone has a google calendar API implementation that works with anything other than Indy that I could use for testing, I would appreciate links and pointers.

Answer 1

There is something wrong with the snapshot of Indy10 that ships with XE2, in that the idHTTP object appears not to work well with any of the OpenSSL dlls I found, in that I could not communicate with any Google Calendar server services with them.

The actual underlying nature of the problem seems to be that Indy doesn't handle HTTP redirects as transparently as we might have hoped. The code that is manipulating Indy (third party component) does some really hard to understand things with the Indy "http redirect" handling logic that appears to be a set of workarounds, that don't work. What is furthermore confusing, is that the exact places in the code where HTTP redirects occur varies from one person testing Google Calendars, to another, so these redirect glitches do not always appear in the same places for each person testing it.

Note that the login method, and method to get the calendars worked. But the methods and code that were to read events, seem not to work. I was unable to figure out the difference between the two, but the code I am using is commercial and I can't post any of it. I will update this message if I ever figure out the actual technical reason that the HTTP get request was returning "0 bytes" in its response for urls like this:

https://www.google.com/calendar/feeds/firstname.lastname%40gmail.com/private/full?max-results=100000

Those zero byte results were really HTTP 302 redirect response code, which the code I was using, did not check for or expect. It was expecting Indy to automatically handle redirects.

The problem could either that Indy10 version is very specific and only works with a version of the openSSL dlls that I didn't happen to find in my searching today, or that the Indy10 version that ships with XE2 doesn't work with ANY version of the OpenSSL dlls that I could find, at least not when the target it's talking to is google's HTTPS calendar servers.

The code I am running creates an IdHTTP object with a TIdSSLIOHandlerSocketOpenSSL.

This works in all versions of Delphi up to and including XE, but breaks with a factory XE2 system, due to the Indy version shipping with XE2.

The only fix I have found is to install a new nightly build of Indy, I grabbed 4760, which appears to work fine, when combined with OpenSSL dll version 1.0.1.

It looks to me like using OpenSSL with Delphi XE2 is a bit difficult out of the box. A huge thank you to the Indy team for working so hard.... But can someone please help them out? This is really a great project and a great product, but when it breaks, and when you have to follow a moving standard (like the openSSL implementation), perhaps a bit more documentation, and testing, and eyeballs would help. I stand ready to assist if anybody can show me how I could help out. The problems with SSL are not indy-specific, as I notice that other component vendors and open source people have specific versions of the OpenSSL dlls that they support or don't support.

Another sad things I learned today: Some of the installers from OpenSSL install their DLLs by default (without warning) into your windows System32 directory, causing not only your app, but others, like TortoiseHG and TortoiseSVN, to perhaps break. If you didn't have a big problem with SSL before you started playing around, you could easily make it worse if you install a bunch of installer-versions from the OpenSSL website.