-2

The following code works as shown, but not with the commented out URL.

Can you see my error?

var
  IdHTTP1: TIdHTTP;
  sl: TStringList;
  Src : string;
  LHandler: TIdSSLIOHandlerSocketOpenSSL;
begin
  try
    IdHTTP1 := TIdHTTP.Create(nil);
    try
      LHandler := TIdSSLIOHandlerSocketOpenSSL.Create(nil);
      try
        IdHTTP1.IOHandler := LHandler;
        Src := IdHTTP1.Get(TIdURI.URLEncode(
          //'https://geocoding.geo.census.gov/geocoder/locations/onelineaddress?address=4600+Silver+Hill+Rd%2C+Suitland%2C+MD+20746&benchmark=9&format=json'
          'https://tools.usps.com/go/ZipLookupResultsAction!input.action?resultMode=0&companyName=&address1=1600+PENNSYLVANIA+AVE+NW&address2=&city=&state=Select&urbanCode=&postalCode=&zip=20500'
        ));
        ShowMessage(Copy(src, 1, 100));
      finally
        LHandler.Free;
      end;
    finally
      IdHTTP1.Free;
    end;
  except
    on E: Exception do
      ShowMessage('e');
  end;
  ShowMessage('done');
end;

The commented out URL raises an exception:

EIdOSSLUnderlyingCryptoError: Error connecting with SSL. Error connecting with SSL. error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure

Remy Lebeau
  • 555,201
  • 31
  • 458
  • 770
kualoa
  • 17
  • 1
  • 4
  • 1
    *"Not working as expected"* - So what did you expect and what did it actually do? – GolezTrol Aug 16 '17 at 13:13
  • 1
    -.- And what is the exception? (tip: change `showmessage('e')` into `raise`). – GolezTrol Aug 16 '17 at 13:18
  • EIdOSSLUnderlyingCryptoError: Error connecting with SSL. Error connecting with SSL. error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure – kualoa Aug 16 '17 at 13:25
  • So it's an SSL 3 error. Funny, just [closed a similar one](https://stackoverflow.com/questions/45713778/file-get-contents-error-when-trying-to-fetch-html-of-https-site) for PHP. :) Anyway, although this error may look confusing, it is actually relevant and it tells you that it's the SSL part that's causing the error rather than the URL encoding. I guess the other server doesn't use SSL3. – GolezTrol Aug 16 '17 at 13:38
  • I don't know if the answer is in there, but do check out [this question](https://stackoverflow.com/questions/32865724/tidhttp-weird-sslv3-read-bytes-error-with-directly-set-up-tlsv1-2-connection) and [this one](https://stackoverflow.com/questions/26469274/ssl-v3-poodle-and-move-to-tls-with-indy). – GolezTrol Aug 16 '17 at 13:40
  • 2
    This demonstrates that it is important to read error messages. Don't just ignore their contents. They usually contain valuable information. How can you expect to debug without gathering facts? – David Heffernan Aug 16 '17 at 14:09
  • It also demonstrates the importance of debugging. So many questions here are from askers who have not performed any debugging. As is this one. You assumed that the error was in `TIdURI.URLEncode` but the error message makes it clear that it's from `IdHTTP1.Get`. – David Heffernan Aug 16 '17 at 15:46
  • 1
    If you were a mechanic, and I brought my car to you and said "Engine has error, please fix it", would you be able to guess that my problem is a rattle under the hood? – Jerry Dodge Aug 16 '17 at 16:16

1 Answers1

1

The two URLs you have shown are already url-encoded, so you should not be passing them to TIdURI.URLEncode() at all, just pass them as-is to TIdHTTP.Get(). That being said, make sure you are using an up-to-date version of Indy so that you have this bug fix to avoid double-encoding any sequences that are already percent-encoded.

In any case, the problem you are having is not related to the URL encoding. The cause of the SSL alert error is that TIdSSLIOHandlerSocketOpenSSL enables only TLS 1.0 by default, but many modern web servers are slowly moving away from TLS 1.0 and now require TLS 1.1+. geocoding.geo.census.gov won't work with anything less than TLS 1.2, whereas tools.usps.com still allows TLS 1.0. Modern web browsers support TLS 1.0+.

So the fix is to enable TLS 1.1 and TLS 1.2 in the TIdSSLIOHandlerSocketOpenSSL.SSLOptions.SSLVersions property 1.

1: I have opened a ticket in Indy's issue tracker to enable TLS 1.1+ by default in a future release.

Remy Lebeau
  • 555,201
  • 31
  • 458
  • 770
  • 1. don't assign both `Method` and `SSLVersions` together, assign one or the other. Assigning one automatically updates the other for you. 2. If your version of Indy 10 does not have `sslvTLSv1_2` then you are using a very outdated version and need to upgrade, which you would have to do anyway to support the latest OpenSSL. – Remy Lebeau Aug 17 '17 at 00:10
  • @kualoa: you have to use the correct OpenSSL version based on how your app is compiled (32bit or 64bit), not based on what OS version you are running on. And you can get precompiled OpenSSL DLLs for Indy at http://indy.fulgan.com/SSL – Remy Lebeau Aug 17 '17 at 13:50
  • @kualoa: all of the downloads have OpenSSL version numbers and platform names in their filenames. It is not that hard to figure out which one to use - `win32` for 32bit, `win64` for 64bit. The latest version of OpenSSL that is supported by Indy is 1.0.2. The latest DLLs provided on Fulgan are for OpenSSL 1.0.2l (aka 1.0.2.12). Best place to put the DLLs is in the same folder as your app's executable. – Remy Lebeau Aug 17 '17 at 19:16
  • @kualoa: 0.9.8 is a very old version of OpenSSL. You should be using 1.0.2 instead. In any case, the "unidentified identifier" error has nothing to do with the version of the OpenSSL DLLS you use, it has to do with the version of Indy you are using. As I told you earlier, "*you are using a very outdated version [of Indy] and need to upgrade*". Please [download the latest version of Indy 10](http://www.indyproject.org/Sockets/Download/DevSnapshot.aspx) and read the [Indy 10 Installation Instructions](http://www.indyproject.org/Sockets/Docs/Indy10Installation.aspx). – Remy Lebeau Aug 18 '17 at 00:01
  • Remy, can you show me where is the latest version of Indy now? Most links are not available now. Thanks – FZS Jun 28 '22 at 14:07
  • @FZS https://www.indyproject.org/2021/02/10/links-to-old-indy-website-pages-are-currently-broken/ – Remy Lebeau Jun 28 '22 at 15:58