Delphi und https - TIdHTTP vs. THttpClient

[Gausi]

Da die Beteiligung "drüben" in der EE etwas mau ist, frage ich hier nochmal nach ...

In meinem mp3-Player parse ich für die Suche nach Liedtexten eine Webseite. Das ist mal wieder "kaputt". Zum einen wurde der Quelltext der Seite geändert (d.h. ich muss das parsen des html-Codes anpassen), zum anderen wurde die Seite komplett von http auf https umgestellt. Jetzt muss ich also gucken, wie ich da am besten Zugriff kriege.

Möglichkeit 1: Weiter mit Indy, einem IOHandler, und die OpenSSL-Libraries mitliefern. Findet man ja genug Code-Beispiele, und habe ich auch schon mal woanders so genutzt.

Möglichkeit 2: THttpClient aus den neuen Delphi-Versionen nutzen (System.Net.URLClient, System.Net.HttpClient). Dabei werden wohl die bei Windows mitgelieferten Bibliotheken dafür genutzt. Macht ggf. unter nicht voll gepatchten Windows-7 Probleme, aber das bekommt man in den Griff, wenn man explizit die neueren Protokolle setzt, was unter W7 per Default nicht gemacht wird, also
HttpClient.SecureProtocols := [THTTPSecureProtocol.TLS12, THTTPSecureProtocol.TLS11]; Zusätzlich gibt es da noch einen anderen Bug in Tokyo, der bei bestimmten URLs (anscheinend bei URL-kodierten Umlauten in der URL?) eine Exception schmeißt, was aber in Rio behoben ist. Das ist wohl noch nicht so ganz ausgereift ...

Da ich unerfahren auf dem Gebiet bin - gibt es da irgendwo noch versteckte Fallstricke? Oder was sind die Vor- und Nachteile der beiden Varianten? Generell muss ich da auch etwas mehr im Code umbauen, da z.B. bei einem 404 Indy eine Exception wirft, der HttpClient aber nicht ...

So wie ich das sehe, muss ich bei (1) zusätzliche Dateien ausliefern, und muss mich ggf. um das patchen kümmern, wenn es da Sicherheitsprobleme gibt. Bei (2) schiebe ich das komplett auf das Betriebssystem, muss dann aber mindestens Windows 7 (?) voraussetzen. Beides sind ja keine besonders dicken Einschränkungen - ich würde aktuell (2) vorziehen. Was meint ihr?

(Crosspost Entwickler-Ecke)

[Bbommel]

Also, ich war sehr froh, dass die ganzen REST-Bibliotheken von Delphi auch auf die "neuen" Http-Bibliotheken setzen und ich mich somit, was https angeht, auf das Betriebssystem verlassen kann. Da veraltete OpenSSL-Bibliotheken ja doch schon mal ein echtes Sicherheitsproblem sein können (klar, kommt immer noch drauf an, was genau man macht), war ich sehr froh, nicht permanent einen Blick auf aktuelle Versionen/Patches haben zu müssen.

Insofern bin ich ziemlich klar für Variante 2. Wobei ich es auch okay finde, mindestens ein aktuelles Windows 7 vorauszusetzen für einen PC, mit dem offensichtlich ja auch ins Netz gegangen werden soll.

[Dennis07]

Sehe ich genau so.
Die 2. Variante ist moderner und verwendet das jeweilige Betriebssystem, was in der Regel zu bevorzugen ist.
EInziges Problem, es fehlen noch einige Dinge wie viele der MIME-Typen, die musst du dir aktuell noch selbst beschaffen. Das Problem bei System.Net ist halt, du musst derzeit noch sehr gut wissen, wie es funktioniert und das trotz der mehr als kargen Dokumentation, die es hat (nämlich leider fast keine).
Dafür wird es aber, im Gegensatz zu Indy, noch aktiv weiterentwickelt und unterstützt auch neuere Features.

[Gausi]

Ok, danke für die Bestätigung meines Bauchgefühls.

Ein paar Stellen im Code waren etwas blöd beim Umbau - hauptsächlich Probleme mit der Kodierung (UTF8, URL-Kodierung, etc.), aber jetzt scheint alles zu laufen.

Zitat von Dennis07:

Einziges Problem, es fehlen noch einige Dinge wie viele der MIME-Typen, die musst du dir aktuell noch selbst beschaffen.

Das ist kein Problem bei mir. Ich brauche nur html/xml-Code und Bilder - und bei letzteren gehe ich einfach nach dem Dateinamen im Link. Das funktioniert bei der Quelle sehr gut.

[mjustin]

Zitat von Dennis07:

Dafür wird es aber, im Gegensatz zu Indy, noch aktiv weiterentwickelt und unterstützt auch neuere Features.

Indy wird immer noch aktiv weiterentwickelt, für Serveranwendungen und andere Protokolle als HTTP(S) ist es immer noch eine erstklassige Bibliothek. Nur der noch fehlende TLS 1.3 Support könnte früher oder später ein Problem darstellen. Client- und/oder Server-Anwendungen, die zur Zeit noch auf TLS 1.2 laufen, könnten irgendwann vor verschlossenen Türen stehen, wenn TLS 1.3 zur Pflicht wird.

[Rollo62]

Die Frage stellt sich mir auch jedes Mal, und ich tendiere auch zur 2ten Version (wg. SSL).

Ich kenne jetzt die interne Struktur von Indy nicht besonders, aber dessen High-Level Protokolle sind immer noch Top.
Wäre es nicht einfach möglich die unterste Hardware-Ebene auf dieselbe Basis wie die neue Net-Library zu stellen, und im API weiter oben bleibt alles wie gehabt (nur ohne die unsäglichen SSL-Libraries mitzuschleifen) ?
Evtl. gibt es ja schon einen Mechanismus um die Hardware nahen Level einfach auszutauschen ?

Das wäre so ungefähr meine Wunschvorstellung dazu, leider müsste das wohl von AtoZed oder sonst jemand der sich dazu berufen fühlt in Angriff genommen werden

[TurboMagic]

@mjustin: unterstützt Windows schon TLS 1.3? Als ich vor einigen Wochen versucht habe das herauszufinden, hab ich's leider nicht geschafft das rauszufinden.

[TurboMagic]

Noch eine gute Alternative: ICS Komponenten von overbyte.eu
Open source, kann SSL und ist kompatibel zu den aktuellen OpenSLL DLLs.
Außerdem gibt es einen extra Forumsbereich dazu auf dem Delphipraxis Server

https://en.delphipraxis.net/forum/37...mponent-suite/

[mjustin]

Zitat von TurboMagic:

@mjustin: unterstützt Windows schon TLS 1.3? Als ich vor einigen Wochen versucht habe das herauszufinden, hab ich's leider nicht geschafft das rauszufinden.

Windows (Clients und Server) unterstützen TLS 1.3 noch nicht. Allerdings ist Indy nicht nur unter Windows einsetzbar, d.h. die Entwicklung für Linux Distributionen mit TLS 1.3 Unterstützung wären betroffen. TLS 1.2 soll aber auch noch für einige Jahre nicht 'deprecated' werden (mindestens bis nach 2024):

Zitat:

"Und TLS 1.2 soll aus heutiger NIST-Sicht (siehe Punkt 4.1 in https://csrc.nist.gov/publications/d...52/rev-2/draft) mit 1.3 koexistieren und nicht von ihm abgelöst werden - sogar noch nach 2024."

(https://social.technet.microsoft.com...ndows_Serverde)