Unbekannte Werte verhindern das Dekodieren.

[Forumsgast]

Ich versuche grad mal etwas mit XMLRPC auf die Beine zu stellen. Nun habe ich eine kleine Testanwendung (Client) geschrieben, welche so aussieht:

<?php

    header('Content-Type: text/plain');

    $response = '';

    $request = xmlrpc_encode_request(
        'public.listEntries', array('id', 'cid')
    );

    $fo = @fsockopen('localhost', 80, $errno, $errstr, 30);
    
    if ($fo) {
        $data = "POST /Testlabor/xmlrpc_server.php HTTP/1.1\r\n"
              . "Host: localhost\r\n"
              . "Content-Length: " . strlen($request) . "\r\n"
              . "Connection: close\r\n\r\n"
              . $request;

        fwrite($fo, $data);
        while(!feof($fo)) {
            $response .= fgets($fo, 128);
        }
        fclose($fo);
        $response = (substr($response, strpos($response, "\r\n\r\n")+4));
        var_dump(xmlrpc_decode($response));
       // echo $response;
    }
    else {
        echo 'Error: Could not connect to server.';
    }

?>

Nicht wirklich schön, aber für den Anfang erfüllt es seinen Zweck.

Nun habe ich das Problem, dass ich einen Response bekomme, der wie folgt aussieht:

HTTP/1.1 200 OK
Date: Thu, 13 Jul 2006 17:56:15 GMT
Server: Apache/2.0.58 (Win32) SVN/1.3.1 DAV/2
X-Powered-By: PHP/5.1.2
Connection: close
Transfer-Encoding: chunked
Content-Type: text/html; charset=iso-8859-15

1e0
<?xml version="1.0" encoding="iso-8859-15"?>
<methodResponse>
<params>
 <param>
  <value>
   <array>
    <data>
     <value>
      <struct>
       <member>
        <name>id</name>
        <value>
         <string>1</string>
        </value>
       </member>
       <member>
        <name>cid</name>
        <value>
         <string>1</string>
        </value>
       </member>
      </struct>
     </value>
    </data>
   </array>
  </value>
 </param>
</params>
</methodResponse>

0

Nun würde ich gern per xmlrpc_decode() diesen Response in einen PHP-Array umwandeln. Es funktioniert manchmal aber meistens nicht.

In diesem Response sieht man zwei Werte: "1e0" und "0". Ich habe leider keine Ahnung, wo diese Werte herkommen. Wenn ich $response nicht ausgeben lasse sind diese Werte auch nicht da. Nun habe ich auf den Header geachtet und mir ist aufgefallen, dass diese Werte nur dann kommen, wenn der Header wie folgt aussieht:

HTTP/1.1 200 OK
Date: Thu, 13 Jul 2006 17:56:15 GMT
Server: Apache/2.0.58 (Win32) SVN/1.3.1 DAV/2
X-Powered-By: PHP/5.1.2
Connection: close
Transfer-Encoding: chunked
Content-Type: text/html; charset=iso-8859-15

Aber nicht, wenn der Header so aussieht:

HTTP/1.1 200 OK
Date: Thu, 13 Jul 2006 18:00:05 GMT
Server: Apache/2.0.58 (Win32) SVN/1.3.1 DAV/2
X-Powered-By: PHP/5.1.2
Content-Length: 480
Connection: close
Content-Type: text/html; charset=iso-8859-15

Unterschiede sind rot gekennzeichnet.

Woran liegt das?

[Forumsgast]

Das sind die Chunk-Markierungen, also wo ein Stück aufhört oder anfängt.
Wie man das selbst dekodiert, weiss ich gar nicht... sollte in der RFC zum HTTP-Protokoll stehen.

Entweder ist google dein Freund, oder Du benutzt sowas wie cURL, das sollte Dir das abnehmen.

[Gast]

Dunkle Erinnerungen kommen hoch...
Bei HTTP 1.1 kann ein Transfer in Chunks eingeteilt werden. Vor jedem Chunk kommen 4 (?) Bytes für die Länge des folgenden Chunks. In Deinem Beispiel: 0x1e0 == 480

Gag der Sache ist wohl, dass pro Chunk Header- und Footer-Felder möglich sind. Man könnte also gewisse Header-Felder nachträglich schicken, obwohl die Ausgabe schon begonnen wurde.

3.6.1 Chunked Transfer Coding
The chunked encoding modifies the body of a message in order to transfer it as a series of chunks, each with its own
size indicator, followed by an OPTIONAL trailer containing entity-header fields. This allows dynamically produced
content to be transferred along with the information necessary for the recipient to verify that it has received the full
message.
Chunked-Body = *chunk
last-chunk
trailer
CRLF
chunk = chunk-size [ chunk-extension ] CRLF
chunk-data CRLF
chunk-size = 1*HEX
last-chunk = 1*("0") [ chunk-extension ] CRLF
chunk-extension= *( ";" chunk-ext-name [ "=" chunk-ext-val ] )
chunk-ext-name = token
chunk-ext-val = token | quoted-string
chunk-data = chunk-size(OCTET)
trailer = *(entity-header CRLF)
The chunk-size field is a string of hex digits indicating the size of the chunk. The chunked encoding is ended by
any chunk whose size is zero, followed by the trailer, which is terminated by an empty line.
The trailer allows the sender to include additional HTTP header fields at the end of the message. The Trailer
header field can be used to indicate which header fields are included in a trailer (see section 14.40).
A server using chunked transfer-coding in a response MUST NOT use the trailer for any header fields unless at least
one of the following is true:
a) the request included a TE header field that indicates “trailers” is acceptable in the transfer-coding of the
response, as described in section 14.39; or,
b) the server is the origin server for the response, the trailer fields consist entirely of optional metadata, and the
recipient could use the message (in a manner acceptable to the origin server) without receiving this
metadata. In other words, the origin server is willing to accept the possibility that the trailer fields might
be silently discarded along the path to the client.
This requirement prevents an interoperability failure when the message is being received by an HTTP/1.1 (or later)
proxy and forwarded to an HTTP/1.0 recipient. It avoids a situation where compliance with the protocol would have
necessitated a possibly infinite buffer on the proxy.
An example process for decoding a Chunked-Body is presented in appendix 19.4.6.
All HTTP/1.1 applications MUST be able to receive and decode the “chunked” transfer-coding, and MUST ignore
chunk-extension extensions they do not understand.

[Forumsgast]

Okay, ich habs nun mal auf HTTP/1.0 umgestellt. Damit läufts ohne Probleme.

Aber weiterhin ist nur bei manchen Responses die Content-Lenght angegeben. Irgendwie wechselt das nach Lust und Laune.

[Gast]

Es sind ja nicht alle Header-Felder zwingend würd ich mal sagen.
Notfalls endet der Content halt, wenn der Webserver die Verbindung kappt. Bei HTTP 1.0 gibt es ha auch nur eine Anfrage pro Verbindung. Da ist ne Content-Length eigentlich net so wichtig. Nur kann man halt keinen Fortschrittsbalken anzeigen.

[Forumsgast]

Naja sowas brauch ich glaub auch nicht

[Forumsgast]

HTTP 1.0 unterstützt allerdings keine Host-Angabe, also darf auf dem Server, den Du ansprichst, nur eine Domain laufen, ohne VirtualHosts.

[Forumsgast]

Hmm... eine Subdomain zählt als VirtualHost?

[Forumsgast]

Wenn sie auf der gleichen IP laufen krachts, da dann nach dem Host-Header unterschieden werden müsste, den HTTP 1.0 nicht kennt.

[Forumsgast]

Okay, dann könnte ich aber, da es ja mein Server ist, das Request einfach direkt an den XMLRPC-Server senden, anstatt da irgendwie über ne Subdomain oder sonstiges zu gehen.

[Forumsgast]

So ich habe es nun endlich geschafft. Ich hatte einen Kumpel nochmals deswegen angesprochen und er hat mir dann diesen Link (klick) gegeben. Dort gibts eine Funktion in der die Chunks verarbeitet werden.

Danke für die schnellen Antworten