xml aanbieden aan webservice; melding Could not load SSL library

[Walt Duzz]

Ik wil een xml-bestand aanbieden aan een webservice van een derde partij. Omdat dit nieuw voor mij is, ben ik uitgegaan van http://www.nldelphi.com/forum/showthread.php?t=32550.

Op mijn form heb ik naast een idHTTP een idSSLIOHandlerSocketOpenSSL1 geplaatst en als volgt in de code verwerkt:

procedure TXmlSendDlg.BtnSendClick(Sender);
  var
    S_st, O_st :TStringstream;
    XmlStrl, Output : TstringList;
    IdHttp1: TIdHttp;
begin
    
    XmlStrl := Tstringlist.Create;
    Output := Tstringlist.Create;

    XmlStrl.LoadFromFile(XmlSendDlg.XmlFileIn);  // laadt xml in stringlist

    S_st := TStringstream.Create(XmlStrl.text);
    O_st := TStringstream.Create(Output.text);

    IdHttp1:=TIdHttp.Create(nil);
    try
      IdHTTP1.IOHandler := IdSSLIOHandlerSocketOpenSSL1;
      IdHTTP1.HandleRedirects := True;
      IdHTTP1.RedirectMaximum := 100; //waarde > 0
      IdHTTP1.HTTPOptions := [hoInProcessAuth];
      IdHTTP1.ProxyParams.BasicAuthentication := True;
      IdHTTP1.ProxyParams.ProxyPort := 443;
      IdHTTP1.ProxyParams.ProxyUsername := 'Username';
      IdHTTP1.ProxyParams.ProxyPassword := 'password';
      IdHttp1.Request.CustomHeaders.Add('SOAPAction: "'+PaWebserviceOperatie+'"');
      IdHttp1.Request.ContentType := 'text/xml';
      IdHttp1.Post('https://testwebservice.....', S_st, O_st);
      except on E:Exception do Memo1.Lines.Add(E.Message);
    end;

    Memo1.Lines.Add(Output.Text);
    Memo1.Lines.Add('response : ' + IdHttp1.ResponseText);

    IdHttp1.Disconnect;
    FreeAndNil(XmlStrl);
    FreeAndNil(Output);

end; {proc TXmlSendDlg.BtnSendClick}

Secured webadres, username en password etc. zijn zoals opgegeven door de derde partij.

Via http://indy.fulgan.com/SSL/ heb ik van een drietal varianten, dus niet alle, de dll's (libeay32.dll, ssleay32.dll en van de 2008 versies ook zlib1.dll) in de applicatiemap geplaatst. Toch blijf ik de melding Could not load SSL library houden. Als ik libeay32.dll verwijder krijg ik de foutmelding The program can't start because LIBEAY32.DLL is missing..... Dus die dll wordt wèl gevonden (als ik 'm weer teruggezet heb uiteraard). Waarom dan ssleay32.dll niet?

[marcov]

De dlls worden waarschijnlijk dynamisch geladen, en tijdens het dynamisch laden mist een symbool.

Dat kan je waarschijnlijk nalopen (welk symbool) door de relevante idopenssl* code te steppen. Evt kan het ook zijn dat dlls waar ssleay32.dll van afhankelijk is mist.

Dus of missende afhankelijkheden, of een mismatch van versie tussen wat de ladende code verwacht (welke Indy/Delphi versie?), en wat je gedownload hebt.

[Walt Duzz]

Marcov, als ik je tips doorloop krijg ik het volgende:

1. ontbreken/missen symbool tijdens dynamisch laden:
Hoe step ik door de relevante idopenssl* code? Ik heb geen idee. Kun je me daarmee op weg helpen?

2. ontbreken andere dll's:
Als ik libeay32.dll tijdelijk verwijder krijg ik daarop de foutmelding The program can't start because LIBEAY32.DLL is missing...... Dus dat wordt apart gemeld. Bovendien bevatten de meeste zip's op http://indy.fulgan.com/SSL/ maar twee dlls: libeay32.dll en ssleay32.dll. Een enkele (die van 2008) heeft ook zlib1.dll. In ieder geval zet ik alle dll's uit zo'n zip netjes in de applicatiemap, dus dat lijkt me niet de oorzaak.

3. mismatch tussen ladende en gedownloade code:
Voorlopig maakt dit de grootste kans. Uit mijn delphi programma haal ik de volgende info.

Help | About:
CodeGear™ RAD Studio 2007 Version 11.0.2902.10471 Copyright © 2007 CodeGear™. All Rights Reserved.

Help | About | Version Info:
dclIndyCore.dll, 11.0.2804.9245, C:\Program Files (x86)\CodeGear\RAD Studio\5.0\bin\
dclIndyCore100.bpl, 10.0.0.17, C:\Program Files (x86)\CodeGear\RAD Studio\5.0\bin\
dclIndyProtocols.dll, 11.0.2804.9245, C:\Program Files (x86)\CodeGear\RAD Studio\5.0\bin\
dclIndyProtocols100.bpl, 10.0.0.17, c:\program files (x86)\codegear\rad studio\5.0\Bin\
DeployIndy100.bpl, 11.0.2902.10471, C:\Program Files (x86)\CodeGear\RAD Studio\5.0\bin\
IndyCore.dll, 11.0.2804.9245, C:\Windows\assembly\GAC_MSIL\IndyCore\11.0.5000.92 45__02edd786fdd155c5\
IndyCore100.bpl, 10.0.0.17, C:\Program Files (x86)\CodeGear\RAD Studio\5.0\bin\
IndyProtocols.dll, 11.0.2804.9245, C:\Windows\assembly\GAC_MSIL\IndyProtocols\11.0.50 00.9245__02edd786fdd155c5\
IndyProtocols100.bpl, 10.0.0.17, C:\Program Files (x86)\CodeGear\RAD Studio\5.0\bin\
IndySystem.dll, 11.0.2804.9245, C:\Windows\assembly\GAC_MSIL\IndySystem\11.0.2804. 9245__02edd786fdd155c5\
IndySystem100.bpl, 10.0.0.17, C:\Program Files (x86)\CodeGear\RAD Studio\5.0\bin\
Hier worden dus zowel Indy 10 als Indy 11 genoemd. Kan ik hieruit afleiden welke Indy versie ik gebruik?

Bij Project | Options | Directories heb ik onder Search Path opgenomen
c:\Program Files\CodeGear\Rad Studio\5.0\Source\Indy\Indy10\Core;
c:\Program Files\CodeGear\Rad Studio\5.0\Source\Indy\Indy10\Protocol;
c:\Program Files\CodeGear\Rad Studio\5.0\Source\Indy\Indy10\System;
Ik gebruik dus Indy 10, maar kan hieraan niet zien welke versie. Hoe kom ik daarachter?

Op http://indy.fulgan.com/SSL/ kan ik het volgende downloaden:
Friday, September 18, 2009 5:15 PM <dir> Archive
Thursday, June 17, 2010 11:57 AM <dir> Experimental
Sunday, September 14, 2008 8:29 PM 600873 openssl-0.9.8e-i386-win32.zip
Wednesday, September 10, 2008 9:15 AM 822724 openssl-0.9.8h-i386-win32-Indy-IntraWebEdition.zip
Thursday, August 28, 2008 8:49 PM 736064 openssl-0.9.8h-i386-win32.zip
Thursday, August 28, 2008 8:49 PM 1423342 openssl-0.9.8h-win32&win64.zip
Thursday, August 28, 2008 8:49 PM 687300 openssl-0.9.8h-x64_86-win64.zip
Wednesday, September 24, 2008 4:08 PM 723635 openssl-0.9.8i-i386-win32.zip
Wednesday, September 24, 2008 4:09 PM 1400272 openssl-0.9.8i-win32&win64.zip
Wednesday, September 24, 2008 4:09 PM 676659 openssl-0.9.8i-x64_86-win64.zip
Thursday, January 08, 2009 8:47 PM 768888 openssl-0.9.8j-i386-win32.zip
Thursday, January 08, 2009 8:47 PM 1469877 openssl-0.9.8j-win32&win64.zip
Thursday, January 08, 2009 8:47 PM 701011 openssl-0.9.8j-x64_86-win64.zip
Saturday, March 28, 2009 4:36 PM 763018 openssl-0.9.8k-i386-win32.zip
Saturday, March 28, 2009 4:36 PM 701250 openssl-0.9.8k-x64_86-win64.zip
Monday, November 09, 2009 7:56 PM 841156 openssl-0.9.8l-i386-win32-IndyBackport.zip
Monday, November 09, 2009 7:56 PM 753162 openssl-0.9.8l-i386-win32.zip
Monday, November 09, 2009 7:56 PM 703726 openssl-0.9.8l-x64_86-win64.zip
Tuesday, March 09, 2010 1:17 AM 759404 openssl-0.9.8m-i386-win32.zip
Tuesday, March 09, 2010 1:17 AM 708375 openssl-0.9.8m-x64_86-win64.zip
Thursday, June 17, 2010 11:55 AM 851480 openssl-0.9.8o-i386-win32.zip
Thursday, June 17, 2010 11:55 AM 875867 openssl-0.9.8o-x64_86-win64.zip
Tuesday, March 30, 2010 4:24 PM 774381 openssl-1.0.0-i386-win32.zip
Tuesday, March 30, 2010 4:24 PM 864995 openssl-1.0.0-x64_86-win64.zip
Thursday, June 17, 2010 11:55 AM 951675 openssl-1.0.0a-i386-win32.zip
Thursday, June 17, 2010 11:55 AM 1013900 openssl-1.0.0a-x64_86-win64.zip
Een enkele zip bevat een readme.txt met daarin de tekst: requires Indy 10.5.5+. Maar de meeste zips bevatten alleen maar twee kale dll's. Daar valt dus niet uit af te leiden bij welke indy versie welke zip hoort. Bestaat er ergens een volledige matchlijst? Of is dit uitsluitend een kwestie van trial and error?

[VideoRipper]

Origineel gepost door Walt Duzz

Hier worden dus zowel Indy 10 als Indy 11 genoemd. Kan ik hieruit afleiden welke Indy versie ik gebruik?

Zet een Indy-component (bijvoorbeeld TIdSSLIOHandlerSocketOpenSSL of TIdHTTP)
op een (lege) TForm en druk hier met je rechtmuisknop op:



Is er trouwens een bijzondere reden voor dat je die TIdHTTP @runtime aanmaakt?

Greetz,

Peter.

[marcov]

Van wat ik er van weet is er geen echte matchlijst, maar is er zo'n info wel in de fora (newsserver) van indy. Zal echter wat zoeken zijn.

[Walt Duzz]

@ VideoRipper:

Indy versie; dankjewel, zo kan ik tenminste zien dat ik werk met Indy 10.1.5 en die voldoet inderdaad niet aan de http://indy.fulgan.com/SSL/-zip eisen. vanaf de 9.8i is de eis V 10.2.3 (en die loopt t/m 1.0i op tot 10.5.5+). Daarmee kan ik aan het werk. Ik kom daar nog op terug.

reden TIdHTTP @runtime aanmaken je bedoelt de coderegel IdHttp1:=TIdHttp.Create(nil);? Ehh... niet echt bewust. Zoals in m'n eerste post vermeld, 't is helemaal nieuw voor mij. Dus heb ik een stuk code opgevist uit een thread die hopelijk enigszins op mijn probleem lijkt (http://www.nldelphi.com/forum/showthread.php?t=32550). Als ik deze regel weglaat krijg ik de exception : Access violation at address 0080B8F0 in module 'Programname.exe'. Of doel je op een andere coderegel? En hoe zou ik die TIdHTTP anders moeten aanmaken?

@Marcov; naast de readme.txt in de recentere versies van de http://indy.fulgan.com/SSL/-zipfiles kennen veel van de de vroegere zipfiles een buildinfo.txt. Zo kon ik toch nog veel matchen:
9.8i t/m 9.8k : V10.2.3+
9.8l t/m 9.8m : V10.2.5/10.5.5+
9.8o t/m 1.0i : V 10.5.5+

[VideoRipper]

Origineel gepost door Walt Duzz

Als ik deze regel weglaat krijg ik de exception : Access violation at address 0080B8F0 in module 'Programname.exe'.
Of doel je op een andere coderegel? En hoe zou ik die TIdHTTP anders moeten aanmaken?

Dat is logisch omdat die TIdHttp-instantie nu niet meer bestaat (en ja: die regel bedoelde ik).

Je kunt een component op twee manieren instantiëren:

• @Run-time: zoals jij dus eerst deed.
  Dit kan in sommige gevallen een voordeel zijn, maar hier is het niet nodig.
• @Design-time: je zet gewoon een (TIdHttp-) component op je formulier.
  Het voordeel van deze manier is dat je zelf helemaal niets meer hoeft te
  instantiëren of vrij te geven (de applicatie/form doet dat voor je).
  Daarnaast kun je met de Object-inspector de properties van het component
  direct instellen (hoef je dus ook niet meer "Handmatig" in code te doen).
  Je kunt dan dus @designtime ook direct de (SSL) IOHandler er aan koppelen.

Sommige componenten houden er overigens niet van om @runtime aangemaakt
te worden, dus het scheelt ook een heleboel geharrewar.

Eerst dus maar "Even" de laatste Indy10-componenten installeren dus...

Greetz,

Peter.

[Walt Duzz]

Ja, maar die TidHTTP component stond al op m'n formulier. En als ik in dat geval de regel IdHttp1:=TIdHttp.Create(nil) weglaat, dan volgt de Access Violation. Bovendien krijg ik bij het compilen dan ook nog de waarschuwing: [DCC Warning] XmlSend.pas(178): W1036 Variable 'IdHttp1' might not have been initialized.

Maar als ik naast die coderegel ook de definitie

  var
    IdHttp1: TIdHttp;

verwijder, dan is alles OK (dus TidHTTP at design-time geïnstantieerd en géén exception Access Violation of DCC Warning meer).

En die run-time instelling van de properties heeft te maken met het experimentele stadium waarin e.e.a. nu zit. Dan zie ik ze in één oogopslag en kan ik onder elkaar diverse varianten testen. Uiteindelijk verdwijnt alles uiteraard netjes naar de object inspector.

Nu op naar de laatste Indy versie...

[VideoRipper]

Origineel gepost door Walt Duzz

Ja, maar die TidHTTP component stond al op m'n formulier.

Dan heeft het geen zin om hem nogmaals aan te maken @runtime, het gaat zelfs
gigantisch fout als beide (de Var in je procedure en het component dat op je form
staat) dezelfde naam hebben (als de compiler al niet gaat klagen)!

Gebruik dus óf het component @runtime óf het component op het formulier, niet beide
(of geef ze in ieder geval niet allebei dezelfde naam).

De designtime-manier heeft de voorkeur: stel deze in met de properties zoals
ze in je procedure staan (voor zover mogelijk):


Haal vervolgens alles weg wat niet (meer) in de procedure thuishoort.

Delphi Code:

1. Procedure TXmlSendDlg.BtnSendClick(Sender : TObject);
2. Var
3.   S_st,
4.   O_st    : TStringStream;
5.   XmlStrl,
6.   Output  : TStringList;
7. Begin
8.   XmlStrl := TStringList.Create;
9.   Output  := TStringList.Create;
10.   Try
11.     XmlStrl.LoadFromFile(XmlSendDlg.XmlFileIn);  // laadt xml in stringlist
12.  
13.     S_st := TStringStream.Create(XmlStrl.Text);
14.     O_st := TStringStream.Create('');
15.     Try
16.       IdHttp1.Request.CustomHeaders.Add('SOAPAction: "'+ PaWebserviceOperatie + '"');
17.       Try
18.         IdHttp1.Post('https://testwebservice.....', S_st, O_st);
19.       Except
20.         On E:Exception Do
21.           Memo1.Lines.Add(E.Message);
22.       End;
23.  
24.       Memo1.Lines.Add(Output.Text);
25.       Memo1.Lines.Add('Response : ' + IdHttp1.ResponseText);
26.  
27.       IdHttp1.Disconnect;
28.     Finally
29.       O_st.Free;
30.       S_st.Free;
31.     End;
32.   Finally
33.     Output.Free;
34.     XmlStr1.Free;
35.   End;
36. End; {proc TXmlSendDlg.BtnSendClick}

Ruim ook alle rommel op die je zelf gemaakt hebt: je kreeg op jouw manier verschrikkelijk
veel geheugenlekken omdat je wel allerlei TStringStreams aanmaakt, maar ze na
gebruik niet meer vrijgeeft

Overigens zou ik zelf gewoon gebruik hebben gemaakt van een enkele TFileStream
of TMemoryStream, dan de omweg om eerst de XML in een TStringList te laden
en die vervolgens toe te wijzen aan een TStringStream, maar dat is een oefening
voor een volgende keer.

Verder valt het mij op dat je wel Proxy-gegevens invoert (Username, Password), maar
geen Proxy-server adres
Misschien was je het vergeten in te vullen in jouw voorbeeld boven, maar volgens mij
gebruik je geen proxyserver en heb je gewoon de verkeerde properties gebruikt en moet
je eigenlijk de .Request.Username en .Request.Password properties hebben

Als toegift nog mijn implementatie van jouw code (met een aantal onnodige zaken
verwijderd en veranderd):

Delphi Code:

1. Procedure TXmlSendDlg.BtnSendClick(Sender : TObject);
2. Var
3.   Return : String;
4.   XMLStr : TFileStream;
5. Begin
6.   XMLStr := TFileStream.Create(XmlSendDlg.XmlFileIn,
7.                                fmOpenRead Or fmShareDenyWrite);
8.   Try
9.     IdHttp1.Request.CustomHeaders.Clear;
10.     IdHttp1.Request.CustomHeaders.Add('SOAPAction: "' +
11.                                       PaWebserviceOperatie + '"');
12.     Try
13.       Return := IdHttp1.Post('https://testwebservice.....', XMLStr);
14.     Except
15.       On E:Exception Do
16.         Memo1.Lines.Add(E.Message);
17.     End;
18.     Memo1.Lines.Add(Return);
19.     Memo1.Lines.Add('Response: ' + IdHttp1.ResponseText);
20.   Finally
21.     XMLStr.Free;
22.   End;
23. End; {proc TXmlSendDlg.BtnSendClick}

Greetz,

Peter.

[Walt Duzz]

VideoRipper, bedankt voor de service.

1. Moet ik niet in jouw laatste codevoorbeeld voor de Finally de regel IdHttp1.Disconnect; plaatsen?

2. De ProxyServer kwam bij mij in beeld omdat ik moet aanleveren via TCP-poort 443 en ik alleen bij ProxyParams.ProxyPort een property met een poort tegenkwam. Maar klopt het dat ik via poort 443 kan posten met IdHttp1.Post(PaWebsiteTest + ':443', XMLStr);?

[VideoRipper]

1. HTTP- en HTTP-verbindingen zijn niet constant actief zoals bijvoorbeeld een FTP-verbinding is.
   Dit betekent dat er bij iedere "Request" een nieuwe verbinding wordt opgezet, data wordt
   verzonden/ontvangen en weer wordt afgesloten.
   Je hoeft dus niet "Handmatig" de verbinding te verbreken na iedere overdracht.
2. HTTPS-verbindingen worden standaard over poort 443 gedaan, dus hoef je deze poort niet
   op te geven in je URL (tenzij je een afwijkende poort gebruikt).
   Je kunt in de IdHTTP.pas-source zien (in TIdCustomHTTP.PrepareRequest) hoe de host en
   poort uit elkaar worden gerafeld.
   Maar het kan geen kwaad om de poort expliciet te vermelden, uiteraard.

Greetz,

Peter.

[marcov]

Volgens mij wordt sinds Http 1.1 de connectie wel herbruikt. De connectie blijft nog typisch de TCP/IP timeout (6 of 8 minuten geloof ik), en een nieuwe request herbruikt de connectie.

Je kan dat ook makkelijk zien door op elk OS "netstat -a" in de terminal te tikken. Dan zal je daar ook allerlei sites zien, terwijl je op dat moment niks aan het laden bent.

Maar het resultaat is wel hetzelfde, op request niveau hoef je je er niet druk om te maken.

[VideoRipper]

Het zou zomaar kunnen, marcov; ikzelf ben echter nooit problemen tegengekomen

Maar mocht je er "Een vreemd gevoel van binnen" aan overhouden, mag je natuurlijk altijd
de extra IdHttp1.Disconnect regel toevoegen aan de code, het kan geen kwaad

[Walt Duzz]

Met dank aan VideoRipper heb ik nu de volgende

procedure TXmlSendDlg.BtnSendClick(Sender: TObject);
Var
  ReturnStr : String;
  XMLStr : TFileStream;
Begin
  with ThisLvr2^ do begin
    XMLStr := TFileStream.Create(XmlSendDlg.XmlFileIn,
                                 fmOpenRead Or fmShareDenyWrite);
    Try
      IdHTTP1.Request.Username := PaWebserviceUsername;
      IdHTTP1.Request.Password := PaWebservicePassword;
      IdHttp1.Request.ContentType := 'text/xml';
      IdHttp1.Request.CustomHeaders.Clear;
      IdHttp1.Request.CustomHeaders.Add('SOAPAction: "' + PaWebserviceOperatie + '"');
      Try
        ReturnStr := IdHttp1.Post(PaWebsiteTest, XMLStr);
      Except
        On E:Exception Do
          Memo1.Lines.Add('Fout: ' + E.Message);
      End;
      Memo1.Lines.Add(ReturnStr);
      Memo1.Lines.Add('Response: ' + IdHttp1.ResponseText);
      IdHttp1.Disconnect;
    Finally
      XMLStr.Free;
    End;
  end;
end; {proc TXmlSendDlg.BtnSendClick}

Inmiddels heb ik mijn project overgezet van D2007 naar D2010 en daar zit Indy 10.5.5 standaard bij. Dus van http://indy.fulgan.com/SSL/-zipfiles de laatste ssl-versie opgehaald. De Readme van deze versie (OpenSSL v1.0.0a, Precompiled Binaries for Win64, Released Date: June 17 2010) eist Indy SVN 10.5.5+.
De hierbij meegeleverde libeay32.dll, ssleay32.dll en voor de zekerheid ook maar OpenSsl.Exe in mijn applicatiemap geplaatst, maar helaas levert bovenstaande code weer de melding: Could not load SSL library.

@Marcov, Terugkomend op je eerdere tips betreffende

1. mismatch tussen ladende en gedownloade code: dat lijkt mij nu uitgesloten (ik werk met Windows7 - 64). Of zie ik iets over het hoofd?

2. het ontbreken/missen symbool tijdens dynamisch laden:
Hoe step ik door de relevante idopenssl* code? Ik heb geen idee. Kun je me daarmee op weg helpen?

[marcov]

Je hebt een win32 applicatie, en moet dus win32 dlls hebben. Win64 dlls zijn voor native 64-bit applicaties en dat kan delphi niet.