ABAKUS

Verfasst: **26.03.2009, 09:56**

Empfange mit Fsockopen eine Datei von einem anderen Server. Jetzt bekomm ich aber in die Variable, in der die Daten geschrieben werden, am Anfang und am Ende bei der Ausgabe des Script, einen String ausgeworden den ich weder bearbeiten, noch sonst iwie ändern kann.

Code: Alles auswählen

217f  <-------- Um diese Varchars geht es mir, warum sind die da???
HTTP/1.1 200 OK
Date&#58; Thu, 26 Mar 2009 08&#58;47&#58;33 GMT
Server&#58; Apache/2.2.11 &#40;Unix&#41; mod_ssl/2.2.11 OpenSSL/0.9.7a DAV/2 mod_bwlimited/1.4 PHP/5.2.8
X-Powered-By&#58; PHP/5.2.8
Connection&#58; close
Content-Type&#58; application/x-www-form-urlencoded; charset=utf-8
X-Pad&#58; avoid browser bug

u=blabla...data....
0 <-------- Um diese Varchars geht es mir, warum sind die da???

Wie gesagt sobald ich die variable der Verbindungdaten anspreche, werden mir in der Output Source am Anfang und am Ende Strings mit ausgegeben.

Diese Strings stehen auch in der Source die ich vom Server empfange aber warum werden mir diese beiden String am Anfang und am Ende der Source angezeigt?? Gebe ich die Var aus sieht es im Output so aus:

Code: Alles auswählen

20f6 <------- Warum sind die jetzt da? Warum kann ich die nicht bearbeiten?
<?xml version='1.0' encoding='UTF-8'?>
    u=blabla....data...

<!--
	XML Response, 2009-03-26T09&#58;54&#58;49+01&#58;00, generated in 0.6783 seconds.
	@srv response success
-->
0  <------- Warum sind die jetzt da? Warum kann ich die nicht bearbeiten?

Hoffe mir kann da jemand helfen

Danke im Vorraus.

grüße ins0

Verfasst: **26.03.2009, 10:20**

Hi,

in der Doku von https://php.net zu fopen und Konsorten steht was. Und da ist auch eine Funktion, die das Problem behebt. Der funktionname hat irgendwas mit chunked zu tun. Snoopy verwendet auch so eine Funktion, um das Problem zu umgehen.

Hoffe das hilft.

Sonnige Grüsse
HaPe

Verfasst: **26.03.2009, 11:00**

Das gleiche Spiel treibt die Source mit mir wenn ich einen HTTP 1.0 GET schicke. Was ja Chuncked nicht unterstützt?!

HHmm an Snoopy hab ich auch schon gedacht und ausprobiert....gleiches resultat oder muss man bei Snoopy ne bestimmt func. aufrufen?

Und warum sind die String immer am Anfang und am Ende jeder ausgabe?

var_dump gibt mir:

218f
string(8575) "HTTP/1.1 200 OK
Date: Thu, 26 Mar 2009 10:06:02 GMT
Server: Apache/2.2.11 (Unix) mod_ssl/2.2.11 OpenSSL/0.9.7a DAV/2 mod_bwlimited/1.4 PHP/5.2.8
X-Powered-By: PHP/5.2.8
Connection: close
Content-Type: application/x-www-form-urlencoded; charset=utf-8
X-Pad: avoid browser bug

u=data"
0

Verfasst: **26.03.2009, 11:18**

ins0 hat geschrieben:Und warum sind die String immer am Anfang und am Ende jeder ausgabe?

var_dump gibt mir:

218f
string(8575) "HTTP/1.1 200 OK
Date: Thu, 26 Mar 2009 10:06:02 GMT
Server: Apache/2.2.11 (Unix) mod_ssl/2.2.11 OpenSSL/0.9.7a DAV/2 mod_bwlimited/1.4 PHP/5.2.8
X-Powered-By: PHP/5.2.8
Connection: close
Content-Type: application/x-www-form-urlencoded; charset=utf-8
X-Pad: avoid browser bug

u=data"
0

Das sieht zwar irgendwie nach chunked aus, aber wenn die Antwort des Servers, denn dein Skript „belästigt“, chunked-kodiert wäre, müsste:

a) dieses im Kopf an einem entsprechenden Transfer-Encoding-Feld zu erkennen sein - ist es aber nicht,
b) die Kodierung im Datenteil der Antwort erscheinen und nicht vor dem Kopf.

Dass die Ursache nicht an der Gegenstelle sondern in deinem Skript oder an deinem Server liegen muss, lässt sich auch daran erkennen, dass die Ausgabe 218f vor der Ausgabe „string(8575)“ erscheint, die durch var_dump() erzeugt wird. 218f steht kann also nicht in dem stehen, was du von dem anderen Server bekommst, ansonsten würdest du (wenn überhaupt, siehe oben) „string(8575) "218f HTTP/1.1 …“ erhalten.

218f ist zudem dezimal 8591, dein Text hingegen ist laut var_dump nur 8575 Zeichen lang - passt also auch nicht. Ich würde so auf den Dutt ja eher darauf tippen, dass du da die Kodierung der Ausgabe deines Skripts siehst.

Zeige doch mal bitte den kompletten Code deines Skripts.

PS: Varchar ist ein Spaltentyp in SQL-Datenbanken und genau betrachtet selbst dort nicht einmal ein Datentyp im eigentlichen Sinne, so wie man es vom Typ char oder string kennt.
Das hat mit PHP und anderen Programmiersprachen nichts weiter zu tun. Was du meinst sind ganz einfach Zeichen.

Verfasst: **26.03.2009, 11:24**

Das war zu versuchszwecken ein 1.0 GET mit 1.1 bekomm ich den Encoding Part.

Code: Alles auswählen

		$receive_connection = fsockopen&#40;'domain.com', 80, $error, $error&#41;;
			fputs&#40;$receive_connection, "GET/file.php?itemid=".$product_id." HTTP/1.1\r\n"&#41;;
			fputs&#40;$receive_connection, "Host&#58; domain.com\r\n"&#41;;
			fputs&#40;$receive_connection, "Keep-Alive&#58; 300\r\n"&#41;;
			fputs&#40;$receive_connection, "Connection&#58; keep-alive\r\n\r\n"&#41;;
			  while&#40;!feof&#40;$receive_connection&#41;&#41; &#123;
			      $res .= fgets&#40;$receive_connection, 4096&#41;;
			  &#125;
			$res = substr&#40;$res, strpos&#40;$res, "\r\n\r\n"&#41; + 4&#41;;

			fclose&#40;$receive_connection&#41;;

        var_dump&#40;$res&#41;;

mehr hab ich im script nich.

Hier der Output bei einem 1.1 GET

Code: Alles auswählen

21c9
string&#40;8633&#41; "HTTP/1.1 200 OK
Date&#58; Thu, 26 Mar 2009 10&#58;23&#58;22 GMT
Server&#58; Apache/2.2.11 &#40;Unix&#41; mod_ssl/2.2.11 OpenSSL/0.9.7a DAV/2 mod_bwlimited/1.4 PHP/5.2.8
X-Powered-By&#58; PHP/5.2.8
Keep-Alive&#58; timeout=5, max=100
Connection&#58; Keep-Alive
Transfer-Encoding&#58; chunked
Content-Type&#58; application/x-www-form-urlencoded; charset=utf-8

1ff0
u=haufenweisedata
0

"

0

Verfasst: **26.03.2009, 11:33**

ins0 hat geschrieben:[…]
mehr hab ich script nich.

Sieht auch unverdächtig aus.

Hier der Output bei einem 1.1 GET

Code: Alles auswählen

21c9
string&#40;8633&#41; "HTTP/1.1 200 OK
Date&#58; Thu, 26 Mar 2009 10&#58;23&#58;22 GMT
Server&#58; Apache/2.2.11 &#40;Unix&#41; mod_ssl/2.2.11 OpenSSL/0.9.7a DAV/2 mod_bwlimited/1.4 PHP/5.2.8
X-Powered-By&#58; PHP/5.2.8
Keep-Alive&#58; timeout=5, max=100
Connection&#58; Keep-Alive
Transfer-Encoding&#58; chunked
Content-Type&#58; application/x-www-form-urlencoded; charset=utf-8

1ff0
u=haufenweisedata
0

"

0

Da hast du ja schonmal die chunked-Kodierung, wo wir sie erwarten täten, in der Antwort bzw. in $res, zu erkennen an dem 1ff0.

Zweitens ist zu sehen, dass die äußere Kodierung (die, die dich stört) wieder 16 Bytes länger als das ist, was var_dump() angibt. Zählen wir mal das, was var_dump() selbst ausspuckt, „string(8633) ""“ kommen wir auf 15 Zeichen, zuzüglich der Zeilenschaltung wären das die besagten 16.
Ich bin mir sicher, der Kram stammt nicht aus deinem Skript und steht vor allen Dingen nicht in $res.

Die Frage scheint merkwürdig, aber womit rufst du denn dein Skript auf? Mit einem Browser? Hast du Firefox mit LiveHTTPHeaders oder Firebug? Oder, noch besser, rufe das Skript mit wget ab, dort bekommst du die Skriptantwort wirklich ungefiltert.

Verfasst: **26.03.2009, 11:39**

jup, das sieht ganz klar nach chunked aus. ich stand mal mit jemand in kontakt, der das nicht begriff was diese "zeichen" bedeuten und dann vorwarf, man wuerde ihn mit "debug outputs" bewerfen. nach etwas recherche musste ich ihn auf die rfc seiten leiten

Verfasst: **26.03.2009, 11:40**

Habs nun direkt aus der Console gestartet und dort ist alle im Grünen bereich , so wie man es möchte. HHmm ja hab FireBug und LHTTPH, ist zum ersten ma, das ich so ein Problem habe, ist mir vor lauter nachdenken garnich in den sinn gekommen keinen browser zu verwenden :/

Dank dir Mork für die Unterstützung.

Verfasst: **26.03.2009, 12:31**

- hat sich erübrigt -

ABAKUS

Unknown Header Data

Unknown Header Data