2016-10-18 1 views
0

Ich versuche, eine Seite mit Gzip-Komprimierung aktiviert, mit und TIdCompressorZLib. Unter Windows funktioniert der Code einwandfrei und die Daten werden dekomprimiert. Aber der exakt gleiche Code auf OSX gibt Mülldaten zurück, die aussehen, als ob sie noch komprimiert wären. Ich kann nicht wirklich sehen, wo es falsch läuft?Gzip Dekomprimierungsproblem auf OSX mit TIdHTTP und TIdCompressorZLib

Dies ist der Code, den ich mit dem Testen bin:

with TIdHTTP.Create(nil) do begin 
    HandleRedirects := true; 
    Compressor := TIdCompressorZLib.Create(nil); 
    Request.AcceptEncoding := 'gzip, deflate'; 
    Data := Get('http://google.com.au'); 
    Compressor.Free; 
    Free; 
    WriteLn(Data); 
end; 

Data sieht aus wie das Original komprimiert Müll auf OSX, während es klar dekomprimierte HTML unter Windows ist.

Ich benutze Delphi 10.1 Berlin Update 1 und OSX 10.11.

Antwort

1

Sie sind manuell die TIdHTTP.Request.AcceptEncoding-Eigenschaft auf dem Webserver zu sagen, dass es OK ist eine komprimierte Antwort zu senden auch wenn TIdCompressorZLib nicht wirklich bereit ist, es zu behandeln. In Ihrem Fall meldet die Eigenschaft TIdCompressorZLib.IsReady wahrscheinlich unter OSX "False", unter Windows jedoch "True".

Im Januar 2016 wurde Indy aktualisiert, um die ZLib-Bibliothek On-Demand bei der ersten Verwendung von ZLib dynamisch zu laden (SVN rev 5330). Diese Änderung brach TIdCompressorZLib, die später im Februar 2016 (SVN rev 5343) behoben wurde. Ich weiß nicht, ob das in Berlin ist oder nicht. Versuchen Sie, die neueste SVN-Version zu installieren, und prüfen Sie, ob das Problem weiterhin besteht (instructions und download).

Bei Verwendung der TIdHTTP.Compressor Eigenschaft, DO NICHT stellen Sie die Request.AcceptEncoding Eigenschaft manuell überhaupt:

with TIdHTTP.Create(nil) do begin 
    HandleRedirects := true; 
    Compressor := TIdCompressorZLib.Create(nil); 
    // Request.AcceptEncoding := 'gzip, deflate'; // <-- here 
    Data := Get('http://google.com.au'); 
    Compressor.Free; 
    Free; 
    WriteLn(Data); 
end; 

Lassen Request.AcceptEncoding leer und lassen TIdHTTP Update es intern, wenn die zugewiesene Compressor ist tatsächlich bereit komprimierte Antworten zu handhaben .


BTW, Sie sind undicht TIdHTTP und TIdCompressorZLib Objekte, wenn TIdHTTP.Get() eine Ausnahme bei einem Fehler auslöst. Sie sollten try/finally Blöcke verwenden:

with TIdHTTP.Create(nil) do 
try 
    HandleRedirects := true; 
    Compressor := TIdCompressorZLib.Create(nil); 
    try 
    // Request.AcceptEncoding := 'gzip, deflate'; 
    Data := Get('http://google.com.au'); 
    finally 
    Compressor.Free; 
    end; 
finally 
    Free; 
end; 
WriteLn(Data); 
+1

Danke. Sie haben Recht, dass die Eigenschaft 'IsReady' den Wert false zurückgegeben hat. Es gibt nach mehreren HTTP-Anfragen ständig false zurück, da die zlib-Bibliothek anscheinend überhaupt nicht geladen wird, was vermutlich der im Jan-2016 SVN rev. 5330 eingeführte Fehler ist. Ich habe die 'IdZlibHeaders'-Einheit zur Liste verwendet und 'IdZlibHeaders.Load' genannt, nachdem das' TIdCompressorZLib' Objekt erstellt wurde, und nun'IsReady' zurückgibt und der Inhalt von gzip dekomprimiert wird –

+0

Ja, der ursprüngliche Fehler war, dass 'TIdCompressorZLib' 'IdZLibHeaders.Load()' bereits erwartet hatte So wurde 'IsReady' einfach den Wert von' IdZLibHeaders.Loaded() 'zurückgegeben. Die Lösung bestand darin, 'IsReady' stattdessen' Load() 'aufzurufen, falls es noch nicht aufgerufen wurde. –

+0

Nick C Workaround hat es auch für mich auf 10.1 Berlin behoben. – Olecramoak