HTTPRquest (Legacy): Fehler bei HEAD-Request

  • Affected Version
    WoltLab Suite 5.2

    Führt man einen HEAD-Request mittels HTTPRequest-Klasse durch, kommt es zu folgender Exception:


    Code
    Body length does not match length given in header


    Setze ich für den Request eine maxLength, erhalte ich 206 als Statuscode, was für mein Vorhaben allerdings ungeeignet ist, da der HEAD-Request eben genau dafür gedacht ist, den aktuellen Statuscode der Seite abzufragen, ohne den ganzen, unnötigen Overhead, den ich bei GET oder POST habe.


    EDIT:


    Okay, das scheint nur bei bestimmten Seiten aufzutreten und nicht generell.


  • da der HEAD-Request eben genau dafür gedacht ist, den aktuellen Statuscode der Seite abzufragen, ohne den ganzen, unnötigen Overhead, den ich bei GET oder POST habe.


    Durch meine Erfahrung in der Entwicklung einer Browser-Erweiterung, welche Lesezeichen dahingehend prüft, ob diese noch gültig sind oder nicht, kann ich sagen, dass das tatsächlich leider nur unzuverlässig funktioniert. Man stößt dann doch recht bald auf Seiten, bei denen eine Anfrage via HEAD nicht das gleiche Ergebnis zurückliefert wie eine GET-Anfrage. ;)

    "Wir finden Worte, die wie Geschosse treffen, wir leisten Schwüre, die niemals zerbrechen. Wir steh'n zusammen auch wenn man uns nicht mag, wir leben schneller, schneller in den Tag. Unsere Metaphern sind teuflische Ikonen, harte Aphorismen, gewagte Abstraktionen. Ein Strauß von Versen im Idiomenbeet, verbale Blüten wie es geschrieben steht."


    (Saltatio Mortis)

  • Naja, in der Hinsicht ist GET genau so unzuverlässig. Und bei meinen bisherigen Tests (5.3 mit Guzzle, ohne HTTPRequest) funktionierte das bisher recht problemlos.

  • Eine hundertprozentige Verlässlichkeit gibt es natürlich keine, aber GET ist schon zuverlässiger als HEAD, um den Status zu erhalten, weil es einfach eine zusätzliche Fehlerkategorie ist, die man sonst nicht hat. Wenn eine GET-Anfrage ein falsches Ergebnis liefert, dann zumindest nicht, weil die Seite HEAD-Abfragen ablehnt oder anders behandelt, sondern "nur" aus einem der ganzen anderen Gründe, die für ein falsches Ergebnis sorgen können. Mein Umgang ist damit, HEAD zu verwenden und im Falle eines negativen Ergebnisses eine zusätzliche GET-Anfrage zur Absicherung hinterzuschicken. So habe ich für Performance optimiert, zahle im Zweifel aber lieber den Preis für eine zusätzliche Abfrage, um die Zuverlässigkei zu erhöhen. ;)

    "Wir finden Worte, die wie Geschosse treffen, wir leisten Schwüre, die niemals zerbrechen. Wir steh'n zusammen auch wenn man uns nicht mag, wir leben schneller, schneller in den Tag. Unsere Metaphern sind teuflische Ikonen, harte Aphorismen, gewagte Abstraktionen. Ein Strauß von Versen im Idiomenbeet, verbale Blüten wie es geschrieben steht."


    (Saltatio Mortis)

    Edited once, last by Cadeyrn ().

    • Official Post

    Hallo,


    ja die Prüfung ist fehlerhaft. Für eine komplett korrekte Funktionsweise von HEAD-Requests sind aber soweit ich das ad-hoc sehe größere Änderungen erforderlich. In Anbetracht der Tatsache, dass das nur Legacy-Code betrifft, lohnt sich der Aufwand in meinen Augen nicht [1]. Einer der Gründe für den Wechsel auf Guzzle war, dass man sich um derartige Details nicht mehr kümmern muss und man automatisch von Verbesserungen (bspw. in cURL) profitiert.


    [1] Jeder Kunde mit Zugang zu WoltLab Suite 5.2 kann einfach auf WoltLab Suite 5.3 aktualisieren und von Guzzle profitieren. Für WoltLab Suite 3.1 halte ich eine Korrektur in Anbetracht der geringen Schwere für zu invasiv.

  • Tim Düsterhus

    Set the Label from Works as designed to Won’t fix