THTTPClient.AutomaticDecompression issues

[softtouch]

Wenn ich System.Net.HttpClient.THTTPClient.AutomaticDecompr ession mit dem Wert "Any" setze, kann ich einige Websites nicht lesen. Setze ich jedoch "Deflate", laden sie Seiten einwandfrei. Soll das so sein, das bei "Any" einige Seiten licht laden? Sollte der THttpClient das nicht automatisch machen? Wofür ist sonst "Any" gut, wenn es nicht klappt?

[Delphi.Narium]

Eventuell, weil die Gegenseite nicht weiß, was sie in dem Fall liefern soll und deshalb kein Ergebnis liefert?

Was ist unter

Zitat:

... einige Seiten nicht laden ...

zu verstehen?
Gibt es keinen Responsecode, mit dessen Hilfe weitergeforscht werden könnte?
Oder ist der 200 und es klappt trotzdem nicht?

Das Problem würd' ich nicht ausschließlich auf der Clientseite suchen.

[Union]

Accept-Encoding Any ist schon mal doof, weil es gzip, deflate, br erlaubt. Und br funktioniert nicht auf allen Client OS. Bei Windows jedenfalls nicht. Was steht denn bei der Response in Content-Encoding? Im Notfall kannst Du das selber decomprimieren.

[softtouch]

Zitat von Union:

Accept-Encoding Any ist schon mal doof, weil es gzip, deflate, br erlaubt. Und br funktioniert nicht auf allen Client OS. Bei Windows jedenfalls nicht. Was steht denn bei der Response in Content-Encoding? Im Notfall kannst Du das selber decomprimieren.

Im Responseheader ist "Content-Encoding: gzip", was falsch ist. Und wenn ich darauf basierend via TIdCompressorZLib die "gzip" Daten dekompremieren will, hängt sich die TIdCompressorZLib Funktion DecompressGZipStream auf, trotz try/except.
Mit anderen Worten: Die Seite (und auch einige andere in meiner Liste) liefert unkompremierte Daten, und der Responseheader sagt das es GZip kompremiert ist.

[Union]

Hast Du mal den Rohdatenstream? Ist der evtl. noch base64-encoded? Wie sieht der Code zum Entpacken aus? Ich würde anstelle der Indy auch eher System.ZLib.TZDecompressionStream verwenden.

[softtouch]

Zitat von Union:

Hast Du mal den Rohdatenstream? Ist der evtl. noch base64-encoded? Wie sieht der Code zum Entpacken aus? Ich würde anstelle der Indy auch eher System.ZLib.TZDecompressionStream verwenden.

Die Daten sind ganz normaler Text, nicht gzip komprimiert. Wenn ich die Dekompression überspringe, also ignoriere was im Header steht, bekomme ich ganz normal die HTML Seite.

[Union]

Das ist in der Tat bedenklich. Falls das tatsächlich vom Server in der Art falsch kommt, könntest Du höchstens auf Vorhandensein des GZip-Headers (1f 8b ..) prüfen und dann entpacken oder nicht. Sind das frei zugängliche Seiten, die man mal testen könnte?
Wie sieht der komplette Response-Header aus? Wird vielleicht Transfer-Encoding verwendet?

[softtouch]

Zitat von Union:

Das ist in der Tat bedenklich. Falls das tatsächlich vom Server in der Art falsch kommt, könntest Du höchstens auf Vorhandensein des GZip-Headers (1f 8b ..) prüfen und dann entpacken oder nicht. Sind das frei zugängliche Seiten, die man mal testen könnte?
Wie sieht der komplette Response-Header aus? Wird vielleicht Transfer-Encoding verwendet?

Eine Seite ist zum Beispiel folgende (Zeigt im Browser nichts an, sieht wie eine leere Seite aus):

Zitat:

https://ibusiness2022.com/

Der Response Header ist wie folgt:

Zitat:

HTTP/1.1 200 OK
Server: nginx/1.14.0 (Ubuntu)
Date: Wed, 10 Aug 2022 08:44:03 GMT
Content-Type: text/html; charset=utf-8
Content-Length: 167735
Connection: keep-alive
CF-Cache-Status: DYNAMIC
CF-RAY: 73876b87de078191-IAD
Cache-Control: no-store, no-cache, must-revalidate, max-age=0
Content-Encoding: gzip
Content-Language: en
Content-Security-Policy: block-all-mixed-content; frame-ancestors 'none'; upgrade-insecure-requests;
ETag: cacheable:5bcc20840ee42571c4ce9e8b71492cdb
Expect-CT: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
Link: <https://cdn.shopify.com>; rel="preconnect", <https://cdn.shopify.com>; rel="preconnect"; crossorigin
NEL: {"success_fraction":0.01,"report_to":"cf-nel","max_age":604800}
Report-To: {"endpoints":[{"url":"https:\/\/a.nel.cloudflare.com\/report\/v3?s=n03E8LDjr6SH0RVmOwd8WNbLpZVYnlXCaaa7Mr%2BbFPY 6NSC7NZpsYt6oyI2jQP2sJPIHM08Zfea4akG%2FBIy9LUJ2YR2 IIRfRn6MbmUf2HOIA%2FGqgixuLerbhAtcTBIw%3D"}],"group":"cf-nel","max_age":604800}
Server-Timing: processing;dur=1368, db;dur=87, parse;dur=21
Set-Cookie: _shopify_s=5c3f7634-b33f-4762-bb0a-084172bf0f8a; Expires=Wed, 10-Aug-22 09:09:17 GMT; Domain=ovcio.com; Path=/; SameSite=Lax
Strict-Transport-Security: max-age=7889238
Vary: Accept
X-Alternate-Cache-Key: cacheable:4c40ddbbb826eee36f1451049183c2f2
X-Cache: miss
X-Content-Type-Options: nosniff
X-Dc: gcp-us-east4,us-east1,gcp-us-east1
X-Download-Options: noopen
X-Permitted-Cross-Domain-Policies: none
X-Request-ID: 4dfdbbd3-0e31-49fe-b7a4-08f98860abf3
X-ShardId: 188
X-ShopId: 2106196038
X-Shopify-Stage: production
X-Sorting-Hat-PodId: 188
X-Sorting-Hat-ShopId: 2106196038
X-Storefront-Renderer-Rendered: 1
X-XSS-Protection: 1; mode=block
alt-svc: h3=":443"; ma=86400, h3-29=":443"; ma=86400

[Union]

Die Seite verursacht im Browser ERR_CONTENT_DECODING_FAILED. Scheint ein Problem von shopify zu sein.

[himitsu]

Nunja, wenn es Content-Encoding: gzip sagt, aber dann doch unkomprimiert senden täte, dann wäre das natürlich ein Fehler.