Aufklärung zu FAQ Beiträge Post mit NMHTTP und IdHTTP



  • Hallo Leute,

    als ich gerade in der FAQ nach etwas suchte bin ich per Zufall auf dem Beitrag
    "Indy - Post per TIdHTTP funktioniert nicht" und weiter ging es mit einem
    siehe auch hier-Link nach "Netzwerk - NMHTTP->Post geht nicht.

    So nu als erstes die Aufklärung zu NMHTTP->Post:

    Laut Dokumentation sollte NMHTTP Post als zweiten Parameter die Post Daten
    beinhalten wenn NMHTTP->OutputFileMode = false; steht, im Prinzip macht er
    es auch fast so, aber nicht richtig so das ein Server es Versteht und als
    Post-Daten erkennt.
    Die Lösung:
    Eine Text-Datei erstellen in der die Post-Daten stehen, wie man es kennt:

    Memo1->Text = "name1=valu1&name2=value2&name3=value3";
    Memo1->Lines->SaveToFile("Filename");
    

    Dann OutputFileMode auf true und 2. Parameter den Filenamen bei NMHTTP
    also:

    NMHTTP->OutputFileMode = true;
    NMHTTP->Post("www.server.de/script.cgi","Filename");
    

    Und guck an NMHTTP Post geht.
    -----------------------------------------------------------------------

    So nun zu dem Thema mit IdHTTP->Post:

    Bei einigen ging es ohne Angabe von Content-Type nicht und bei anderen doch,
    und warum kann man auch als Type "egal" angeben aber richtig ist "application/x-www-form-urlencoded"
    oder ist das überhaupt richtig??
    Was ist überhaupt Content-type?

    Kurze Anmerkung:
    Wir tauschen mit einer Firma Datenbank-Daten aus, den Request den er an mein
    Perl-Script auf dem Server sendet ist eine XML-Datei, wir hatten uns geeinigt
    das er die Daten nicht "Urlencoded" sendet, sondern normal. Daher lies er den
    Content-Type x-www-form-urlencoded auch weg, und es ging natürlich nicht,
    geschrieben hatte er in C#. Ich sagte ihm das er es mit angeben muß, egal wie
    er die Daten sendet, meinem Script ist es EGAL. Er kann auch application/xml als
    Content-type nehmen oder egal/egal.

    Hintergrund!
    Schuld daran ist der Webserver, den wenn er eine POST-Anfrage erhält möchte er
    auch den Content-type wissen, damit sich das Programm/Script darauf einstellen
    kann.
    Wenn es an einem PHP-Script geht, braucht PHP dieses x-www-form-urlencoded, da
    PHP für Webanwendungen gedacht ist und seine POST-Daten von einem Formular
    erhält, sind in der POST-Datei auch Binäredaten (z.B. ein Bild) wird es PHP
    vom Browser mit multiform mitgeteilt.

    ALSO:
    Content-type: DATEI-Type / INHALTS-Type (welche Art der Datei)

    giebt ein Server eine HTML-Datei zum Browser aus, sagt er Content-type: text/html
    "text" weil jede HTML-Datei aus Text besteht, also mit einem Text-Editor geöffnet
    werden kann, und "HTML" da es ein HTML-Document ist.
    Sendet der Server ein Bild, sagt er Content-type: image/jpg
    Datei-Type: Image, Inhalts-Type: ipg , also ein jpg-Bild.

    Wenn wir Daten an einem Server senden, niemt es meistens ein Programm/Script
    entgegen, daher Datei-type: application,
    kommen die Daten aus einem Formular, ist der Inhalt x-www-form-urlencoded.

    Um SAUBER mit so was umzugehen und höchste Kompatibelität zu erreichen, sollte
    man immer den Content-type verwenden, welchen das Script/Programm an der
    Gegenstelle erwartet.

    -----------------------------------------
    ??? Warum ging es bei Jansen ohne und Peter nicht mit Content-type ???

    Vorweg war noch die Rede mit PHP wo "text/html" nicht ging, logisch wie gesagt
    will PHP nur "application/x-www-form-urlencoded", da Peter eine CGI Anwendung
    nahm, dessen Interpreter (bei Perl z.B.) bzw. direkte Anwendung, nicht den
    Content-type verwaltet, also ihm "egal" ist und diesen Wert nur weitergiebt,
    geht das mit jeder Angabe "Content-type: egal".

    Bei Jansen ging es auch ohne angabe des Content-type, aber war die Angabe wirklcih
    nicht da?? Es reicht auch ein Leerzeichen, oder sogar garnichts:
    (Header:)
    Content-type:;
    Content-length:xxx;
    ...etc...

    Wichtig für (fast) jeden Server ist das die Zeile "Content-type:" vorhanden
    sein muß im Header, egal ob sie nun einen Wert zum Weitergeben hat oder nicht.

    Ich hoffe das ich ein bischen mehr Klarheit schafen konnte.

    viele Grüße
    promicha



  • Erstmal danke für deinen Beitrag.

    Der NMHTTP-Workaround scheint einleuchtend, ohne das jetzt getestet zu haben.

    Mit deinen Erklärungen zu IdHTTP komme ich aber noch nicht ganz klar, das muss ich mir mal in Ruhe durch den Kopf gehen lassen. 🙂


Anmelden zum Antworten