2011-03-21T13:30:21 murphy

2011-03-21T09:00:16 rosti

[...]
Meine Client-Server-Anwendung, an der ich schon länger schreibe, erfordert es, dass kein TE (chunked) stattfindet.
[...]

Aus purer Neugier wüsste ich ja gerne, warum Deine Anwendung das eigentlich erfordert.

Meine naive Vorstellung ist, dass es der Anwendung doch reichlich egal sein könnte, wie das Übertragungsformat aussah, solange sich die HTTP-Bibliothek korrekt um diese Protokolldetails kümmert und einen Datenblock abliefert, der weiterverarbeitet werden kann.

Hi,

da muss ich mal ein bischen weiter ausholen, evntl. ist das auch von allg. Interesse.

In meiner Client-Server-Anwendung, die im Wesentlichen aus UserAgent und serverseitigen Script besteht, geht es um die Übertragung binärer Strukturen, kurz Binaries, vom Webserver zum UA und umgekehrt. Die Binaries können alles Mögliche sein, MP3s, proprietäre DB-Dumps, Multipart-Messages (as bin), Dateien, Binärsequenzen oder auch Text, was auch immer. Übertragen werden Rohdaten, Bytes, unabhängig von Inhalten und auch unabhängig von jedwelchen Zeichenkodierungen.

Da Binärsequenzen aus einem Handle gelesen werden (Strings sind dafür ungeeignet), ist es wichtig, einmal serverseitig STDIN frei zu haben von irgendwelchen Parametern. Das serverseitige Script liest die Bin bytegenau aus STDIN und bekommt per Custom-HTTP-Header mitgeteilt, was es damit machen soll.

Anererseits, in der Übertragung vom Server zum UA, wird die Binary aus einem Socket gelesen, nachdem der Request rausgegangen ist. Von daher muss die Response 'am Stück' kommen, damit bytegenau gelesen werden kann.

Mit TE: chunked würde das nicht funktionieren, ebensowenig mit gzip o.a. Compess'Dings. Sofern es nur um text/html geht, ist chunking ok, der Browser setzt den Inhalt als String zusammen und gut. Ein gewöhnlicher Browser setzt aus TE: chunked auch ein image/gif wieder zusammen, aber er wird es als String behandeln, behaupte ich mal *g (was evntl. zu prüfen wäre).

Wenn ich darf, stelle ich mein Net::HTTP10 heute abend mal ein und stelle mich gerne weiterer Diskussionen. Es ist schon möglich, dass es sich hierbei um eine Spezialanwendung handelt, jedoch, ich habe mir das in den Kopf gesetzt, es so zu machen.

Anwendungsbeispiele: Serverseitiger Tabellendump, die Records werden über eine pack()-Schablone gejagt und alles zusammen über HTTP übertragen. Ein spezieller UA entpackt die Records, schreibt die Daten in Dateien oder in die lokale DB.

Mein CMS (für meine HP) bekommt Einzelseiten auch als binär serialisierte Objekte und baut die an der entsprechenden Stelle ein.

Edit: Einher geht das mit eigenen Algorithmen für Serialze, Deserialize

Viele Grüße an alle,
Rolf

Noch ein Edit: Weiter oben habe ich Mist verzählt.
Transfer-Encoding ist natürlich ein Response Header und nicht im Request.

Es gibt einen Request-Header (HTTP/1.0 und 1.1)
Accept-Encoding: gzip,deflate

Worauf der Webserver möglicherweise mit dem Header
Content-Encoding: gzip

antwortet und den Content gezippt ausliefert (falls der Server das unterstützt).



Last edited: 2011-03-21 18:32:32 +0100 (CET)