4. [GELÖST] CHttpFile::SendRequest() - POST-Abfrage

[GELÖST] CHttpFile::SendRequest() - POST-Abfrage

  • D

    Hallo,
    nach vielen Monaten des (Gast-)Lesens habe ich mich nun dazu entschieden mich in diesem super Forum anzumelden.
    Ich heiße Daniel komme aus Niedersachsen und bin ab 11.6. ausgelernter Fachinformatiker/Anwendungsentwicklung.

    Zusammen mit dem Buch "Visual C++" (Frank Budszuhn) habe ich vor einigen Wochen angefangen mit den MFC zu programmieren. (Visual Studio '08)

    Ich habe mir vorgenommen eine Internetanwendung (MFC/WinInet) zu schreiben (Learning-By-Doing klappt doch immer noch am besten ;))
    Beim Absetzen einer POST-Abfrage stoße ich nun jedoch auf ein Problem, welches ich trotz intensiver Recherche leider noch nicht lösen konnte.

    Als Leitfaden zur Programmierung benutzte ich folgenden Artikel aus der MS KB: http://support.microsoft.com/kb/165298/de

    In meiner Funktion steht nun folgender Code:

    CHttpFile* file;

CString headers;
headers  = _T("Content-Type: application/x-www-form-urlencoded\r\n");

CString parameters = _T("werta=a&wertb=b");

file = m_pConnection->OpenRequest(CHttpConnection::HTTP_VERB_POST, request.getFilename());
file->SendRequest(headers, (LPVOID)(LPCTSTR)parameters, parameters.GetLength());

    hier ist mir aufgefallen, dass die Parameter (hier "werta" und "wertb") nicht vollständig übertragen werden.

    Eine Netzwerkprotokollierung via Wireshark zeigten folgendes (Auszug):
    Content-Length: 15\r\n
    ...
    Line-based text data: application/x-www-form-urlencoded
    w\000e\000r\000t\000a\000=\000a\000&

    Zwischen den Zeichen stehen immer NUL-Zeichen was die Inhaltslänge von 15 Byte natürlich verkürzt.

    Daraufhin ersetzte ich folgendes:

    file->SendRequest(headers, (LPVOID)(LPCTSTR)parameters, parameters.GetLength());

    durch

    file->SendRequest(headers, (LPVOID)(LPCTSTR)"werta=a&wertb=b", parameters.GetLength());

    und siehe da, die NUL-Zeichen zwischen den Zeichen waren verschwunden.

    Kann es sein, dass das Problem darin liegt, dass die MFC die Zeichen in CString in wchar_t (also 16 Bit/Zeichen) speichert HTTP dann aber mit ASCII arbeitet wo ein Zeichen in ein Byte passt?

    Wahrscheinlich gibt's dafür eine ganz einfache Erklärung die mir als MFC-Anfänger einfach (noch) nicht ersichtlich ist.

    Vielen Dank schonmal für alle die sich hiermit befassen,
    Daniel

    0
  • S

    In Deinem Aufruf übergibst Du den zusätzlichen Parameterstring als Unicode, der wird dann auch so wie er ist gesendet. Du müsstest den String also vorher explizit nach Ansi konvertieren. Am einfachsten geht das, indem Du statt CString gleich CStringA verwendest.

    0
  • D

    Super, das klappt!

    Komisch, dass ich das weder im Buch, noch hier im Forum, noch in der MS KB gefunden habe. Alle Beispiele wurden mit CString geschrieben. Arbeiten alle ohne Unicode-Unterstützung?

    und noch eine kleine Frage:
    Gibt es einen schöneren/eleganteren Weg als

    CStringA parameters = _T("werta=a");
(LPVOID)(LPCTSTR)parameters.GetBuffer(parameters.GetLength()

    um CStringA nach LPVOID zu casten?

    Viele Grüße,
    Daniel

    0
  • S

    Wenn Du weißt, dass die Funktion den Text nicht verändert, dann reicht auch ein

    parameters.GetString()

    Ansonsten empfiehlt sich ein

    CStrBuf(parameters, parameters.GetLength())

    Damit sparst Du Dir den manuellen Aufruf von parameters.ReleaseBuffer().

    0
  • D

    Viel einfacher 🙂
    Danke!

    0

  • @DanielV: gewöhn dir einfach ab mit "(type)wert" zu casten, und nimm stattdessen "static_cast<typ>(wert)". Dann hätte dir vermutlich nämlich schon der Compiler einen Fehler gemeldet...

    0
  • D

    Hi,

    hustbaer schrieb:

    @DanielV: gewöhn dir einfach ab mit "(type)wert" zu casten, und nimm stattdessen "static_cast<typ>(wert)". Dann hätte dir vermutlich nämlich schon der Compiler einen Fehler gemeldet...

    Hast Recht. Der Compiler hätte beim Cast von LPCTSTR nach LPVOID einen Fehler rausgeschmissen.

    Die Zeile mit den beiden expliziten Casts kam aus dem KB-Artikel. Diese habe ich (blöderweise) 1:1 aus dem Artikel übernommen 🙂

    0
Anmelden zum Antworten