Transparente Handhabung von GZip-kodierten Inhalten mit WWW::Mechanize

Question

Ich verwende WWW::Mechanize und behandle derzeit HTTP-Antworten mit dem ' Content-Encoding: gzip Header' in meinem Code, indem ich zunächst die Antwort-Header prüfe und dann IO::Uncompress::Gunzip verwende, um den unkomprimierten Inhalt zu erhalten.

Ich möchte dies jedoch transparent tun, so dass WWW::Mechanize-Methoden wie form(), links() usw. mit dem unkomprimierten Inhalt arbeiten und diesen parsen. Da WWW::Mechanize eine Unterklasse von LWP::UserAgent ist, würde ich es vorziehen, die LWP::UA::handlers um dies zu tun.

Obwohl ich teilweise erfolgreich war (ich kann zum Beispiel den unkomprimierten Inhalt ausdrucken), bin ich nicht in der Lage, dies transparent in einer Weise zu tun, die ich aufrufen kann

$mech->forms();

Zusammengefasst: Wie "ersetze" ich den Inhalt innerhalb des $mech-Objekts, so dass von diesem Punkt an alle WWW::Mechanize-Methoden so funktionieren, als wäre die Content-Encoding nie geschehen?

Ich würde mich über Ihre Aufmerksamkeit und Hilfe freuen. Danke

Answer 1

WWW::Mechanize::GZip denke ich.

Answer 2

Es sieht für mich so aus, als könnten Sie es durch das Element $res->content( $bytes ) ersetzen.

Übrigens habe ich diese Dinge gefunden, indem ich mir den Quelltext von LWP::UserAgent, dann HTTP::Response, dann HTTP::Nachricht .

Answer 3

Sie ist in UserAgent und damit in Mechanize integriert. Ein WICHTIGER Vorbehalt um Ihnen einige Haare zu ersparen

-Zum Debuggen sollten Sie nach Fehlern suchen $@ nach dem Aufruf von decoded_content.

$html = $r->decoded_content;
die $@ if $@;

Noch besser ist es, den Quellcode von HTTP::Message zu durchsuchen und sicherzustellen, dass alle Unterstützungspakete vorhanden sind

In meinem Fall gab decoded_content undef zurück, obwohl content raw binary ist, und ich habe mich auf die Suche gemacht. UserAgent setzt das Fehlerflag, wenn die Dekodierung fehlschlägt, aber Mechanize ignoriert es einfach (es prüft oder protokolliert das Vorkommen nicht als eigenen Fehler/Warnung).

In meinem Fall sagt $@: "Can't find IO/HTML.pm It was eval'ed

Nachdem ich mich in die Quelle vertieft habe, finde ich heraus, dass der eingebaute Entschlüsselungsprozess lang, akribisch und mühsam ist und so ziemlich jedes Szenario abdeckt und viele Vermutungen zulässt (Danke, Gisle!).

wenn Sie paranoid sind, setzen Sie explizit den Standard-Header, der bei jeder Anfrage bei new() verwendet werden soll

    $browser = new WWW::Mechanize('default_headers' => HTTP::Headers->new('Accept-Encoding' 
                            => scalar HTTP::Message::decodable()));