gzip-Komprimierung in beide Richtungen?

[Andreas Korthaus]

Hallo!

Ich schicke Daten per HTTP(S) von einem Server zu einem anderen Server (HTTP-request), und andere Daten wieder im body zurück(HTTP-reponse). Gibt es eine Möglichkeit, den Verkehr in beide Richtungen zu komprimieren? Wenn ich z.B. 200K an Daten schicke dann dauert das schon ein wenig, wenn man z.B. nur über ISDN angebunden ist. Da es sich bei den Daten um SQL-Statements handelt, bin ich sicher das ich das Datenvolumen um bestimmt 70-80 % reduzieren könnte. Womit mache ich sowas sinnvollerweise?

Viele Grüße
Andreas

[Björn Höhrmann]

Ich schicke Daten per HTTP(S) von einem Server zu einem anderen Server (HTTP-request), und andere Daten wieder im body zurück(HTTP-reponse). Gibt es eine Möglichkeit, den Verkehr in beide Richtungen zu komprimieren?

Ja, du kannst hier beliebige Kompressionsverfahren verwenden, wenn du Kontrolle über Sender und Empfänger hast, sie müssen sich nur einig sein, wie die Daten zu dekomprimieren sind. HTTP bietet ja von Haus aus einige Kompressionsverfahren an, auf die bist du allerdings nicht beschränkt. Wenn du allerdings nicht die Kontrolle über beide Anwendungen hast, kannst du nur verwenden, was der jeweilige Empfänger versteht, mir ist nicht bekannt, dass ein Webserver ankommende Daten von sich aus dekomprimiert, unabhängig davon, ob es dafür eine Unterstützung gibt oder nicht, das wäre ansonsten die Alternative Implementationsmöglichkeit.

[Philipp Hasenfratz]

Halihallo Andreas

Ich schicke Daten per HTTP(S) von einem Server zu einem anderen Server (HTTP-request), und andere Daten wieder im body zurück(HTTP-reponse). Gibt es eine Möglichkeit, den Verkehr in beide Richtungen zu komprimieren? Wenn ich z.B. 200K an Daten schicke dann dauert das schon ein wenig, wenn man z.B. nur über ISDN angebunden ist. Da es sich bei den Daten um SQL-Statements handelt, bin ich sicher das ich das Datenvolumen um bestimmt 70-80 % reduzieren könnte. Womit mache ich sowas sinnvollerweise?

Ich schliesse mich der Meinung von Björn an. Du hast ja die Kontrolle über beide Programme. Kannst also übermitteln was du willst. Neulich habe ich das auch bei der Statistik-Synchronisation gemacht:

Ich habe die Daten incore mit Zlib (Compress::Zlib) komprimiert und in den Request-Content gelegt. Dies wird vom Server über <STDIN> eingelesen incore dekomprimiert und dann in die Datenbank eingelesen. Du brauchst dich eigentlich um gar nichts zu kümmern.

Viele Grüsse

Philipp

[Andreas Korthaus]

Hallo!

Ich schliesse mich der Meinung von Björn an. Du hast ja die Kontrolle über beide Programme. Kannst also übermitteln was du willst. Neulich habe ich das auch bei der Statistik-Synchronisation gemacht:

Ich habe die Daten incore mit Zlib (Compress::Zlib) komprimiert und in den Request-Content gelegt. Dies wird vom Server über <STDIN> eingelesen incore dekomprimiert und dann in die Datenbank eingelesen. Du brauchst dich eigentlich um gar nichts zu kümmern.

Also da ich das mit PHP mache, auf beiden Seiten, habe ich das mal wie folgt probiert:

ich übertrage die Daten mit CURL als eine POST-Variable  und komprimiere das so:

encode auf Server 1:
$string = urlencode(gzcompress($data));

decode auf Server 2
echo gzuncompress(urldecode($string));

Das dumme an der Sache, gzip komprimiert wirklich bemerkenswert, fast 90%. Aber durch urlencode, damit ich das als POST-Daten übertragen kann, muß das ganze noch durch urlencode, dadurch wird der String wieder 3 mal so groß, also nichtmal mehr 70% Komprimierung.

Vermutlich schaffe ich das in die eine Richtung, wenn ich CURL klarmache das es sich um binäre Daten handelt, aber wie ist das mit der anderen Richtung? Da gebe ich die Daten einfach normal aus(an Stelle einer Webseite), kann ich da einfach binäre Daten verwenden?

Grüße
Andreas

[Henryk Plötz]

Moin,

Vermutlich schaffe ich das in die eine Richtung, wenn ich CURL klarmache das es sich um binäre Daten handelt

Nuja, vom Prinzip her gibt es keine Beschränkungen für die Daten innerhalb des Bodys, du kannst also auch problemlos binäre Daten da reinpacken, _wenn_ die Gegenseite sie so erwartet und versteht. Wenn ich deinen Aufbau richtig in Erinnerung habe verwendest du aber --data von cURL und sendest die Daten damit url-encoded, so dass sie für PHP wie das Ergebnis eines ganz normalen Formular-Submits aussehen.

Wenn ich die cURL-manpage richtig verstehe, willst du stattdessen einfach --form bla=@- statt --data @- verwenden, wobei du dann die binären Daten an cURL gibst, ohne urlencoding und client_dump= davorzuschreiben. Das sollte dann für PHP so aussehen, als hättest du im Formularfeld namens bla eine Datei hochgeladen.

aber wie ist das mit der anderen Richtung? Da gebe ich die Daten einfach normal aus(an Stelle einer Webseite), kann ich da einfach binäre Daten verwenden?

Jo, HTTP hat kein Problem mit dem Senden von binären Daten, sonst würdest du auch nie ein Bild zu Gesicht bekommen.

--
Henryk Plötz
Grüße von der Ostsee

[Andreas Korthaus]

Hi Henryk!

Nuja, vom Prinzip her gibt es keine Beschränkungen für die Daten innerhalb des Bodys, du kannst also auch problemlos binäre Daten da reinpacken, _wenn_ die Gegenseite sie so erwartet und versteht. Wenn ich deinen Aufbau richtig in Erinnerung habe verwendest du aber --data von cURL und sendest die Daten damit url-encoded, so dass sie für PHP wie das Ergebnis eines ganz normalen Formular-Submits aussehen.

so mach ich das bis jetzt:
<?
$fp = popen("curl --data @- https://www.server.de/env.php > c:/www/curlausgabe.txt", "w");
fputs($fp, "clientdata=".$dump);
pclose($fp);
?>

auf der Gegenseite ertwarte ich das bis jetzt in $_POST["clientdata"]

Wenn ich die cURL-manpage richtig verstehe, willst du stattdessen einfach --form bla=@- statt --data @- verwenden, wobei du dann die binären Daten an cURL gibst, ohne urlencoding und client_dump= davorzuschreiben. Das sollte dann für PHP so aussehen, als hättest du im Formularfeld namens bla eine Datei hochgeladen.

Ich habe das jetzt mal so versucht:
<?
$fp = popen("curl --form @- https://www.server.de/env.php > c:/www/curlausgabe.txt", "w");
fputs($fp, $dump);
pclose($fp);
?>

Was ich in diesem Fall aber bekomme ist ein leeres $_POST["@-"]

und ein

$_ENV["CONTENT_TYPE"] = multipart/form-data; boundary=curlhMHWAiJsTD38wJxNuc4k6wqFkJp

Dann habe ich es mal so versucht:

curl --data-binary @- https://www.server.de/env.php

da bekomme ich allerdings $_SERVER["CONTENT_TYPE"] = application/x-www-form-urlencoded

sonst nichts. $_FILES ist in allen Fällen leer.

Jo, HTTP hat kein Problem mit dem Senden von binären Daten, sonst würdest du auch nie ein Bild zu Gesicht bekommen.

Und CURL braucht keinen Content-Type um das zu verstehen?

Vielen Dank und viele Grüße,
Andreas

[Henryk Plötz]

Moin,

$fp = popen("curl --form @- https://www.server.de/env.php > c:/www/curlausgabe.txt", "w");

Wenn du dir meinen Beitrag nochmal ansiehst, hatte ich "curl --form client_dump=@- https://www.server.de/env.php > c:/www/curlausgabe.txt" geschrieben, und nein, die Angabe eines Namens + darauffolgendes Istgleichzeichen ist - soweit ich die manpage interpretiere - nicht egal. (Der Name kann natürlich quasi beliebig sein.)

Was ich in diesem Fall aber bekomme ist ein leeres $_POST["@-"]

Wenn du es so wie von mir beschrieben machst, solltest du ein $_FILES['client_dump']['tmp_name'] mit der temporären Datei kriegen, sowie den ganzen anderen Upload-Kram wie in der PHP-Doku beschrieben.

Jo, HTTP hat kein Problem mit dem Senden von binären Daten, sonst würdest du auch nie ein Bild zu Gesicht bekommen.
Und CURL braucht keinen Content-Type um das zu verstehen?

Naja, es kann nicht schaden ein Content-Type: application/octet-stream zu senden, aber eigentlich sollte es keine Probleme geben, da cURL den Content-Type gefälligst zu ignorieren hat.

--
Henryk Plötz
Grüße von der Ostsee

[Andreas Korthaus]

Hi!

$fp = popen("curl --form @- https://www.server.de/env.php > c:/www/curlausgabe.txt", "w");

Wenn du dir meinen Beitrag nochmal ansiehst, hatte ich "curl --form client_dump=@- https://www.server.de/env.php > c:/www/curlausgabe.txt" geschrieben, und nein, die Angabe eines Namens + darauffolgendes Istgleichzeichen ist - soweit ich die manpage interpretiere - nicht egal. (Der Name kann natürlich quasi beliebig sein.)

Oh, hatte ich was falsch verstanden. Dann so:

$fp = popen("curl --form clientdata=@- https://www.server.de/env.php", "w");
fputs($fp, gzcompress($dump));
pclose($fp);

auf der anderen Seite versuche ich das so auszulesen:

$file = "test.txt";

move_uploaded_file($_FILES['clientdata']['tmp_name'], $file);

$fp = fopen($file, "r");
$result = fread($fp,1000000);
fclose($fp);
echo $result;
echo gzuncompress($result);

2 Probleme:
1. bekomme ich einen gzuncompress: buffer error,
2. ist die temp-Datei nur 657 Byte groß, obwohl der string von gzcompress($dump) 14.000 Byte groß ist(habe ich mir mit strlen ausgeben lassen).

Naja, es kann nicht schaden ein Content-Type: application/octet-stream zu senden, aber eigentlich sollte es keine Probleme geben, da cURL den Content-Type gefälligst zu ignorieren hat.

Content Type der Temp-Datei ist text/plain.

Hm, was könnte das jetzt sein? Braucht curl evtl noch einen Parameter?

Viele Grüße
Andreas

[Henryk Plötz]

Moin,

$result = fread($fp,1000000);

Besser ist hier fread($fp, filesize($file));

Ich habe mir hier eben mal lokal cURL installiert und habe mit dem selben Code keine Probleme feststellen können. Die Datei die gesendet wird ist genauso groß wie die die letztendlich ankommt und auch dekomprimieren klappt.

Vielleicht musst du zwischen dem fputs() und pclose() beim Senden einfach ein bisschen Pause machen (kann ich mir eigentlich nicht vorstellen)? Sah denn die Ausgabe von echo $result; ok aus (also keine Fehlermeldungen etc.)?

Content Type der Temp-Datei ist text/plain.

Ich meinte eigentlich die Gegenrichtung (vom Server zu cURL) aber da du hier nirgendwo einen allgemeinen HTTP-Clienten sondern von dir kontrollierte Programme hast, ist das auch in Ordnung.

Hm, was könnte das jetzt sein? Braucht curl evtl noch einen Parameter?

Wie gesagt, works for me.

--
Henryk Plötz
Grüße von der Ostsee

[Andreas Korthaus]

Hallo!

Ich habe mir hier eben mal lokal cURL installiert und habe mit dem selben Code keine Probleme feststellen können. Die Datei die gesendet wird ist genauso groß wie die die letztendlich ankommt und auch dekomprimieren klappt.

Also hast Du das auch mal mit einem längeren String probiert? Bekomme dasselbe Problem wie beim schreiben auf die Kommandozeile, was ich ja nicht mache, da ich popen verwende. Wenn ich folgenden String verwende:

$string="asdaösdklaskdlasödsdf9s 9sd 09sd09fsdfus dasfjlkjfd9 0as09dasdjasljdlsakj ad9a 0sd89as klsajdksdf fs s jsdl jsdfi kej klsjdfljs kljkldsjk jldsfj kjdslfjlkdsfssf sdf sdf sdf dfsdfsdfsdf98sd90f8 df89 sd0f809ds8 0ds8f90 8s09f809s 8lasjd js kljkldsjk jldsfj kjdslfjlkdsfssf sdf sdf sdf dfsdfsdfsdf98sdsfsdfsdfs fs sdf sdfsdh jkhsdf sdjfh jkshdjhjdhjhdjkhshfiuez uziu z qpwouip oipwru09320uqiwuilwjledjwqil ueloi wjelidjuoiw eru39po893uprqweqüowuiquj4 oiäejf9ewu üä9poejkjdfdlksalödk öldklwqkökdölkwöl kdölwkdölwkepo qe p0928peoöu oj öoweio piwoeiöioe i üqeiüpqi üpq ie üpqie üp0qie pqeiüqieüp qieüpq iepüqi üei ddsaöl 90f8 df89 sd0f809ds8 0ds8f90 8s09f809s 8lasjd lX1wer 12 1rw qrw";

// so mach ich das jetzt:

$dump=gzcompress($string);

$fp = popen("curl --form clientdata=@- http://www.server.de/env.php > c:/www/curlausgabe.txt", "w");
fputs($fp, $dump);
pclose($fp);

echo "<pre>";
echo "String: ".strlen($string)."\n";
echo "gzip-String: ".strlen($dump)."\n";

$fp2 = fopen("c:/www/curlausgabe.txt", "r");
$result = fread($fp2,1000000);
$time2 = time();
fclose($fp2);

echo $result;
echo "</pre>";

Dann bekomm eich folgende Ausgabe:

String: 677
gzip-String: 353
Array
(
    [clientdata] => Array
        (
            [name] => -
            [type] => text/plain
            [tmp_name] => /tmp/phpg3YiHy
            [size] => 353
        )

)
asdaösdklaskdlasödsdf9s 9sd 09sd09fsdfus ...

hat also geklappt. Wenn ich aber an den String oben ein paar Zeichen dranhänge, sowas wie:

$string="asdaösdklaskdlasödsdf9s 9sd 09sd09fsdfus dasfjlkjfd9 0as09dasdjasljdlsakj ad9a 0sd89as klsajdksdf fs s jsdl jsdfi kej klsjdfljs kljkldsjk jldsfj kjdslfjlkdsfssf sdf sdf sdf dfsdfsdfsdf98sd90f8 df89 sd0f809ds8 0ds8f90 8s09f809s 8lasjd js kljkldsjk jldsfj kjdslfjlkdsfssf sdf sdf sdf dfsdfsdfsdf98sdsfsdfsdfs fs sdf sdfsdh jkhsdf sdjfh jkshdjhjdhjhdjkhshfiuez uziu z qpwouip oipwru09320uqiwuilwjledjwqil ueloi wjelidjuoiw eru39po893uprqweqüowuiquj4 oiäejf9ewu üä9poejkjdfdlksalödk öldklwqkökdölkwöl kdölwkdölwkepo qe p0928peoöu oj öoweio piwoeiöioe i üqeiüpqi üpq ie üpqie üp0qie pqeiüqieüp qieüpq iepüqi üei ddsaöl 90f8 df89 sd0f809ds8 0ds8f90 8s09f809s 8lasjd lX1wer 12 1rw qrw12345";

dann erhalte ich folgende Ausgabe mit selbigem Script:

String: 682
gzip-String: 358
Array
(
    [clientdata] => Array
        (
            [name] => -
            [type] => text/plain
            [tmp_name] => /tmp/phpihTD3G
            [size] => 53
        )

)

Warning:  gzuncompress: buffer error in /www/webseite/env.php on line 12

Wie gesagt, works for me.

auch mit langen Strings? Danke das Du Dir die Mühe gemacht hast!

Grüße
Andreas

[Andreas Korthaus]

Hallo!

was mir noch aufgefallen ist, wenn ich den String direkt übertrage, also nicht komprimiert, dann kann er so lang sein wie er will und es geht immer?!?!?! Also nur wenn ich so wie beschreiben einen längeren komprinierten String übergebe funktioniert da irgendwas nicht!

Grüße
Andreas

[Henryk Plötz]

Moin,

Also hast Du das auch mal mit einem längeren String probiert?

In Ermangelung eines besseren Beispiels habe ich eine 400 Kilobyte große Postscript-Datei geschickt.

Momentan bin also etwas ratlos, da ich das Problem nicht reproduzieren kann. Kannst du mal einen Sniffer drauf ansetzen, die gesamte HTTP-Session mitloggen und hier posten?

--
Henryk Plötz
Grüße von der Ostsee

[Andreas Korthaus]

Hallo!

In Ermangelung eines besseren Beispiels habe ich eine 400 Kilobyte große Postscript-Datei geschickt.

Momentan bin also etwas ratlos, da ich das Problem nicht reproduzieren kann. Kannst du mal einen Sniffer drauf ansetzen, die gesamte HTTP-Session mitloggen und hier posten?

OK, wie das Script aussieht habe ich ja geschrieben, die beiden entschiedenen Pakete:

0001  00 90 1A 10 14 D3 00 40 F4 1E 47 68 88 64 11 00    .ü...Ó.@ô.Ghˆd..
0002  13 27 01 6A 00 21 45 00 01 68 05 E6 40 00 80 06    .'.j.!E..h.æ@.€.
0003  14 60 50 85 88 65 3E 43 C8 1C 04 33 00 50 3E B9    .`P…ˆe>CÈ..3.P>¹
0004  BD 6F 40 12 69 EA 50 18 44 10 A1 A5 00 00 50 4F    ½o@.iêP.D.¡¥..PO
0005  53 54 20 2F 65 6E 76 2E 70 68 70 20 48 54 54 50    ST /env.php HTTP
0006  2F 31 2E 31 0D 0A 55 73 65 72 2D 41 67 65 6E 74    /1.1..User-Agent
0007  3A 20 63 75 72 6C 2F 37 2E 39 2E 38 20 28 77 69    : curl/7.9.8 (wi
0008  6E 33 32 29 20 6C 69 62 63 75 72 6C 20 37 2E 39    n32) libcurl 7.9
0009  2E 38 20 28 4F 70 65 6E 53 53 4C 20 30 2E 39 2E    .8 (OpenSSL 0.9.
000A  36 64 29 0D 0A 48 6F 73 74 3A 20 77 77 77 2E 6B    6d)..Host: www.k
000B  6E 65 74 2D 73 79 73 74 65 6D 73 2E 64 65 0D 0A    net-systems.de..
000C  50 72 61 67 6D 61 3A 20 6E 6F 2D 63 61 63 68 65    Pragma: no-cache
000D  0D 0A 41 63 63 65 70 74 3A 20 69 6D 61 67 65 2F    ..Accept: image/
000E  67 69 66 2C 20 69 6D 61 67 65 2F 78 2D 78 62 69    gif, image/x-xbi
000F  74 6D 61 70 2C 20 69 6D 61 67 65 2F 6A 70 65 67    tmap, image/jpeg
0010  2C 20 69 6D 61 67 65 2F 70 6A 70 65 67 2C 20 2A    , image/pjpeg, *
0011  2F 2A 0D 0A 43 6F 6E 74 65 6E 74 2D 4C 65 6E 67    /*..Content-Leng
0012  74 68 3A 20 32 32 30 0D 0A 45 78 70 65 63 74 3A    th: 220..Expect:
0013  20 31 30 30 2D 63 6F 6E 74 69 6E 75 65 0D 0A 43     100-continue..C
0014  6F 6E 74 65 6E 74 2D 54 79 70 65 3A 20 6D 75 6C    ontent-Type: mul
0015  74 69 70 61 72 74 2F 66 6F 72 6D 2D 64 61 74 61    tipart/form-data
0016  3B 20 62 6F 75 6E 64 61 72 79 3D 63 75 72 6C 4B    ; boundary=curlK
0017  52 54 7A 36 67 38 78 68 51 46 38 50 68 71 7A 33    RTz6g8xhQF8Phqz3
0018  69 4C 75 61 77 4E 54 50 6C 34 0D 0A 0D 0A          iLuawNTPl4....

0001  00 90 1A 10 14 D3 00 40 F4 1E 47 68 88 64 11 00    .ü...Ó.@ô.Ghˆd..
0002  13 27 01 06 00 21 45 00 01 04 05 E7 40 00 80 06    .'...!E....ç@.€.
0003  14 C3 50 85 88 65 3E 43 C8 1C 04 33 00 50 3E B9    .ÃP…ˆe>CÈ..3.P>¹
0004  BE AF 40 12 6A 03 50 18 43 F7 7A 45 00 00 2D 2D    ¾ß@.j.P.C÷zE..--
0005  63 75 72 6C 4B 52 54 7A 36 67 38 78 68 51 46 38    curlKRTz6g8xhQF8
0006  50 68 71 7A 33 69 4C 75 61 77 4E 54 50 6C 34 0D    Phqz3iLuawNTPl4.
0007  0A 43 6F 6E 74 65 6E 74 2D 44 69 73 70 6F 73 69    .Content-Disposi
0008  74 69 6F 6E 3A 20 66 6F 72 6D 2D 64 61 74 61 3B    tion: form-data;
0009  20 6E 61 6D 65 3D 22 63 6C 69 65 6E 74 64 61 74     name="clientdat
000A  61 22 3B 20 66 69 6C 65 6E 61 6D 65 3D 22 2D 22    a"; filename="-"
000B  0D 0A 43 6F 6E 74 65 6E 74 2D 54 79 70 65 3A 20    ..Content-Type:
000C  74 65 78 74 2F 70 6C 61 69 6E 0D 0A 0D 0A 78 9C    text/plain....xœ
000D  A5 51 51 6A 04 21 0C FD 9E 5B E4 08 EE 6E 0B E3    ¥QQj.!.ýž[ä.în.ã
000E  4D FA 2B 24 32 89 82 3A 41 84 3D 6F CF E0 D7 7C    Mú+$2‰‚:A„=oÏà×|
000F  34 EE D2 03 94 82 BE 24 EF 25 26 C1 A0 18 A6 62    4îÒ.”‚¾$ï%&Á .¦b
0010  CA 41 13 0D 0A 2D 2D 63 75 72 6C 4B 52 54 7A 36    ÊA...--curlKRTz6
0011  67 38 78 68 51 46 38 50 68 71 7A 33 69 4C 75 61    g8xhQF8Phqz3iLua
0012  77 4E 54 50 6C 34 2D 2D 0D 0A                      wNTPl4--..

Die ausgabe lautet:

String: 682
gzip-String: 358
Array
(
    [clientdata] => Array
        (
            [name] => -
            [type] => text/plain
            [tmp_name] => /tmp/phpm8ldUF
            [size] => 53
        )

)

Warning:  gzuncompress: buffer error in /kunden/knet-systems.de/webseite/env.php on line 12

Wie gesagt, wenn ich ein paar Bytes weglasse funktionierts perfekt! Danke für Deine Mühen!

Viele Grüße an die Ostsee!
Andreas

[Andreas Korthaus]

Hi! Hier  mal zum Vergleich dasselbe Script,, nur das ich den String um die letzten 5 Bytes gekürzt habe, wie oben beschreiben:

OK, wie das Script aussieht habe ich ja geschrieben, die beiden entschiedenen Pakete:

0001  00 90 1A 10 14 D3 00 40 F4 1E 47 68 88 64 11 00    .ü...Ó.@ô.Ghˆd.. 0002  13 27 01 6A 00 21 45 00 01 68 05 E6 40 00 80 06    .'.j.!E..h.æ@.€. 0003  14 60 50 85 88 65 3E 43 C8 1C 04 33 00 50 3E B9    .`P…ˆe>CÈ..3.P>¹ 0004  BD 6F 40 12 69 EA 50 18 44 10 A1 A5 00 00 50 4F    ½o@.iêP.D.¡¥..PO 0005  53 54 20 2F 65 6E 76 2E 70 68 70 20 48 54 54 50    ST /env.php HTTP 0006  2F 31 2E 31 0D 0A 55 73 65 72 2D 41 67 65 6E 74    /1.1..User-Agent 0007  3A 20 63 75 72 6C 2F 37 2E 39 2E 38 20 28 77 69    : curl/7.9.8 (wi 0008  6E 33 32 29 20 6C 69 62 63 75 72 6C 20 37 2E 39    n32) libcurl 7.9 0009  2E 38 20 28 4F 70 65 6E 53 53 4C 20 30 2E 39 2E    .8 (OpenSSL 0.9. 000A  36 64 29 0D 0A 48 6F 73 74 3A 20 77 77 77 2E 6B    6d)..Host: www.k 000B  6E 65 74 2D 73 79 73 74 65 6D 73 2E 64 65 0D 0A    net-systems.de.. 000C  50 72 61 67 6D 61 3A 20 6E 6F 2D 63 61 63 68 65    Pragma: no-cache 000D  0D 0A 41 63 63 65 70 74 3A 20 69 6D 61 67 65 2F    ..Accept: image/ 000E  67 69 66 2C 20 69 6D 61 67 65 2F 78 2D 78 62 69    gif, image/x-xbi 000F  74 6D 61 70 2C 20 69 6D 61 67 65 2F 6A 70 65 67    tmap, image/jpeg 0010  2C 20 69 6D 61 67 65 2F 70 6A 70 65 67 2C 20 2A    , image/pjpeg, * 0011  2F 2A 0D 0A 43 6F 6E 74 65 6E 74 2D 4C 65 6E 67    /*..Content-Leng 0012  74 68 3A 20 32 32 30 0D 0A 45 78 70 65 63 74 3A    th: 220..Expect: 0013  20 31 30 30 2D 63 6F 6E 74 69 6E 75 65 0D 0A 43     100-continue..C 0014  6F 6E 74 65 6E 74 2D 54 79 70 65 3A 20 6D 75 6C    ontent-Type: mul 0015  74 69 70 61 72 74 2F 66 6F 72 6D 2D 64 61 74 61    tipart/form-data 0016  3B 20 62 6F 75 6E 64 61 72 79 3D 63 75 72 6C 4B    ; boundary=curlK 0017  52 54 7A 36 67 38 78 68 51 46 38 50 68 71 7A 33    RTz6g8xhQF8Phqz3 0018  69 4C 75 61 77 4E 54 50 6C 34 0D 0A 0D 0A          iLuawNTPl4....

oben das fehlgeschlagene Script, unten das kürzere welches funktioniert:

0001  00 90 1A 10 14 D3 00 40 F4 1E 47 68 88 64 11 00    .ü...Ó.@ô.Ghˆd.. 0002  18 29 01 6A 00 21 45 00 01 68 0D 84 40 00 80 06    .).j.!E..h.„@.€. 0003  12 25 50 85 83 02 3E 43 C8 1C 04 5A 00 50 56 06    .%P…ƒ.>CÈ..Z.PV. 0004  AD 07 A2 8E BB F0 50 18 44 10 C0 4D 00 00 50 4F    -.¢Ž»ðP.D.ÀM..PO 0005  53 54 20 2F 65 6E 76 2E 70 68 70 20 48 54 54 50    ST /env.php HTTP 0006  2F 31 2E 31 0D 0A 55 73 65 72 2D 41 67 65 6E 74    /1.1..User-Agent 0007  3A 20 63 75 72 6C 2F 37 2E 39 2E 38 20 28 77 69    : curl/7.9.8 (wi 0008  6E 33 32 29 20 6C 69 62 63 75 72 6C 20 37 2E 39    n32) libcurl 7.9 0009  2E 38 20 28 4F 70 65 6E 53 53 4C 20 30 2E 39 2E    .8 (OpenSSL 0.9. 000A  36 64 29 0D 0A 48 6F 73 74 3A 20 77 77 77 2E 6B    6d)..Host: www.k 000B  6E 65 74 2D 73 79 73 74 65 6D 73 2E 64 65 0D 0A    net-systems.de.. 000C  50 72 61 67 6D 61 3A 20 6E 6F 2D 63 61 63 68 65    Pragma: no-cache 000D  0D 0A 41 63 63 65 70 74 3A 20 69 6D 61 67 65 2F    ..Accept: image/ 000E  67 69 66 2C 20 69 6D 61 67 65 2F 78 2D 78 62 69    gif, image/x-xbi 000F  74 6D 61 70 2C 20 69 6D 61 67 65 2F 6A 70 65 67    tmap, image/jpeg 0010  2C 20 69 6D 61 67 65 2F 70 6A 70 65 67 2C 20 2A    , image/pjpeg, * 0011  2F 2A 0D 0A 43 6F 6E 74 65 6E 74 2D 4C 65 6E 67    /*..Content-Leng 0012  74 68 3A 20 35 32 30 0D 0A 45 78 70 65 63 74 3A    th: 520..Expect: 0013  20 31 30 30 2D 63 6F 6E 74 69 6E 75 65 0D 0A 43     100-continue..C 0014  6F 6E 74 65 6E 74 2D 54 79 70 65 3A 20 6D 75 6C    ontent-Type: mul 0015  74 69 70 61 72 74 2F 66 6F 72 6D 2D 64 61 74 61    tipart/form-data 0016  3B 20 62 6F 75 6E 64 61 72 79 3D 63 75 72 6C 52    ; boundary=curlR 0017  37 45 76 4B 51 70 51 63 7A 6B 65 30 58 4A 48 45    7EvKQpQczke0XJHE 0018  49 42 7A 32 45 36 47 70 36 62 0D 0A 0D 0A          IBz2E6Gp6b....

0001  00 90 1A 10 14 D3 00 40 F4 1E 47 68 88 64 11 00    .ü...Ó.@ô.Ghˆd.. 0002  13 27 01 06 00 21 45 00 01 04 05 E7 40 00 80 06    .'...!E....ç@.€. 0003  14 C3 50 85 88 65 3E 43 C8 1C 04 33 00 50 3E B9    .ÃP…ˆe>CÈ..3.P>¹ 0004  BE AF 40 12 6A 03 50 18 43 F7 7A 45 00 00 2D 2D    ¾ß@.j.P.C÷zE..-- 0005  63 75 72 6C 4B 52 54 7A 36 67 38 78 68 51 46 38    curlKRTz6g8xhQF8 0006  50 68 71 7A 33 69 4C 75 61 77 4E 54 50 6C 34 0D    Phqz3iLuawNTPl4. 0007  0A 43 6F 6E 74 65 6E 74 2D 44 69 73 70 6F 73 69    .Content-Disposi 0008  74 69 6F 6E 3A 20 66 6F 72 6D 2D 64 61 74 61 3B    tion: form-data; 0009  20 6E 61 6D 65 3D 22 63 6C 69 65 6E 74 64 61 74     name="clientdat 000A  61 22 3B 20 66 69 6C 65 6E 61 6D 65 3D 22 2D 22    a"; filename="-" 000B  0D 0A 43 6F 6E 74 65 6E 74 2D 54 79 70 65 3A 20    ..Content-Type: 000C  74 65 78 74 2F 70 6C 61 69 6E 0D 0A 0D 0A 78 9C    text/plain....xœ 000D  A5 51 51 6A 04 21 0C FD 9E 5B E4 08 EE 6E 0B E3    ¥QQj.!.ýž[ä.în.ã 000E  4D FA 2B 24 32 89 82 3A 41 84 3D 6F CF E0 D7 7C    Mú+$2‰‚:A„=oÏà×| 000F  34 EE D2 03 94 82 BE 24 EF 25 26 C1 A0 18 A6 62    4îÒ.”‚¾$ï%&Á .¦b 0010  CA 41 13 0D 0A 2D 2D 63 75 72 6C 4B 52 54 7A 36    ÊA...--curlKRTz6 0011  67 38 78 68 51 46 38 50 68 71 7A 33 69 4C 75 61    g8xhQF8Phqz3iLua 0012  77 4E 54 50 6C 34 2D 2D 0D 0A                      wNTPl4--..

oben das fehlgeschlagene Script, unten das kürzere welches funktioniert:

0001  00 90 1A 10 14 D3 00 40 F4 1E 47 68 88 64 11 00    .ü...Ó.@ô.Ghˆd.. 0002  18 29 02 32 00 21 45 00 02 30 0D 85 40 00 80 06    .).2.!E..0.…@.€. 0003  11 5C 50 85 83 02 3E 43 C8 1C 04 5A 00 50 56 06    .\P…ƒ.>CÈ..Z.PV. 0004  AE 47 A2 8E BC 09 50 18 43 F7 44 49 00 00 2D 2D    ®G¢Ž¼.P.C÷DI..-- 0005  63 75 72 6C 52 37 45 76 4B 51 70 51 63 7A 6B 65    curlR7EvKQpQczke 0006  30 58 4A 48 45 49 42 7A 32 45 36 47 70 36 62 0D    0XJHEIBz2E6Gp6b. 0007  0A 43 6F 6E 74 65 6E 74 2D 44 69 73 70 6F 73 69    .Content-Disposi 0008  74 69 6F 6E 3A 20 66 6F 72 6D 2D 64 61 74 61 3B    tion: form-data; 0009  20 6E 61 6D 65 3D 22 63 6C 69 65 6E 74 64 61 74     name="clientdat 000A  61 22 3B 20 66 69 6C 65 6E 61 6D 65 3D 22 2D 22    a"; filename="-" 000B  0D 0A 43 6F 6E 74 65 6E 74 2D 54 79 70 65 3A 20    ..Content-Type: 000C  74 65 78 74 2F 70 6C 61 69 6E 0D 0A 0D 0A 78 9C    text/plain....xœ 000D  A5 51 41 8E 04 21 08 3C F7 2F 78 82 33 B3 87 F6    ¥QAŽ.!.<÷/x‚3³‡ö 000E  27 7B 35 01 D3 A0 89 DA C4 98 CC 7B F7 0D 9E FA    '{5.Ó ‰ÚĘÌ{÷.žú 000F  B0 38 93 79 C0 66 13 2D A0 0A 04 62 50 0C 53 31    °8“yÀf.- ..bP.S1 0010  E5 A0 09 0D 26 2A 46 AF E0 15 C1 19 38 1F 8D E8    å ..&*Fßà.Á.8.ìè 0011  0A 18 34 4A 4E 12 D1 83 0B EA BC 11 28 41 B3 60    ..4JN.у.ê¼.(A³` 0012  D6 90 04 02 FA 00 4E 71 F7 41 21 19 27 98 AC 14    Öü..ú.Nq÷A!.'˜¬. 0013  A2 82 82 28 E6 05 91 21 91 2C 59 30 66 59 89 92    ¢‚‚(æ.‘!‘,Y0fY‰’ 0014  32 AA 24 10 33 D1 24 41 CD AB 93 45 AA 11 D6 13    2ª$.3Ñ$AÍ«“Eª.Ö. 0015  9F 8B 6B 96 F7 F1 BB A2 77 71 37 6E F7 26 9A 6B    Ÿ‹k–÷ñ»¢wq7n÷&šk 0016  23 E9 0E CE 20 7A 07 BB 8D B8 38 85 DD D6 12 84    #é.Î z.»ì¸8…ÝÖ.„ 0017  7F 36 D3 4F F8 5A E8 9D A3 78 80 A4 E3 1D 49 5C    6ÓOøZèØ£x€¤ã.I
0018  81 1E 28 87 E0 21 66 4D 39 22 77 7A 42 7F 72 87    ü.(‡à!fM9"wzBr‡ 0019  27 B4 3A 4A E7 0A 85 EB 38 BB F3 8F BB EB 8D 47    '´:Jç.…ë8»óÅ»ëìG 001A  E7 3C 24 13 CA 68 9C A1 53 2E 0C 43 28 33 4A 2F    ç<$.Êhœ¡S..C(3J/ 001B  3C 80 CE FE F0 B5 EC FE D1 EB D9 06 B5 AB 58 4D    <€ÎþðµìþÑëÙ.µ«XM 001C  EB F2 65 2F FD 90 44 4F A3 C3 F5 63 39 24 B6 52    ëòe/ýüDO£Ãõc9$¶R 001D  C4 9C 34 E4 89 09 66 B6 AF 1D 2D CD 84 33 A7 31    Äœ4ä‰.f¶ß.-Í„3§1 001E  33 2C 67 BC 81 6A 81 46 50 9D BF EF 95 CA EC 50    3,g¼üjüFPØ¿ï•ÊìP 001F  04 66 19 C4 05 2A 8F 42 3C B9 D0 C6 70 35 E2 AB    .f.Ä.*ÅB<¹ÐÆp5â« 0020  36 73 6A DB 98 96 79 A1 5B A6 2E D1 9C AB 6E 2F    6sjÛ˜–y¡[¦.Ñœ«n/ 0021  5C 19 D5 88 ED 22 06 44 0D D6 F4 6F 3F 95 BF 6F    .Õˆí".D.Öôo?•¿o 0022  83 4E B8 DD E1 76 8E AD 9D E3 17 43 C0 02 68 0D    ƒN¸ÝávŽ-Øã.CÀ.h. 0023  0A 2D 2D 63 75 72 6C 52 37 45 76 4B 51 70 51 63    .--curlR7EvKQpQc 0024  7A 6B 65 30 58 4A 48 45 49 42 7A 32 45 36 47 70    zke0XJHEIBz2E6Gp 0025  36 62 2D 2D 0D 0A                                  6b--..

Die ausgabe lautet:

String: 682 gzip-String: 358 Array (     [clientdata] => Array         (             [name] => -             [type] => text/plain             [tmp_name] => /tmp/phpm8ldUF             [size] => 53         )

)

Warning:  gzuncompress: buffer error in /kunden/knet-systems.de/webseite/env.php on line 12

oben die Ausgabe des fehlgeschlagenen Scripts, unten die des kürzeren welches funktioniert:

String: 677 gzip-String: 353 Array (     [clientdata] => Array         (             [name] => -             [type] => text/plain             [tmp_name] => /tmp/phpYV3NS2             [size] => 353         )

) asdaösdklaskdlasödsdf9s 9sd 09sd09fsdfus dasfjlkjfd9 0as09dasdjasljdlsakj ad9a 0sd89as klsajdksdf fs s jsdl jsdfi kej klsjdfljs [...]

Ich habe nichts verändert außer die letzten 5 Bytes aus dem String zu entfenen! Hat es vielleicht was damit zu tun das ich die Windows-Version verwende? Das komische an der Sache, das ganze mit gz funktioniert sobald ich das entsprechende ";" vor der dll in der php.ini entferne, ob jetzt eine php_zlib.dll im c:\winnt\system32\ Verzsichnis liegt der nicht, gans seltsam sag ich dir! Aber es funktioniert ob mit oder ohne gleich gut/schlecht(siehe kurzer String)! Ich habe eine neue Foxserv Installation(PHP4.2,Apache2) auf Win2K laufen, auf der anderen Seite Linux(PHP4.1.2,Apache1.3). Ich habe wirklich keine Ahnung! Kannst Du mir vielleicht mal Dein Script mit der ps-Datei posten/schicken? Vielleicht mache ich ja irgendeinen dummen Fehler woanders?

Viele Grüße Andreas

[Philipp Hasenfratz]

Halihallo Andreas

String: 682
gzip-String: 358
Array
(
    [clientdata] => Array
        (
            [name] => -
            [type] => text/plain
            [tmp_name] => /tmp/phpm8ldUF
            [size] => 53
        )

)

Warning:  gzuncompress: buffer error in /kunden/knet-systems.de/webseite/env.php on line 12

Wie gesagt, wenn ich ein paar Bytes weglasse funktionierts perfekt! Danke für Deine Mühen!

Ich kann mir leider nicht so wirklich vorstellen, wo der Fehler sein könnte; könnte ja auch verschiedene Ursachen haben. Versuch doch einmal alle Zeichen im Intervall 0-32 und eventuell 126-255 zu kodieren; ich könnte mir nämlich vorstellen, dass CURL bei einem gewissen Zeichen abbricht, weil es das Zeichen als Steuercode interpretiert und den String zu früh als beendet interpretiert...

Ist leider das einzige, was mir grad in Sinn kommt...!??

Viele Grüsse

Philipp

[Andreas Korthaus]

Hi!

Ich kann mir leider nicht so wirklich vorstellen, wo der Fehler sein könnte; könnte ja auch verschiedene Ursachen haben. Versuch doch einmal alle Zeichen im Intervall 0-32 und eventuell 126-255 zu kodieren; ich könnte mir nämlich vorstellen, dass CURL bei einem gewissen Zeichen abbricht, weil es das Zeichen als Steuercode interpretiert und den String zu früh als beendet interpretiert...

Hm. Auf alle Fälle ist das was da am anderen Ende ankommt kein gültiger gzip String. Ich kann mir das miot den Zeichen als Steuercode nicht vorstellen, denn ich übergebe den Binärcode komplett ab die Standardeingabe von Curl, da sollte Curl eigentlich egal sein was da kommt, das ist binärcode und der wird soweit ich den header verstehe ist das der entscheidene Teil:

¾ß@.j.P.C÷zE..--
curlKRTz6g8xhQF8
Phqz3iLuawNTPl4.
.Content-Disposi
tion: form-data;
 name="clientdat
a"; filename="-"
..Content-Type:
text/plain....xœ
¥QQj.!.ýž[ä.în.ã
Mú+$2‰‚:A„=oÏà×|
4îÒ.”‚¾$ï%&Á .¦b
ÊA...--curlKRTz6
g8xhQF8Phqz3iLua
wNTPl4--..

--curlKRTz6g8xhQF8Phqz3iLuawNTPl4 ist doch dieser boundary-String oder wie das hieß, und der ist dann wieder am Ende, was dazwischen kommt sollte doch recht egal sein, oder? Das Problem muß schon vorher passieren, denn der gz-String den ich in PHP mit gzcompress()(nicht gzinflate!) erzeuge ist ja korrekt, das habe ich breits geprüft. Ich öffne ja die Shell(Dos) mit popen(), und übergebe mit fputs() den gz-String an die Standardeingabe von curl. vermutlich passiert da unterwegs irgendwas unvorhergesehenes, kann ja auch ein bug in der Windowsversion von Curl oder PHP oder auch Windows2000 selbst sein, aber es wäre schon etwas vermessen wenn ich das ganze jetzt auf einen bug schiebe, vermutlich habe ich einen Fehler gemacht, nur wo?

Vielleicht sollte ich --data-binary versuchen?

To post data purely binary, you should instead use  the
          --data-binary option.

--data-binary <data>
          (HTTP)  This  posts data in a similar manner as --data-
          ascii does, although when using this option the  entire
          context  of  the posted data is kept as-is. If you want
          to post a binary file without the  strip-newlines  fea-
          ture of the --data-ascii option, this is for you.

aber das hat so nicht funktioniert(wenn ich einach --form durch --data-binary ersetze). Vor allem wird das ja nicht als multipart/form-data übertragen, oder?

Ich habe mir mal bei Curl stderr ausgeben lassen, im Fall das es scheitert(zu langer String) bekomme ich:

% Total    % Received % Xferd  Average Speed          Time             Curr.
                                 Dload  Upload Total    Current  Left    Speed

100   220    0     0  100   220      0    912  0:00:00  0:00:00  0:00:00   912
100   220    0     0  100   220      0    876  0:00:00  0:00:00  0:00:00     0
100   262    0    42  100   220     74    392  0:00:00  0:00:00  0:00:00     0
100   522    0   302  100   220    391    285  0:00:00  0:00:00  0:00:00   154
100   522    0   302  100   220    391    285  0:00:00  0:00:00  0:00:00   154

Mit dem kürzeren String, wo es funktioniert erhalte ich:

% Total    % Received % Xferd  Average Speed          Time             Curr.
                                 Dload  Upload Total    Current  Left    Speed

100   520    0     0  100   520      0    158  0:00:03  0:00:03  0:00:00   158
100   520    0     0  100   520      0    151  0:00:03  0:00:03  0:00:00     0
100  1294    0   774  100   520    211    142  0:00:03  0:00:03  0:00:00   684
100  1378    0   858  100   520    234    142  0:00:03  0:00:03  0:00:00   911

Ich verstehe inzwischen überhaupt nichts mehr inzwischen läuft noch nicht mal mehr die Variante mit --data. es ist reiner Zufall ob CURL den String nun überträgt oder nicht. Und bei der --data Variante war das ganze noch urlencodet! Also da ist bestimmt nichts mit Sonderzeichen. Wie gesagt, nur ganz bestimmt Strings funkrionieren, die meisten aber nicht. Ich teste jetzt schon wiedr seit Stunden, wobei ich langsam glaube das Curl dochnicht das richtige ist. Vermutlich ist es nur ne KLeinigkeit, aber die werde ich wohl nicht mehr finden...

depressive Grüße,

Andreas

[Philipp Hasenfratz]

Halihallo Andreas

Ich kann mir leider nicht so wirklich vorstellen, wo der Fehler sein könnte; könnte ja auch verschiedene Ursachen haben. Versuch doch einmal alle Zeichen im Intervall 0-32 und eventuell 126-255 zu kodieren; ich könnte mir nämlich vorstellen, dass CURL bei einem gewissen Zeichen abbricht, weil es das Zeichen als Steuercode interpretiert und den String zu früh als beendet interpretiert...
Hm. Auf alle Fälle ist das was da am anderen Ende ankommt kein gültiger gzip String.

Also, entweder es liegt bei der Übertragung, was ich nicht glaube, oder CURL liest nicht alles ein, oder bei CURL kommt gar nicht alles an, weil z. B. die Konsole die Eingabe schon als geschlossen erachtet...

Ich kann mir das miot den Zeichen als Steuercode nicht vorstellen, denn ich übergebe den Binärcode komplett ab die Standardeingabe von Curl, da sollte Curl eigentlich egal sein was da kommt,

Ich kenne mich "einwenig zu wenig" damit aus, aber es könnte sein, dass hier die Konsole noch was zu sagen hat...???

--curlKRTz6g8xhQF8Phqz3iLuawNTPl4 ist doch dieser boundary-String oder wie das hieß, und der ist dann wieder am Ende, was dazwischen kommt sollte doch recht egal sein, oder?

Ja.

Das Problem muß schon vorher passieren, denn der gz-String den ich in PHP mit gzcompress()(nicht gzinflate!) erzeuge ist ja korrekt, das habe ich breits geprüft. Ich öffne ja die Shell(Dos) mit popen(), und übergebe mit fputs() den gz-String an die Standardeingabe von curl.

hast du den Handler aber schon auch auf binary gesetzt, oder? - Ich habe nämlich in dem gzwurm einige 0a0d's gesehen => riecht nach win, obwohl dort nur vielleicht ein 0d stehen sollte... binmode(HANDLE)!

vermutlich passiert da unterwegs irgendwas unvorhergesehenes, kann ja auch ein bug in der Windowsversion von Curl oder PHP oder auch Windows2000 selbst sein,

bestimmt letzteres :-)
Ich kann mir hier eben sehr gut vorstellen, dass die \015 durch \015\012 übersetzt werden...

aber es wäre schon etwas vermessen wenn ich das ganze jetzt auf einen bug schiebe, vermutlich habe ich einen Fehler gemacht, nur wo?

Vielleicht sollte ich --data-binary versuchen?

das klingt schon mal gut.

aber das hat so nicht funktioniert(wenn ich einach --form durch --data-binary ersetze). Vor allem wird das ja nicht als multipart/form-data übertragen, oder?

Muss doch auch nicht... Die POST-Daten kannst du ja dann über STDIN einlesen (php?); achung: auch hier wieder zuerst binmode(STDIN). Und dann den eingelesenen String an gz übergeben.

Ich verstehe inzwischen überhaupt nichts mehr inzwischen läuft noch nicht mal mehr die Variante mit --data. es ist reiner Zufall ob CURL den String nun überträgt oder nicht.

Nix Zufall, das gibt's nicht ;-)
Vielleicht heisst der Zufall, dass ein Zeilenumbruch im gzString ist, der nicht 1:1 sondern eben Win:irgendwas übersetzt wird??? :-)

Und bei der --data Variante war das ganze noch urlencodet!

Nun, das hätte ja auch sein können, aber in der binary Geschichte ist das Problem ja schon vorher geschehen.

Viele Grüsse

Philipp

PS: Wehe dir, du hast die Dateihandles nicht auf binmode gesetzt! :-)) Das Problem'schen kommt mir irgendwie bekannt vor :-)

[Andreas Korthaus]

Hi!

Also ich habe kapituliert. Das soll halt nicht sein. Ohne gz bekomme ich das ohne Probleme hin, aber mit klappt noch nichtmal mehr die Übertragung als POST Variable, siehe </?m=136434&t=24834>. Das Problem liegt in de Kombination von Binärdaten/Windows/und meiner Unwissenheit. Ich habe keinen Schimmer von Binärdaten, ich habe popen auch mal mit "wb" anstatt nur "w" versucht, weiß aber nicht ob das bei popen genau so funktioniert wie bei fopen, jedenfalls funktioniert es nicht. Problem ist ja auch das ich auf dem 2. Server die binären Daten in eine txt-Dateis schreibe die dann öffne und dekomprimieren will. Ich weiß nicht wo, aber vermutlich sind da sogar noch mehrere Feher drin. Ich habe mich heute schon wieder 5 Stunden mit dem Mist beschäftigt, und ich weiß einfach nicht mehr weiter. Ich versuche es jetzt anders, erstmal noch mit der CURL-Implementierung in PHP, und wenn das auch nicht will, dann bleibt mir immer noch das direkte Ansprechen von MYSQL über X11 Forewarding. Mich wundert nur, das ich noch nichtmal die 60-70% Komprimierung von Anfang hinbekomme. Der Witz an der ganzen Sache, manche Strings gehen, aber lange gehen nicht, und kurze wie "hallo" genau so wenig. Vielleicht muß ich auch eine richtige gz-file generieren, die hochladen und die entpacken, das würde vermutlich gehen, aber kann es das sein? mit gzip habe ich eh schonmal Probleme gehabt, anscheinend kann man mit einem Binärstring nicht so umgehen wie mit einem "normalen" string. Bei der --data Variante scheitert es irgendwo auf dem 2. Server denn die Daten werden korrekt vom ersten Server übertragen(hab mir den http-Verkehr angesehen), aber der 2. Server hat Probleme mit den urlencodeten Binärdaten umzugehen.
Bei der --form Variante ist das Problem genau anders herum, da gehen nur 657 Bytes raus, egal was ich mit dem Handler mache. Und da ich keine Ahnung davon habe sondern nur wild rumrate, hat es eigentlich keinen großen Sinn mehr.

Danke für Eure Hilfe, habe wenigstens einiges gelernt, wenn auch nicht genug :-(

Viele Grüße
Andreas

PS: @Henryk, wenn Du mir Dein Script wo es mit einer 400KB PS Datei funktioniert hat mal schicken könntest wäre ich Dir sehr dankbar!

[Henryk Plötz]

Moin,

dann bleibt mir immer noch das direkte Ansprechen von MYSQL über X11 Forewarding.

Öhm, X11 Forwarding und MySQL haben nichts miteinander zu tun. Du meinst das allgemeine Portforwarding von SSH, und die Idee ist nicht schlecht. Übrigens reicht dafür auch stunnel, du musst also nicht gleich eine interaktive SSH-Verbindung aufmachen. Übrigens(2) kann SSH (und hoffentlich auch stunnel) die Verbindung auch transparent komprimieren.

PS: @Henryk, wenn Du mir Dein Script wo es mit einer 400KB PS Datei funktioniert hat mal schicken könntest wäre ich Dir sehr dankbar!

Öhm, das habe ich grad nicht auf dem Rechner, aber ich versuche mal es abzutippen:
curlsend.php:
<?php
$fp=fopen("test.ps","r");
$dump=fread($fp,filesize("test.ps"));
fclose($fp);

$fp = popen("curl --form da=@- http://localhost/~henryk/curltest.php > /tmp/curlaus","w");
fputs($fp,gzcompress($dump));
fclose($fp);
?>

curtest.php:
<?php print_r($_FILES);
$fp = fopen($_FILES['da']['tmp_name'],"r");
$content = fread($fp, filesize($_FILES['da']['tmp_name']));
fclose($fp);
echo strlen($content)." ".filesize($_FILES['da']['tmp_name'])."\n";
$fp=fopen("/tmp/test1.ps","w");
fwrite($fp, gzuncompress($content));
fclose($fp);
?>

Die lagen beide in meinem public_html zusamen mit der test.ps.
Ich habe das dann mit lynx http://localhost/~henryk/curlsend.php aufgerufen und mich in /tmp/curlsend davon überzeugt sowie mit diff test.ps /tmp/test1.ps davon überzeugt, dass alles glattging. (Die Datei war übringens 'nur' 304 kB groß.)

Das ganze war PHP 4.2.2 als Modul auf Apache 1.3.26 unter Linux 2.4.18 mit cURL 7.9.7.

--
Henryk Plötz
Grüße von der Ostsee

[Andreas Korthaus]

Hi!

Öhm, X11 Forwarding und MySQL haben nichts miteinander zu tun. Du meinst das allgemeine Portforwarding von SSH, und die Idee ist nicht schlecht. Übrigens reicht dafür auch stunnel, du musst also nicht gleich eine interaktive SSH-Verbindung aufmachen. Übrigens(2) kann SSH (und hoffentlich auch stunnel) die Verbindung auch transparent komprimieren.

Ja, und das wäre auch das Problem - wie öffne ich eine interaktive SSH-Verbindung automatisch? Mit plink und pscp geht das ja aber nur für sehr begrenzte Anwendungsbereiche. SCP wäre zwar perfekt, aber das darf ich auf dem Masterserver nicht verwenden. Das einzige was ich kann, ist das:

<quote>
Der Zugriff auf mySQL über SSH Port-Forwarding ist durchaus möglich, allerdings nicht unbedingt nötig, da ja lokal auf den Webservern ein mySQL Client installiert wurde, eben damit nicht jeder anfängt, SSH-Ports zu tunneln.
Aufpassen sollte man aber wie man den Tunnel einstellt.
Die korrekte Anweisung ist nämlich
-L 3306:127.0.0.1:3306
und eben nicht
-L 3306:<ip des webservers>:3306
</quote>

MySQL ist nach außen nicht erreichbar, nur über den localhost. Dann müßte ich den Tunnel wohl lokal einrichten oder wie? Aber wie soll das gehen? Ich müßte lokal von PHP aus eine Verbindung zu beiden Servern herstellen können, gleichzeitig. Dann sollte ich wohl entweder dem Tunnel oder der Lokalen DB einen anderen Port geben, vermutlich kann  ich in PHP MYsql auch über einen anderen Port ansprechen. Wenn  ich das lokal im Tunnel angebe und ich eine Verbindung zum entfernten SSH-Server aufgebaut habe, kommen die Anfragen an localhost:3306 automatisch an den entferntet Server "von innen" an 3306??? Und wie kann ich das einrichten ohne dass ich mit putty jedesmal von Hand eine Verbindung herstelle? Gibt es dafür vielleicht ein Kommandozeilentool, welches ich aus PHP heraus starten und die Verbindung herstellen kann?

Öhm, das habe ich grad nicht auf dem Rechner, aber ich versuche mal

Danke Dir für die Mühe, aber ich habs genau so gemacht: läuft genauso wenig.

Naja, da wollte ich doch direkt mal die PHP_CURL Version probieren, aber denkste, das läuft bei mir nicht, keine Ahnung wieso, bin nicht der einzige mit dem Problem, jedenfalls habe ich mehrere Workarounds versucht und es hat alles nicht geklappt. Das Problem, Apache findet die php_curl.dll nicht - obwohl sie definitiv vorhanden ist :-) Ich glaube irgendjemand will nicht das ich das je ans laufen bekomme ;-)
Naja, vermutlich ist der Weg dann auch versperrt, genauso der über CURL und --data (</?m=136434&t=24834>), und es sieht auch nicht so aus als würde es jemals mit --form funktionieren, naja, aml gucken wie das mit SSH aussieht! Wobei eine SSl Lösung vermutlich die einfachere ist, vielleicht sollte ich es auch mal mit php_openssl versuchen, jedenfalls habe ich mir auch mal Deinen Vorschlag(stunnel) angesehen, wobei mir das ganz wie eine client-server Applikation aussieht, und wie ich es sehe kann ich stunnel auf dem 2. Server nicht installieren ;-)

Vielleicht ist dei SSh Variante wirklich die einzige Möglichkeit? Ich habe serverseitig halt nur den SSH-Server und den Apache die Verbindungen entgegennehmen können. Mal gucken, vielleicht bekomme ich meinen Provider dazu stunnel zu installieren, wäre ja wirklich nicht schlecht!

Danke nochmal für Deine Hilfe!

Grüße
Andreas

[Henryk Plötz]

Moin,

Ja, und das wäre auch das Problem - wie öffne ich eine interaktive SSH-Verbindung automatisch? Mit plink und pscp geht das ja aber nur für sehr begrenzte Anwendungsbereiche.

Plink und Putty sind alles was du brauchst (zugegebenermaßen eine neuere Version von putty als ich installiert hatte). Mit putty 0.52 (zumindest habe ich das jetzt installiert) und plink geht das folgendermaßen: Starte putty und mach eine neue Konfiguration fertig. Hostname eingeben, SSH auswählen, dann links Connection anklicken und rechts bei Auto-login username den Benutzernamen eingeben. Links unter Auth kannst du übrigens einen privaten Schlüssel angeben, dazu komme ich gleich. Links Tunnels auswählen und du kannst rechts einen Tunnel konfigurieren. Wähle Local und denk dir einen Source port aus, 3306 ist ok (das wird der Port sein, den du nachher lokal benutzen kannst), als Destination gibst du 127.0.0.1:3306 an und klickst auf Add. Dann gehst du wieder zurück zu Session, gibst einen Namen bei Saved Sessions ein, zum Beispiel bla und wählst save. Jetzt hast du eine vorbereitete Session die du gleich mit plink benutzen kannst.

Wenn du jetzt auf der Kommandozeile einmal plink bla probierst, wird die SSH-Verbindung aufgebaut und der Tunnel steht. Er wird dich noch nachdem Passwort fragen. Du kannst entweder beim Starten das Passwort auf der Kommandozeile angeben in Form von plink -pw passwort bla, aber das ist IMHO eine Blöde Idee(tm). Besser ist es wenn du dir ein public key-Schlüsselpaar generierst, und das an der oben beschriebenen Stelle angibst.

Dieses Kommando kannst du jetzt in PHP starten um den Tunnel aufzubauen. Wenn du popen() dafür nimmst und es auf lesen stellst, müsstest du dir die Ausgabe ansehen können, um feststellen zu können, wann die Verbindung letztendlich steht. Mit pclose() kannst du den Tunnel dann wieder schliessen.

Falls du übrigens vor der Konfiguration auf vielen Rechnern Angst hast: PuTTY schreibt seine Konfiguration in die Registry unter HKEY_CURRENT_USER\Software\SimonTatham\PuTTY\Sessions\sessionname, du kannst den ganzen Zweig mit regedit exportieren und kriegst dabei dann eine .reg-Datei die du durch Doppelklick auf beliebigen Rechnern wieder einspielen kannst.

Wobei eine SSl Lösung vermutlich die einfachere ist, vielleicht sollte ich es auch mal mit php_openssl versuchen, jedenfalls habe ich mir auch mal Deinen Vorschlag(stunnel) angesehen, wobei mir das ganz wie eine client-server Applikation aussieht, und wie ich es sehe kann ich stunnel auf dem 2. Server nicht installieren ;-)

Ja sorry, da hatte ich etwas falsch in Erinnerung, da ich dachte du könntest stunnel mit einem SSH-Server benutzen. BTW: http://www.stunnel.org/examples/mysql.html

--
Henryk Plötz
Grüße von der Ostsee

[Andreas Korthaus]

Hallo!

Du hast mir wirklich sehr geholfen! Habe jetzt gerade mit phpmyadmin auf eine externe Db Zugriff, herrliche Sache! Und das mit popen werde ich morgen einbauen. Das einzige was mir noch nicht so klar ist, wie geht das mit dem key? Wie generiere ich den? Womit? Was muß da rein?
Hätte gar nicht gedacht das ich plink auch hier verwenden kann, wirkich super!

Falls du übrigens vor der Konfiguration auf vielen Rechnern Angst hast: PuTTY schreibt seine Konfiguration in die Registry unter HKEY_CURRENT_USER\Software\SimonTatham\PuTTY\Sessions\sessionname, du kannst den ganzen Zweig mit regedit exportieren und kriegst dabei dann eine .reg-Datei die du durch Doppelklick auf beliebigen Rechnern wieder einspielen kannst.

man, man, man - nicht schlecht!

Ja sorry, da hatte ich etwas falsch in Erinnerung, da ich dachte du könntest stunnel mit einem SSH-Server benutzen. BTW: http://www.stunnel.org/examples/mysql.html

Ja, da war ich auch mit neideishcen Blicken drauf gestoßen, naja, habe das mal meinem Provider vorgeschlagen zu installieren, aber vermutlich sind die Aussichten nicht wirklich gut!

Man kann ja mit dem Kommandozeilentool "mysql" meines Wissens eine komprimierte Datenübertragung einstellen. Hast Du eine Idee wie ich das mit PHP nutzen könnte?

-C, --compress
    im Client-Server-Protokoll Komprimierung benutzen.

Dann wären alle Problem gelöst ;-) Ich glaube ich mache meine genze Kommunikation auf die Weise, denn so habe ich recht wenig Angriffspunkte und wenige Fehlerquellen. Nur die Sache mit der Komprimierung macht mir jetzt macht Sorgen... denn die Übertragung der unkomorimierten Daten hat ja bereits mit CURL bestens geklappt! Und da bei der Datenbank mal schnell größere Datenmengen zusammenkommen wäre das schon ein wichtiges Feature! HAst Du ne Idee, oder nen Ansatz wo man vielleicht mal gucken könnte?

Vielen Dank nochmal für Deine Hilfe!

Grüße
Andreas

[Henryk Plötz]

Moin,

Du hast mir wirklich sehr geholfen! Habe jetzt gerade mit phpmyadmin auf eine externe Db Zugriff, herrliche Sache! Und das mit popen werde ich morgen einbauen. Das einzige was mir noch nicht so klar ist, wie geht das mit dem key? Wie generiere ich den? Womit? Was muß da rein?

Zum Beispiel mit PuTTYgen, gibt's da wo du auch PuTTY her hast. Das startest du einfach und wählst erstmal unten einen Schlüsseltyp aus. Da SSH1 teilweise gravierende Sicherheitslücken hatte (und hat) wird dein Provider das wohl abschalten oder schon abgeschaltet haben (meiner hat schon vor einiger Zeit). Also suchst du dir eine der der SSH2-Varianten aus. Welche sollte relativ egal sein, ein 1024-Bit DSA-Schlüssel ist ok. Dann klickst du auf Generate und tust was er von dir verlangt (mit der Maus ein bisschen Spielen). Den erzeugten Schlüssel speicherst du mit Save private key auf deinen Rechner. Sei vorsichtig mit der Datei! Nach dem nächsten Schritt wird jeder diesen Schlüssel hat, Zugriff auf deinen Account auf dem Server haben. Du kannst sie im Prinzip auch mit einer Passphrase verschlüsseln, die muss dann später beim Verbinden wieder angegeben werden, was ggbf. beim automatisierten Starten Probleme bereitet. Je nach Umgebung kannst du ihn auch mit einer Passphrase schützen und anschließend Pageant benutzen, welches dich nur einmal beim Einloggen nach der Passphrase fragt. -> http://the.earth.li/~sgtatham/putty/0.52/htmldoc/Chapter8.html#8

Im oberen Bereich des Generators siehst du jetzt den öffentlichen Schlüssel. Der muss auf den Server in die Datei .ssh/authorized_keys2 unterhalb deines Heimatverzeichnisses gepackt werden, und zwar in einer einzigen Zeile!

Man kann ja mit dem Kommandozeilentool "mysql" meines Wissens eine komprimierte Datenübertragung einstellen. Hast Du eine Idee wie ich das mit PHP nutzen könnte?

Du kannst auch PuTTY (und damit plink) anweisen komprimiert zu arbeiten: Links SSH auswählen und rechts Enable compression ankreuzen. Speichern der Änderung an der Session nicht vergessen.

--
Henryk Plötz
Grüße von der Ostsee

[Andreas Korthaus]

Hallo!

Zum Beispiel mit PuTTYgen, gibt's da wo du auch PuTTY her hast. Das startest du einfach und wählst erstmal unten einen Schlüsseltyp aus. Da SSH1 teilweise gravierende Sicherheitslücken hatte (und hat) wird dein Provider das wohl abschalten oder schon abgeschaltet haben (meiner hat schon vor einiger Zeit). Also suchst du dir eine der der SSH2-Varianten aus. Welche sollte relativ egal sein, ein 1024-Bit DSA-Schlüssel ist ok. Dann klickst du auf Generate und tust was er von dir verlangt (mit der Maus ein bisschen Spielen). Den erzeugten Schlüssel speicherst du mit Save private key auf deinen Rechner. Sei vorsichtig mit der Datei! Nach dem nächsten Schritt wird jeder diesen Schlüssel hat, Zugriff auf deinen Account auf dem Server haben. Du kannst sie im Prinzip auch mit einer Passphrase verschlüsseln, die muss dann später beim Verbinden wieder angegeben werden, was ggbf. beim automatisierten Starten Probleme bereitet. Je nach Umgebung kannst du ihn auch mit einer Passphrase schützen und anschließend Pageant benutzen, welches dich nur einmal beim Einloggen nach der Passphrase fragt. -> http://the.earth.li/~sgtatham/putty/0.52/htmldoc/Chapter8.html#8

Danke Dir, werde das mal probieren! Und das akzeptieren alle SSH Sever sowas, oder?

Im oberen Bereich des Generators siehst du jetzt den öffentlichen Schlüssel. Der muss auf den Server in die Datei .ssh/authorized_keys2 unterhalb deines Heimatverzeichnisses gepackt werden, und zwar in einer einzigen Zeile!

Aha, und schon das erste Problem, ich bezweifele das ich das darf! Muß mich mal erkundigen!

Du kannst auch PuTTY (und damit plink) anweisen komprimiert zu arbeiten: Links SSH auswählen und rechts Enable compression ankreuzen.

Schreck: "Sever refused to compress", aber als ich auf SSH2 umgestellt hatte hat es funktioniert! Sehr gut! Danke Dir. Meine einzige Sorge ist jetzt noch, das es ja schon nicht ganz so praktisch ist, 100te vielleicht sogar 1000nde SQL-Afbfragen so von PHP aus quer über das Internet zu schicken, oder? OK, Insert kann ich pro Tabelle in ein Statement zusammenfassen, aber mit Update geht das nicht, jedes Update bedarf eines eigenen Requests über putty, verschlüsselt, komprimiert, quer über das Internet dort dekomprimiert, etschlüsselt, an den mySQL-Server weitergeleitet und da geparst und ausgeführt -  und das x 1000, da hört sich doch nicht wirklich vernünftig an, oder was meinst Du? Gibt es eien Möglichkeit über den Tunnel auf die Daten an ein PERL oder PHP-Script zu übertragen? SCP ist wie gesagt deaktiviert. Ginge wohl höchstens per FTP, oder? Und da mache ich das vermutlich genau so wie bei mySQL, also an 127.0.0.1:21 schicken, oder? Und dann wird es garantiert nicht über das Internet geleitet, oder? Das könnte ich ja dann von PHP ausmachen und dann mit plink ein serverseitiges Script ausführen, aber erstmal schaun wie das mit mySQL direkt läuft!.

Vielen Dank nochmal für Deine großartige Hilfe!

Viel Grüße
Andreas

[Andreas Korthaus]

Nochmal was zum Thema Geschwindigkeit:

Ich habe das testweise mit einem 30KB großen Dump versucht.

1. Über PHPmyADMIN auf dem Remote-Server, das ganze hat ca. 6 Sekunden gedauert
2. Über PHPmyADMIN auf meinem lokalen Server über den SSH-Tunnel, das ganze hat etwa 20 Sekunden gedauert(mit Herstellen der Verbindung)
3. Von einem eigenen Script über CURL (übertragen der Daten auf den Remote-Server und erst da Ausführen der SQL-Statements) ohne Komprimierung, ca. 6 Sekunden
4. genau dasselbe wie 3. nur mit Komprimierung(knapp 90%!), leider bekomme ich das ja nicht hin, aber mit vergleichbaren Daten getestet liefe das auf ca. 3 Sekunden hinaus!!!

Die Konsequenzen die ich hieraus ziehe:
1. Es ist ein erheblicher Unterschied ob ich die Statements(100) remote oder lokal ausführe(3:1)
2. Die Komprimierung die man in putty verwenden kann taugt nichts

Also werde ich mich mal weiter an der CURL-Version versuchen, das ist wie es aussieht der mit großem Abstand performanteste Weg! Schade das SSH so langsam ist, aber wenn das noch größere Datenmengen werden, und ich ja auch noch zurück übertragen muß, dann kann ich mir einfach den Zeitunterschied um einen Faktor 7 nicht wirklich erlauben!

Viele Grüße
Andreas

[Henryk Plötz]

Moin,

Danke Dir, werde das mal probieren! Und das akzeptieren alle SSH Sever sowas, oder?

Wenn der Administrator es nicht explizit abschaltet (wofür mir kein vernünftiger Grund einfällt), dann ja.

Aha, und schon das erste Problem, ich bezweifele das ich das darf! Muß mich mal erkundigen!

Wieso solltest du nicht in dein Heimatverzeichnis schreiben dürfen?

Gibt es eien Möglichkeit über den Tunnel auf die Daten an ein PERL oder PHP-Script zu übertragen?

Klar, mach einfach einen Tunnel zum Webserver auf und benutz den mit fsockopen(). Wie man HTTP zu Fuß fährt, haben wir ja schon mehrmals behandelt.

Ginge wohl höchstens per FTP, oder? Und da mache ich das vermutlich genau so wie bei mySQL, also an 127.0.0.1:21 schicken, oder?

Nein! FTP ist so ziemlich das einzige (weiter verbreitete) Protokoll dass du nicht vernünftig tunneln kannst. Es hat nämlich die unangenehme Eigenheit eine weitere Verbindung für die Daten aufzubauen und die ursprüngliche Verbindung nur für die Kontrolldaten zu verwenden. Du müsstest also mindestens einen weiteren Port tunneln und da wird's kompliziert: Der Port für die zweite Verbindung wird erst nach Aufbau der ersten Verbindung über diese ausgehandelt. Wenn du halbwegs die Kontrolle über den FTP-Clienten hast (lies: wahrscheinlich zu Fuß machen), kannst du zwar präventiv den einen oder anderen Port zusätzlich tunneln und den Clienten dazu bringen nur einen davon für die zweite Verbindung zu benutzen, aber das ist etwas umständlich und wenig sauber.

--
Henryk Plötz
Grüße von der Ostsee

[Andreas Korthaus]

Hallo!

Wenn der Administrator es nicht explizit abschaltet (wofür mir kein vernünftiger Grund einfällt), dann ja.

die haben ganz andere Probleme, obwohl Du natürlich Recht hast, dem Provider ist es wichtig das er SSH als Deature anbietet, der Rest ist erstmal uninteressant!

Aha, und schon das erste Problem, ich bezweifele das ich das darf! Muß mich mal erkundigen!

Wieso solltest du nicht in dein Heimatverzeichnis schreiben dürfen?

Hast Recht, ich kann das wohl verwenden, muß nur noch abklären wie das jetzt genau funktioniert, ist nicht ganz so einfach bei mir ;-)

Gibt es eien Möglichkeit über den Tunnel auf die Daten an ein PERL oder PHP-Script zu übertragen?

Klar, mach einfach einen Tunnel zum Webserver auf und benutz den mit fsockopen(). Wie man HTTP zu Fuß fährt, haben wir ja schon mehrmals behandelt.

Mann! Warum bin ich nicht selbst darauf gekommen? Klar! Und wenn ich das dann noch gz-Komprimiere habe ich die absolut perfekte Lösung! Zum einen sollte die Geschwindigkeit deutlich gewinnen, aber ich behalte  gegenüber cURL(SSL) die zusätzliche Sicherheit der Authentifizierung, was ich sonst auch nur hätte manuell machen können! Außerdem bietet fsockopen() doch mehr Möglichkeiten als cURL! Das einzige was es jetzt noch zu überlegen gilt, kann man binäre Daten(gz) _direkt_ an ein PHP Script schicken ohne den Umweg über eine temporäre Datei zu gehen? Vermutlich nicht, aber so schlimm ist es nicht, ich hoffe nur das ich so die cURL-Probleme umgehen kann! Aber wenn ich noch ein bisschen überlege, dann kommt ja schon langsam die PHP 4.3 raus, dann kann ich "zur Not" auch per fsockopen() SSL verschlüsselt Daten übermitteln ;-)

Ginge wohl höchstens per FTP, oder? Und da mache ich das vermutlich genau so wie bei mySQL, also an 127.0.0.1:21 schicken, oder?

Nein!

´tschuldigung ;-)

FTP ist so ziemlich das einzige (weiter verbreitete) Protokoll dass du nicht vernünftig tunneln kannst. Es hat nämlich die unangenehme Eigenheit eine weitere Verbindung für die Daten aufzubauen und die ursprüngliche Verbindung nur für die Kontrolldaten zu verwenden. Du müsstest also mindestens einen weiteren Port tunneln und da wird's kompliziert: Der Port für die zweite Verbindung wird erst nach Aufbau der ersten Verbindung über diese ausgehandelt. Wenn du halbwegs die Kontrolle über den FTP-Clienten hast (lies: wahrscheinlich zu Fuß machen), kannst du zwar präventiv den einen oder anderen Port zusätzlich tunneln und den Clienten dazu bringen nur einen davon für die zweite Verbindung zu benutzen, aber das ist etwas umständlich und wenig sauber.

Ah ja, da war was, jetzt wo Du´s sagst, hatte ich in einem anderen Zusammenhang schonmal gehört(Router/port forewarding)

Aber was ist denn mit SFTP, was da wo es putty gibt gibt? Ist das sicher? Aber eigentlich egal, ich will es wenn möglich vermeiden Dateien zu schreiben!

Viele Grüße
Andreas

[Andreas Korthaus]

nur ein kleiner Nachtrag von wegen "neues PHP", kennst Du http://snaps.php.net/? Hatte gestern eine Benachrichtigung über einen gefixten Bug bekommen und da stand der Link - in der neusten Version sei das bereits berücksichtigt. Sind die "Dinger" wohl stabil? Ich vermisse eine Angabe wie eine change.log, damit man irgendwie wissen kann was denn jetzt in welcher Version neu ist! Werd mir morgen mal die neuste runterladen uns lass mich überraschen ;-)

Grüße
Andreas

[Andreas Korthaus]

http://snaps.php.net/

Sachmal, bin ich total blöd? Das steht ja alles da, sorry ;-) Aber den Link fand ich schon recht interessant!

Grüße
Andreas

[Henryk Plötz]

Moin,

Ja, auf die Snapshots habe ich dich schonmal mit der Bemerkung über die mögliche Instabilität hingewiesen: http://forum.de.selfhtml.org/archiv/2002/9/24066/#m133293 ;-) Ein Changelog sollte sich eigentlich in jedem Archiv befinden, ggbf. als NEWS getarnt.

Was das schicken von Daten direkt an ein Skript mit PHP angeht: Du könntest auf der anderen Seite ein PHP-Skript starten, welches Server spielt und an einem Port lauscht. Dann baust du einen Tunnel vom Sendeskript zu diesem Server auf und schickst die Daten durch. Wie du mit PHP an einem Socket lauscht, steht in http://www.php.net/manual/en/function.socket-listen.php, aber das ist eigentlich Overkill.

Zu SFTP: Laut Doku (http://the.earth.li/~sgtatham/putty/0.52/htmldoc/Chapter6.html#6) geht das nur mit SSH2 (kein Problem) und wird bei dir wohl zusammen mit SCP deaktiviert worden sein. Einen Versuch ist es vielleicht wert.

--
Henryk Plötz
Grüße von der Ostsee

[Andreas Korthaus]

Hi!

Ja, auf die Snapshots habe ich dich schonmal mit der Bemerkung über die mögliche Instabilität hingewiesen: http://forum.de.selfhtml.org/archiv/2002/9/24066/#m133293 ;-) Ein Changelog sollte sich eigentlich in jedem Archiv befinden, ggbf. als NEWS getarnt.

Aha! Ich habe die Seite schon 1000 mal gesehen aber das war mir noch nicht aufgefallen, die NEWS habe ich auch bereits gelesen. Habe mir auch mal die aktuelle dev Version gezogen, ich muß sagen bei PHP 4.3 sind einige Sachen gemacht! Und wenn ich das ganze nicht total falsch verstanden habe kommt jetzt noch eine 4.2.4 und danach die 4.3! Hoffe ich wenigstens ;-)

Also sollte man auch die snaps - STABLE nicht verwenden oder?

Was das schicken von Daten direkt an ein Skript mit PHP angeht: Du könntest auf der anderen Seite ein PHP-Skript starten, welches Server spielt und an einem Port lauscht. Dann baust du einen Tunnel vom Sendeskript zu diesem Server auf und schickst die Daten durch. Wie du mit PHP an einem Socket lauscht, steht in http://www.php.net/manual/en/function.socket-listen.php, aber das ist eigentlich Overkill.

Meinst Du das Positiv oder Negativ? Für mich sind das neben OOP die mir noch nicht so behagt die beiden wichtigsten Themen die ich in Zukunft mal anpacken will, Sockets und Prozessverwaltung (hatten wir ja ein paar "Etagen" drüber mal).

Zu SFTP: Laut Doku (http://the.earth.li/~sgtatham/putty/0.52/htmldoc/Chapter6.html#6) geht das nur mit SSH2 (kein Problem) und wird bei dir wohl zusammen mit SCP deaktiviert worden sein. Einen Versuch ist es vielleicht wert.

Hm. SSH2 scheint zu gehen, SFTP habe ich noch nicht versucht, geht garantiert nicht da der Privider gerade das verhindern will, hat irgendwas mit der Abrechnung des Traffics zu tun, das wäre nicht ganz so einfach, naja, keine Ahnung.

Viele Grüße
Andreas

[Henryk Plötz]

Moin,

Also sollte man auch die snaps - STABLE nicht verwenden oder?

Keine Ahnung, ich vermute einfach mal ins Blaue hinein dass das Snapshots vom aktuellen stable-Baum (also 4.2.x) sein werden, die dir also nicht viel bringen.

Meinst Du das Positiv oder Negativ?

Wenn PHP 4.3 wirklich so bald herauskommt wie es sich bei deinen Postings liest, wäre die Implementierung dieses Ansatzes, der dir gegenüber dem Anderen (fsockopen() durch den Tunnel zum Webserver und einen Dateiupload emulieren) noch nicht mal viel bringt, meiner bescheidenen Meinung nach unnötige Komplexität.

Hm. SSH2 scheint zu gehen,

Na das hoffe ich doch. Du solltest am besten nur noch SSH2 verwenden, da SSH1 wie erwähnt unsicher ist, und zwar unabhängig von der verwendeten Software. Siehe zum Beispiel http://www.ssh.com/products/ssh/advisories/statement.cfm und verlinkte Seiten.

Noch was: Besorg dir aus einer halbwegs sicheren Quelle (Telefonanruf beim Provider etwa oder wenigstens sicher unterschriebene Mail[1]) den Fingerprint des Servers und vergleiche ihn mit dem den PuTTY beim ersten Verbindungsaufbau anzeigt. PuTTY schreibt den Schlüssel dann in die Registry (bei dem kürzlich erwähnten Schlüssel für die Sessions direkt nebenan, dort kannst du ihn auch löschen um bei der nächsten Verbindung nochmal den Fingerprint zu sehen) und du solltest ihn auf alle Rechner auf denen das noch laufen soll verteilen, per Registry-Ex- und Import etwa.

PuTTY/plink überprüfen den Schlüssel vor jeder Verbindung und verweigern einen Verbindungsaufbau bzw. Warnen wenn er sich ändert. Wenn der Schlüssel nicht wirklich sicher der vom Server ist, kannst du dir eigentlich die ganze SSH-Sache schenken.

[1] Waren Paranoikern reicht das natürlich nicht http://forum.de.selfhtml.org/archiv/2002/7/18310/#m103525 ff. ;-)

--
Henryk Plötz
Grüße von der Ostsee

[Andreas Korthaus]

Hallo!

Keine Ahnung, ich vermute einfach mal ins Blaue hinein dass das Snapshots vom aktuellen stable-Baum (also 4.2.x) sein werden, die dir also nicht viel bringen.

Ja, die hatr ein paar Kleinigkeiten gegenüber dem aktuellen Stable release geändert, ist dann die 4.2.4, die halt aber nich nicht fertig ist, also bringts mir nichts und ist nur ein unnötiges Risiko. Aber die dev-Version ist die 4.3, aber von dev lass ich lieber die Finger, das wäre dann wohl doch etwas gewagt!

Wenn PHP 4.3 wirklich so bald herauskommt wie es sich bei deinen Postings liest, wäre die Implementierung dieses Ansatzes, der dir gegenüber dem Anderen (fsockopen() durch den Tunnel zum Webserver und einen Dateiupload emulieren) noch nicht mal viel bringt, meiner bescheidenen Meinung nach unnötige Komplexität.

Ja, daher halte ich jetzt an der fsockopen-Variante fest, die verwende ich erstmal durch den Tunnel, und teste mal wie sich das mit 4.3 und SSL macht. Dann muß ich mir halt nur Gedanken über die Komprimierung machen, das sollte ich mir doch hoffentlich bei SSH2 nicht machen müssen, oder? d.h. ich könnte den ganzen String auch urlencoded als POST Daten schicken, vermutlich ohne merkbare Nachteile.

Bei SSH habe ich nur Angst das es zu langsam ist, wobei SSL auch nicht gerae für seine Schnelligkeit bekannt ist ;-) Werd das mal vergleichen, wenn ich es denn doch irgendwann mal hinbekommen sollte ;-)

zur Zeit kämpfe ich mit meinem ersten POST-Header mit multipart/dorm-data: </?m=137499&t=25037>
Mal schaun wie es ausgeht!

Viele Grüße
Andreas

PS: ich hab das mal oben gepostet da die Vorgeschichte dafür eher unerheblich ist - denke ich.

[Henryk Plötz]

Moin,

hast du den Handler aber schon auch auf binary gesetzt, oder? - Ich habe nämlich in dem gzwurm einige 0a0d's gesehen => riecht nach win, obwohl dort nur vielleicht ein 0d stehen sollte...

Die 0a0d sind die korrekten Zeilenenden von HTTP-Zeilen. Innerhalb des Binärdatenblocks wurden soweit ich sehen kann, keine Zeilenenden kovertiert (zumindest beim Senden durch cURL) und das ist die richte Vorgehensweise.

binmode(HANDLE)!

Error, perl code detected! In php macht man das indem man ein b an den Modus-String beim Öffnen anhängt. Andreas: Ergänze mal das "w" von popen() um ein b.

vermutlich passiert da unterwegs irgendwas unvorhergesehenes, kann ja auch ein bug in der Windowsversion von Curl oder PHP oder auch Windows2000 selbst sein,

Ich kann mir hier eben sehr gut vorstellen, dass die \015 durch \015\012 übersetzt werden...

Wie gesagt, im funktionierenden Dump tauchen 0D und 0A alleine auf, im nichtfunktionierenden immerhin ein einzelnes 0A. Wobei mir auffällt: Der nicht funktionierende sendet ja nicht mal alles, da bricht meine schöne Theorie, dass der Apache vielleicht beim Empfangen von text/plain ein bisschen konvertiert zusammen.

Vielleicht sollte ich --data-binary versuchen?

das klingt schon mal gut.

NACK. --data ist für Daten vom Typ urlencoded, -binary sorgt bloss dafür, dass er nicht alle Zeilenumbrüche wegschneidet.

Muss doch auch nicht... Die POST-Daten kannst du ja dann über STDIN einlesen (php?); achung: auch hier wieder zuerst binmode(STDIN). Und dann den eingelesenen String an gz übergeben.

Weder noch. --form emuliert einen Dateiupload so dass das PHP-Skript die hochgeladene Datei als temporäre Datei vorgesetzt kriegt, --data emuliert normale Formularfelder, so dass das PHP-Skript die Daten in Variablen vorgesetzt kriegt. An die reinen POST-Daten kommst du in PHP (leider) nicht mehr ran, so dass sich das Einlesen zu Fuß erübrigt.

Aber das mit dem b im Modestring klingt wie eine gute Idee (auch wenn seine notwendigkeit nach einem Designfehler im OS stinkt), am besten gibst du das auch in den String der die temporäre Datei öffnet.

--
Henryk Plötz
Grüße von der Ostsee

[Philipp Hasenfratz]

Halihallo Henryk

hast du den Handler aber schon auch auf binary gesetzt, oder? - Ich habe nämlich in dem gzwurm einige 0a0d's gesehen => riecht nach win, obwohl dort nur vielleicht ein 0d stehen sollte...

Die 0a0d sind die korrekten Zeilenenden von HTTP-Zeilen.

die meinte ich auch nicht. Ich bezog mich auf eventuelle 0a0d's im GZ-Stream.

Innerhalb des Binärdatenblocks wurden soweit ich sehen kann, keine Zeilenenden kovertiert (zumindest beim Senden durch cURL) und das ist die richte Vorgehensweise.

binmode(HANDLE)!

Error, perl code detected! In php macht man das indem man ein b an den Modus-String beim Öffnen anhängt. Andreas: Ergänze mal das "w" von popen() um ein b.

Das ist kein Error, sondern ein "warning" :-)
Mir kam halt grad das binmode in den Sinn; wenn das ein Error ist, entschuldige ich mich :-)

vermutlich passiert da unterwegs irgendwas unvorhergesehenes, kann ja auch ein bug in der Windowsversion von Curl oder PHP oder auch Windows2000 selbst sein,

Ich kann mir hier eben sehr gut vorstellen, dass die \015 durch \015\012 übersetzt werden...

Wie gesagt, im funktionierenden Dump tauchen 0D und 0A alleine auf, im nichtfunktionierenden immerhin ein einzelnes 0A.

Uha, na, dann fällt meine Theorie ins Wasser *seufz*... Naja, sicherer ist es _besonders_ bei binären Dateien... Und vielleicht war der Dump auch noch nicht alles, bzw. es könnte dann bei grösseren Daten dieser Fehler (win:what-ever Kodierung) auftauchen...

Muss doch auch nicht... Die POST-Daten kannst du ja dann über STDIN einlesen (php?); achung: auch hier wieder zuerst binmode(STDIN). Und dann den eingelesenen String an gz übergeben.

Weder noch. --form emuliert einen Dateiupload so dass das PHP-Skript die hochgeladene Datei als temporäre Datei vorgesetzt kriegt, --data emuliert normale Formularfelder, so dass das PHP-Skript die Daten in Variablen vorgesetzt kriegt. An die reinen POST-Daten kommst du in PHP (leider) nicht mehr ran, so dass sich das Einlesen zu Fuß erübrigt.

Ich mach mal ein Feature-Request für die Zend Engine 3 :-)

Viele Grüsse

Philipp

[Björn Höhrmann]

Das dumme an der Sache, gzip komprimiert wirklich bemerkenswert, fast 90%. Aber durch urlencode, damit ich das als POST-Daten übertragen kann, muß das ganze noch durch urlencode, dadurch wird der String wieder 3 mal so groß, also nichtmal mehr 70% Komprimierung.

Wozu urlencode()? Wie schon gesagt, du kannst dir selber aussuchen, was du für Daten über die Leitung schiebst, die müssen nicht gesondert kodiert werden, wichtig ist nur, dass die beiden Anwendungen sich über die Interpretation der Daten einig sind und die Header stimmen.

[Andreas Korthaus]

Hi!

Wozu urlencode()? Wie schon gesagt, du kannst dir selber aussuchen, was du für Daten über die Leitung schiebst, die müssen nicht gesondert kodiert werden, wichtig ist nur, dass die beiden Anwendungen sich über die Interpretation der Daten einig sind und die Header stimmen.

Ja, aber dann sag mir mal wie Du das mit SSL machst. Wie übertrage ich per HTTP und SSL verschlüsselt Daten an den Server? Der einzige Weg den ich gefunden habe ist das Kommandozeilen-Tool CURL zu verwenden, wo ich die besagten Daten über eine POST Variable übertrage. Da das ganze urlencoded sein muss, habe ich keine andere Wahl. Es gibt wohl eine Möglichkeit binäre Daten zu übertragen, nur will das noch nicht funktionieren. Und auch das als "Formular-Uploaddaten" und nicht anders.

Das Problem ist nicht, das ich keine Individuelle Kommunikation über sockets möchte, leider bietet PHP von Haus aus keine Unterstützung von Socketverbindungen über SSL, also muß ich mir behelfen und das ist bis jetzt die einzige Möglichkeit die ich realisiern kann!

Viele Grüße
Andreas

[Björn Höhrmann]

Wozu urlencode()? Wie schon gesagt, du kannst dir selber aussuchen, was du für Daten über die Leitung schiebst, die müssen nicht gesondert kodiert werden, wichtig ist nur, dass die beiden Anwendungen sich über die Interpretation der Daten einig sind und die Header stimmen.

Ja, aber dann sag mir mal wie Du das mit SSL machst. Wie übertrage ich per HTTP und SSL verschlüsselt Daten an den Server?

Das kommt drauf an, welche Möglichkeiten dir zur Verfügung stehen. Würdest du Perl verwenden, gäbe es sicherlich kein Problem, Libwww-Perl unterstützt SSL so die entsprechenden Module installiert sind.

Der einzige Weg den ich gefunden habe ist das Kommandozeilen-Tool CURL zu verwenden, wo ich die besagten Daten über eine POST Variable übertrage. Da das ganze urlencoded sein muss,

Verlangt CURL das?

habe ich keine andere Wahl. Es gibt wohl eine Möglichkeit binäre Daten zu übertragen, nur will das noch nicht funktionieren.

Vielleicht solltest du lieber da ansetzen?

Und auch das als "Formular-Uploaddaten" und nicht anders.

Was sind "Formular-Uploaddaten"?

Das Problem ist nicht, das ich keine Individuelle Kommunikation über sockets möchte, leider bietet PHP von Haus aus keine Unterstützung von Socketverbindungen über SSL, also muß ich mir behelfen und das ist bis jetzt die einzige Möglichkeit die ich realisiern kann!

Für PHP gibt es (neben einer CURL-Erweiterung) auch eine OpenSSL-Erweiterung die genau das ermöglicht. Die Erweiterung ist soweit ich weiss derzeit experimentell, aber das sollte dich nicht aufhalten, wenn du PHP einsetzen willst.

[Andreas Korthaus]

Hi!

Ja, aber dann sag mir mal wie Du das mit SSL machst. Wie übertrage ich per HTTP und SSL verschlüsselt Daten an den Server?

Das kommt drauf an, welche Möglichkeiten dir zur Verfügung stehen. Würdest du Perl verwenden, gäbe es sicherlich kein Problem, Libwww-Perl unterstützt SSL so die entsprechenden Module installiert sind.

Ja, aber ich kann so schlecht PERL!

Der einzige Weg den ich gefunden habe ist das Kommandozeilen-Tool CURL zu verwenden, wo ich die besagten Daten über eine POST Variable übertrage. Da das ganze urlencoded sein muss,

Verlangt CURL das?

Ja, wenn man es als normale POST-Variable wie bei HTML-Formularen überträgt. CURL ist glaube ich dafür gebaut einen Browser serverseitig zu emulieren, also vielleicht nichtganz so optimal, aber bisher die einzige Möglichkeit die Daten verschlüsselt zu übertragen! Aber ich hatte gerade noch eine Idee, per X11 Forewarding(SSH), mal schauen, so könnte ich evtl doch direkt eine verschlüsselte Vebindung zur anderen DB aufbauen, und soweit ich weiß kann man das dann auch automatisch komprimiert übertragen, mal gucken, habe es schonmal probiertund nicht hinbekommen.

habe ich keine andere Wahl. Es gibt wohl eine Möglichkeit binäre Daten zu übertragen, nur will das noch nicht funktionieren.

Vielleicht solltest du lieber da ansetzen?

Ja, sieh Hentyk´s Postings, es scheint zu gehen, aber wie ich geschreiben habe - bei mir zumindest - nur mit begrenzter String-Länge, was ich überhaupt nicht verstehen kann! Vor allem da es so geringe Mengen sind!

Und auch das als "Formular-Uploaddaten" und nicht anders.

Was sind "Formular-Uploaddaten"?

Also ich meine ein HTML-Upload Formular, welches eine Datei mit multipart/form-data überträgt

Für PHP gibt es (neben einer CURL-Erweiterung) auch eine OpenSSL-Erweiterung die genau das ermöglicht. Die Erweiterung ist soweit ich weiss derzeit experimentell, aber das sollte dich nicht aufhalten, wenn du PHP einsetzen willst.

Aber ich habe keine Ahnung von SSL selbst! Weiß denn jemand von PHP 4.3  rauskommt? Denn da ist eine Socketverbindung über fsockopen() auch mit SSL möglich:

As of PHP 4.3.0, if you have compiled in OpenSSL support, you may prefix the hostname with either 'ssl://' or 'tls://' to use an SSL or TLS client connection over TCP/IP to connect to the remote host.

Vom CVS lass ich lieber meine Finger! Habe schon genügend Probleme mit PHP4/Apache2/Mysql4, vor allem phpmyadmin dreht total am Rad, die mit foxserv mitgelieferte Version war schlichtweg nicht zu gebrauchen, die neue geht schon besser, aber immer noch problematisch!

Viele Grüße
Andreas

[Michael Schröpl]

Hi Andreas,

zunächst mal: Danke für diesen schönen Thread!
Ich wünschte mir, dieses Forum bekäme jeden Tag so etwas Spannendes zu lesen.

Zur Lösung kann ich wohl nicht viel beitragen.
Auch ich vermute das Problem im Bereich "binmode" auf der Curl-Seite - ich hatte bei der Entwicklung von gzip_cnc recht ähnliche Probleme (in die andere Richtung allerdings).

Was die URL-Codierung angeht - das Thema ist ja wohl vom Tisch, wenn via POST übertragen wird.
Deshalb nur als Anmerkung: Ich hatte mal die Aufgabe, eine Komprimierung zu schreiben, die steuerzeichensicher über X.25-Leitungen verwendet werden konnte, und wir haben uns damals (angesichts vorliegender Kenntnisse über die zu komprimierenden Daten) dafür entschieden, etwas Eigenes, ziemlich Primitives in C zu schreiben (zumal das Teil möglichst einfach und portabel sein sollte).

Viel Erfolg bei der weiteren Suche
     Michael

P.S.: Danke auch an Henryk für den Tip mit putty 0.52.

[Andreas Korthaus]

Hi Michael!

zunächst mal: Danke für diesen schönen Thread!

ich habe allen Antwortenden zu danken, ich glaube ich habe noch nie so viel in einem Thread gelernt ;-)

Auch ich vermute das Problem im Bereich "binmode" auf der Curl-Seite - ich hatte bei der Entwicklung von gzip_cnc recht ähnliche Probleme (in die andere Richtung allerdings).

Ja, aber ich verstehe es einfach nicht. Ich will auch das das ganze nicht um sonst war, daher were ich gleich nochmal ne Testserie starten und mit den HTTP-Traffic genau ansehen (auch hier Danke für den Tipp!) , und mir alles mögliche ausgeben lassen, das _muss_ doch irgendwie gehen! Denn es funktioniert ja bei bestimmten Strings! Es funktioniert nicht bei ganz kurzen wie "hallo" und nicht bei ganz langen. Es ist mir ein absolutes Rätsel!

Was die URL-Codierung angeht - das Thema ist ja wohl vom Tisch, wenn via POST übertragen wird.

Wieso? Ich habe immer über POST übertragen einmal multipart und einmal urlencoded, bei multipart kommen diese komischen Probleme, bei urlencode habe ich andere Probleme, da werden die Daten alle von CURL richtig losgeschickt(im http-Traffic steht alles noch richtig), aber auf dem Server habe ich in den Umgebungsvariablen(in PHP) nicht mehr dasselbe stehen, wie ich einst losgeschickt habe! Es sind ja binärdaten(gz), die der Apache wenn er urldecodet "zu sehen" bekommt, und ich vermute der Apache sieht darin irgendwelche Zeilenumrüche und wandelt dann irgndwas um. Ich habe den String der in der Umgebungsvariable des Servers(wieder aus PHP) steht mal erneut urlencodet(in PHP), und mit dem losgeschickten String verglichen, da gibt es Unterschiede, siehe: </?m=136434&t=24834>
Naja, aber leider kenne ich mich zu wenig aus um sagen zu können was da jetzt genau los ist.

Deshalb nur als Anmerkung: Ich hatte mal die Aufgabe, eine Komprimierung zu schreiben, die steuerzeichensicher über X.25-Leitungen verwendet werden konnte, und wir haben uns damals (angesichts vorliegender Kenntnisse über die zu komprimierenden Daten) dafür entschieden, etwas Eigenes, ziemlich Primitives in C zu schreiben (zumal das Teil möglichst einfach und portabel sein sollte).

Ja, abr wenn ich doch den gesamten String urlcodiere dürfte es ja keine Probleme geben, da keine Steuerzeichen mehr vorkommen. Aber wenn Apache den String empfängt dekodiert er ihn wieder automatisch, und dann gibt es Probleme mit irgendwelchen Zeichen vermute ich, den Schluss den ich daraus ziehe ist entwerder ich kodiere das doppelt, also 2 mal übereinander, dann kann ich den Binärstring erst in PHP wieder dekodieren, aber dann sind von 90% Komprimierung mit viel Glück noch 50% übrig! Und daher fällt die Methode einen Binärstring als urlencodet POST-Request zu schicken wohl flach. Bleibt mir nur nach die andere Variante mit multipart..., aber da treten ja die ganz sonderbaren Probelem auf. Naja, ich werde testen und Euch berichten ;-)
Vermutlich ist es ein Windows-Problem, an irgendeiner Schnittstelle gibt es Probleme. Der Quellcode von mir sollte eigntlich richtig sein, der Stimmt auch genau mit dem Beispiel von Henryk überein. Aber die meisten Programme die ich verwende wurden nunmal primär für Unix entwickelt, vermutlich liegt da das Problem!

Aber man wird sehen!

Viele Grüße
Andreas

[Michael Schröpl]

Hi Andreas,

Was die URL-Codierung angeht - das Thema ist ja
wohl vom Tisch, wenn via POST übertragen wird.
Wieso? Ich habe immer über POST übertragen ...

weil URLencode mit Faktor 3 für den ganzen Block einfach zu teuer ist.

Da kannst Du dann wirklich selbst etwas schreiben, was einfach nur Steuerzeichen ausblendet. Nimm Dir BASE64 als Beispiel:
     http://www.freesoft.org/CIE/RFC/1521/7.htm

Viele Grüße
      Michael

[Andreas Korthaus]

Hi!

weil URLencode mit Faktor 3 für den ganzen Block einfach zu teuer ist.

Da kannst Du dann wirklich selbst etwas schreiben, was einfach nur Steuerzeichen ausblendet. Nimm Dir BASE64 als Beispiel:
     http://www.freesoft.org/CIE/RFC/1521/7.htm

Ok, das hätte vielleicht den Faktor 1,5 oder? Aber brauch man das? Wenn ich den gz-String zwischen den boundary-Strings als multipart/form-data übertrage habe ich zumindest in PHP keine Probleme, wobei ich zur Zeit hier an keine vernünftige Verschlüsselung komme. Vielleicht läuft es am Ende doch noch auf eine eigene GPG-Verschlüsselung hinaus, ich hoffe aber dass ich entweder SSL oder SSH noch hinbekomme!

Viele Grüße
Andreas