Frage zur Request Klasse

Hi liebes Forum

Ich hab da ein Problem und zwar arbeite ich gerade mit der Request-Klasse um eine API aufzurufen. Dabei schreibt mir Typolight immer eine zusätzliche Zeile am Anfang und ans Ende. Zuerst bin ich davon ausgegangen, dass die Zahl welche in der ersten Zeile es die Gesamtlänge des Strings darstellt und die zweite letzte Zeile mit einer Null das Ende anzeigt. Aber nach einer kurzen Überprüfung bin ich zu dem Schluss gekommen, dass dies nicht sein kann.

Kann mir einer sagen was die Zahlen bedeuten und kann man sie irgendwie verhindern? Oder muss ich sie selbst raus löschen?

Grüße BruderFlexo

Ich glaube andreas.schempp hatte irgendwo genau das gleiche Problem...mach ihm mal eine PM!

Danke!

Ich hab Andreas mal angeschrieben.

Ich hab mir auch die anderen Requests im Typolight angeschaut, wie z.B. im Rep oder LiveUpdate, aber komischerweise tritt das Problem dort nicht auf.

Unterdessen schätze ich die erste Zahl / Zeile als die Größe der Daten als Hex ein und die Null als EOF Marker ein.

Gruß BruderFlexo

Andreas hatte eben ziemlich das gleiche Problem und das war irgendwie wegen dem Header, da gibt's eine ganze Diskussion dazu in einem Ticket. Aber Leo antwortet dort scheinbar nicht mehr :D

Hast du mal einen Link zu dem Thread, weil ich ihn nicht gefunden habe.

Ich hab jetzt schnell ein Workaround gemacht, aber das ist natürlich keine Lösung.

Gruß Bruderflexo

So hab den Trac Thread/Ticket gefunden.

Gruß Bruderflexo

Koennte es sein, dass du evtl. im Header "Transfer-Encoding: chunked" uebersehen hast?

Wenn ja, empfehle ich dir in deinem Objekt folgendes hinzuzufuegen.

PHP-Code:

---

    private function decode_chunked($string=null) {
        $lines = explode("\r\n",$string);
        $i=0;
        $length = 999;
        $content = '';
        foreach($lines as $line) {
            $i++;
            if ($i%2 == 1) {
                $length = hexdec($line);
            } elseif ($length == strlen($line)) {
            $content .= $line;
        }
            if ($length == 0)
                break;
        }
        return $content;
    }

    protected function makeRequest($httpURL)
    {
        $objRequest = $this->request;
        $objRequest->send($httpURL);
        if(array_key_exists('Transfer-Encoding', $objRequest->headers) && $objRequest->headers['Transfer-Encoding'] == 'chunked')
            $response = $this->decode_chunked($objRequest->response);
        else
            $response = $objRequest->response;
        return $response;
    } 


---

Die Funktion makeRequest kannst du ja nach belieben aendern, wichtig ist jedoch der check auf Transfer encoding, welcher das ggf. fixt.

Das Problem resultiert daraus, dass die Request Klasse in TL vorgibt HTTP 1.1 zu sprechen, worin chunked transfer encoding vorgeschrieben wird (siehe hierzu RFC).

Hoffe es hilft dir (und anderen evtl auch).
Chris

diese hier habe ich in meinem Banner Modul im Einsatz:

PHP-Code:

---

private function decodeChunked($chunked)
    {
        $decBody = '';
        $m = '';
        while (trim($chunked)) {
            preg_match("/^([\da-fA-F]+)[^\r\n]*\r\n/sm", $chunked, $m);
            $length = hexdec(trim($m[1]));
            $cut = strlen($m[0]);

            $decBody .= substr($chunked, $cut, $length);
            $chunked = substr($chunked, $cut + $length + 2);
        }
        return $decBody;
    } 


---

Frage nebenbei: Wäre das nicht etwas, was in den Core gehören würde?

Doch, eigentlich schon, schliesslich wyrde die Request Klasse dadurch RFC-konformer.
Meiner Meinung nach sollte da auch noch gzip encoding eingebaut werden (ist wenig Aufwand) um Bandbreite zu sparen.

Die Frage ist jedoch, wo zieht man die Grenze zum light und sollte man nicht einfach eine Extension schreiben, welche ein grosser Bruder der Request Klasse ist.

Ich denke, letzteres waere wohl doch das Beste, mal sehen ob ich mich in den naechsten Tagen daran setzen kann (zumindest ein grobes lineout zu verfassen).

Gruss
Chris

Es gibt ja bereits ein Ticket von daher sollte man eine Erweiterung mit Leo absprechen. Schließlich wollte er es im nächsten Release ändern.

Gruß BruderFlexo

Es gibt ein Ticket dazu, mag jetzt nicht übers iPhone danach suchen ;-)
das Problem wir in 2.7.3 behoben. Bis dahin kannst du in deiner Request-Klassen den Teil von "HTTP 1.1" auf "HTTP 1.0" ändern.

Die geplante "Behebung" des Fehler sieht aber auch nur so aus, dass die Request-Klasse wieder HTTP/1.0-Header schickt. Eine richtige HTTP/1.1-Kompatibilität würde ich allerdings schon begrüßen.

Zitat:

---

Zitat von leo

Die geplante "Behebung" des Fehler sieht aber auch nur so aus, dass die Request-Klasse wieder HTTP/1.0-Header schickt. Eine richtige HTTP/1.1-Kompatibilität würde ich allerdings schon begrüßen.

---

Schreibe gerade eine Klasse namens "RequestExtended", welche ich fyr eins meiner Module benoetige.
Implementiert ist bislang:

• Useragent kann ueberschrieben werden.
• Direktverbindungen auf ipV6 sollten funktionieren.
• getUrlEncoded()
• postUrlEncoded()
• postMultipartFormdata() (inklusive einer wrapperklasse welche die Daten entsprechend aufbereitet).
• send() (mit zur "normalen" Requestklasse kompatibler Syntax)
• Empfangen, parsen, setzen von Cookies.
• Transfer-Encoding/Content-Encoding(bislang nur bei Responses, noch nicht bei postdata):
  
  • chunked,
  • (x-)gzip,
  • deflate.
  
  (Compress folgt, sobald ich LZW akzeptabel decodieren kann).

Dies nur mal als Vorschau was ich schon habe, weiteres kommt noch.
Ich frage mich jedoch gerade, wie ich die Dateien "RequestExtended.php" und "MultipartFormdata.php" dann im TL_ROOT positionieren soll.
Ein Modul ist es ja nicht, kann ich die gefahrlos nach "TL_ROOT/system/libraries" packen lassen oder doch lieber ein "leeres" Modulverzeichnis, welche dann diese beinhaltet? Welcher Ort ist "der Richtige"?

Gruss
Chris

Die Dateien sollen sowohl im Ordner system/libraries als auch in einem separaten Modulordner vom Autoloader gefunden werden.

Zitat:

---

Zitat von leo

Die Dateien sollen sowohl im Ordner system/libraries als auch in einem separaten Modulordner vom Autoloader gefunden werden.

---

Das ist mir bekannt.
Ich meinte jedoch aus "logischer" Sicht.
Also wo der gefyhlt richtige Platz ist. Momentan tendiere ich zu libraries, da es wie gesagt ja kein Modul descendant ist, sondern nur eine Supporter Klasse.
Die Frage sollte nicht heissen, "Wo funktioniert es" sondern "Wo erwartet ein Entwickler intuitiv diese Klassen zu finden."

Gruss
Chris

Ich denke auch das libraries der richtige Ort ist.

Als ich begann, die Erweiterung cm_membergooglemaps zu schreiben, hatte ich auch danach gesucht. Ich hatte mich dann entschieden, die Anfragen (geocoding) mit cURL umzusetzen. Das funktioniert aus ganz gut. Allerdings würde ich schon gern "framework-interne" Funktionen nutzen.
Wer Lust hat, kann sich das ja mal ansehen (https://contao.org/erweiterungsliste...010005.de.html
Gruß ChrMue