Indy 10 HTTP(S) Protokoll

[Christoph64]

Hallo,

ich bin neu hier, deswegen weiss ich nicht, ob es noch Sinn macht auf ein so altes Thema zu antworten, aber ich versuche es einfach mal. Vielleicht kann mir ja einer weiterhelfen.

Ich versuche mit der neusten Delphi version Tokio 10.2 eine Anwendung zu Programmieren, die eine HTTPS Webseite liest, was ich aber leider nicht hinbekomme. Es liegt wohl auch daran das mir das basis wissen dazu fehlt. Ich kann problemlos eine HTTP Seite mit derr Anwendung lesen.

Kann mir jemand weiterhelfen ?
Eine Frage z.B habe ich, benötige ich bei Delphi 10.2 immer noch die libeay32.dll und ssleay32.dll Bibliothek, oder sind die mitlerweile im Delphi integriert.

Wäre nett, wenn ich eine info bekommen würde.

[Redeemer]

Seit XE8 gibt es System.Net.HttpClientComponent.TNetHTTPClient, der eine Windows-API verwendet. Bei einfachen GET-Requests würde ich Vcl.ExtActns.TDownloadURL benutzen, das es seit Urzeiten gibt und einfach zu verwenden ist.

Indy benötigt weiterhin OpenSSL.

[KodeZwerg]

Eine ganz brauchbare Resource für OpenSSL mit anderen Libraries findest Du hier.

Ich selbst habe auch positive Erfahrung mit der Overbyte (ICS) Variante gemacht, falls einem pures Indy zu wenig bietet/zu schwer ist einzusetzen, da ist eine sehr steile Lernkurve bei wenig Programmierung geboten. Also falls alle Stricke reißen, einfach mal da reinschnuppern, ist sehr Neueinsteiger-freundlich will ich damit sagen.

Das hier zugrunde liegende Tutorial, gute Arbeit, genug und nachvollziehbar erklärt, Danke dafür.

[Christoph64]

Danke erst einmal ich schaue mir das jetzt mal in ruhe an, was ich nun zum download der https Seite nehmen werde.
Die beiden Möglichkeiten von Redeeemer gefallen mir.

Also Danke Euch beiden.

[Hobbycoder]

Zitat von Redeemer:

Seit XE8 gibt es System.Net.HttpClientComponent.TNetHTTPClient, der eine Windows-API verwendet. Bei einfachen GET-Requests würde ich Vcl.ExtActns.TDownloadURL benutzen, das es seit Urzeiten gibt und einfach zu verwenden ist.

Indy benötigt weiterhin OpenSSL.

Kommen die beiden erstgenannten Möglichkeiten ohne OpenSSL-DLL's aus?

[Rolf Frei]

Ja. Um OpenSSL würde ich, wenn möglich, einen grossen Bogen machen. Die System.Net Funktionen laufen nativ auf Windows und brauchen daher kein OpenSSL.

Habe damit aber das Problem, dass es bei Redirects (301/302) keine Möglichkeit zu geben scheint, die wirklich gelesene URL zu ermitteln. Die Funktinon ist also recht eingeschränkt. Ich muss für meine Anwendung wissen wie die zurückgelieferte URL denn nun genau gelautet hat. Habe keine Weg gefunden da an die nötige Info zu gelangen.

[Sherlock]

Randbemerkung: Um OpenSSL kann man aber nur einen Bogen machen, wenn man nicht plattformübergreifend entwickeln will.

Sherlock

[Hobbycoder]

Zitat von Rolf Frei:

Ja. Um OpenSSL würde ich, wenn möglich, einen grossen Bogen machen. Die System.Net Funktionen laufen nativ auf Windows und brauchen daher kein OpenSSL.

Das ist schön zu wissen. Mich hat das immer gestört, fremde DLL's mit auszuliefern.
Wobei ich jetzt aber auch dazu sagen muss, dass ich mit Indy+OpenDLL nie wirklich Probleme hatte, außer denen die ich selbst reinprogrammiert habe

[hoika]

Hallo,
zu Redirects findest Du für Indy hier was

https://stackoverflow.com/questions/...rl-redirection

[CCRDude]

Zitat von Rolf Frei:

Ja. Um OpenSSL würde ich, wenn möglich, einen grossen Bogen machen. Die System.Net Funktionen laufen nativ auf Windows und brauchen daher kein OpenSSL.

Nativ kann aber auch von Nachteil sein. Gerade erst erlebt, auf dem Server wollten wir veralterte TLS-Versionen abschalten - ging aber noch nicht, da die Software nativ zugreift und damit auf altem Windows noch ein altes TLS verwendet.