Schlagwort-Archive: THTTPClient

Delphi 10.1 Berlin THTTPClient Trouble (2)

Ok, switching to english for recapitulation

  1. Response.ContenAsString now checks for Content-Encoding = gzip and uses a compression stream (did make app crash)
  2. With AcceptEncoding = identity it can be avoided that a server adds this encoding
  3. It doesn’t matter what Encoding, Charset etc is set always get an EEncodingError querying IHTTPResponse.ContentAsString
    after successful POST (works in 10.0)
    (Embarcadero QC RSP-14300)
  4. Instead using IHTTPResponse.ContentAsString passing a TStringStream with HTTPClient.Post then
    no exception and StringStream.DataString is readable without any problem
  5. But final problem: Response delivers HTML and no JSON anymoreNow checking server side first if there is a problem before passing another bug report.
  6. My customer detected the reason:
    In Delphi 10.0 HTTPClient managed cookies from server login „behind the scene“ and sent it with every post..
    Proof: Setting HTTPClient.AllowCookies := False and an app does not work.
    In Delphi 10.1 Berlin this has changed, now there has to be added before a HTTPClient.Post
    HTTPClient.CustomHeaders[‚Cookie‘] := ‚WebBrokerSessionId=‘ + FSessionID;
    Otherwise any test app does not work.
    Removing such an automatism like this is a bug, time for another report. (Embarcadero QC RSP-14301)

 

Delphi 10.1 Berlin THTTPClient Trouble

Ein KO Kriterium für den Einsatz von Delphi 10.1 war eine Exception vom Typ EZCompressionError in einem FMX Projekt, welches mit Delphi 10.0 einwandfrei funktioniert.

Bei der Ursachensuche musste ich feststellen, dass die Interna von THTTPClient – und allem was damit zusammenhängt – sich grundlegend geändert haben:
In IHTTPResponse.ContentAsString wird jetzt z.B. das „Content-Encoding“ abgefragt und falls dieses „gzip“ ist, wird ein Compression Stream für die Ausgabe erzeugt, in 10.0. wurde das „Content-Encoding“ ignoriert. Und da kracht es gleich beim Login.
Mit HTTPClient.AcceptEncoding := ‚identity‘ war das Problem erstmal vom Tisch (womit jedes serverseitige Encoding  unterbunden wird).

Das nächste Probleme:
Egal welches Encoding, Charset etc, beim Abruf der JSON Daten vom Server, wenn intern die Streams umkopiert werden, kommt immer die Exception EEncodingError „Keine Zuordnung für Unicode-Zeichen in der Multibyte-Zielcodeseite vorhanden“. (Es ist egal, was für das Encoding angegeben ist: serverseitig ANSI)

Nach langem Hin und Her und einigen Stunden Debugging:
Wenn entweder ein Stream im HTTPClient.Post() für den Response übergeben oder Response.ContentStream abgefragt wird (in TStringStream umkopieren), dann klappt das ohne Exception und es gibt lesbaren Response String.
Aber: Der Response enthält keine JSON Daten sondern HTML! Was geht nun schief ?
Fiddler zeigt alles als korrekt an, das Sever Log zeigt keine (offensichtlichen) Fehler.

Negativ ist in diesem Zusammenhang die Hilfe aufgefallen: Ich bin da auf zu viele Einträge mit “ … zu diesem Zeitpunkt keine weiteren Informationen“ gestossen.

Fortsetzung folgt (wahrscheinlich, nicht garantiert)