Serialize Objects for HTTP
hotti
- meinung
0 Der Martin0 hotti0 Der Martin0 hotti
hi,
es geht um mein CMS und ich kann mich einfach nicht entscheiden, ob ich meine URL-Objekte im QUERY_STRING serialisiert zum Server bringe oder die Attribute in den Request(Custom)Header einbaue.
Ein URL-Objekt ist sowas:
$uo = "foo=bar&url=".uri_escape("/index.html")."&title=".uri_escape("Startseite der Domäne")."&descr=".uri_escape("Programmieren mit Perl, Kochen, Maya und Tunguska")."&time=".time;
wobei der Content extra geht (alles per POST). Es gäbe noch eine Variante, die wäre form-data, aber die mag ich nicht, weil ich Content-Length: 0 erlaube beim POST (bei form-data ist Content-Length immer > 0).
Evntl. kann mir mal jemand die Vor- und Nachteile aufzeigen zwischen einer Übertragung im QUERY_STRING oder HTTP_Header. Meine Entscheidung fällt insofern schwer als das ich für beide Varianten schon die Funktionen habe und die tun einwandfrei (zu gut).
Bitte maln Hinweis,
Horst Kralle
Hallo,
es geht um mein CMS und ich kann mich einfach nicht entscheiden, ob ich meine URL-Objekte im QUERY_STRING serialisiert zum Server bringe oder die Attribute in den Request(Custom)Header einbaue.
[...]
Evntl. kann mir mal jemand die Vor- und Nachteile aufzeigen zwischen einer Übertragung im QUERY_STRING oder HTTP_Header.
für mich ist der Fall klar: Custom HTTP Headers sind keine Option. Denn dazu brauche ich einen speziellen UA; ein 08/15-Browser tut's nicht. Außer natürlich, du wolltest dein komplettes CMS ausschließlich auf AJAX aufbauen, deine Requests selbst bauen, und dich so von Javascript und den Eigenheiten des nutzerseitig verwendeten Browsers (und seiner Konfiguration) abhängig machen. Auch keine gute Idee.
So long,
Martin
hi,
für mich ist der Fall klar: Custom HTTP Headers sind keine Option. Denn dazu brauche ich einen speziellen UA; ein 08/15-Browser tut's nicht. Außer natürlich, du wolltest dein komplettes CMS ausschließlich auf AJAX aufbauen, deine Requests selbst bauen, und dich so von Javascript und den Eigenheiten des nutzerseitig verwendeten Browsers (und seiner Konfiguration) abhängig machen. Auch keine gute Idee.
Mein CMS basiert nicht auf Ajax und auch nicht auf einem Browser. Der UA, den ich dazu gebaut habe, ist eine nur wenige Zeilen umfassende Funktion, eine Methode des Lokal erstellten URL-Objekts zum Filetransfer.
Bisher habe ich diesen UA mit dem Perl-Modul LWP::UA gebaut, bin jedoch am Überlegen, den Code total abzuspecken und das Basismodul auf IO::Socket runterzuschreiben. Bevor ich damit anfange, wollte ich mal fragen... naja, zumindest ist auf dem Server das Script schon für "Beides" vorbereitet ;-)
Viele Grüße,
Horst Haselhuhn
n'Abend!
für mich ist der Fall klar: Custom HTTP Headers sind keine Option. Denn dazu brauche ich einen speziellen UA; ein 08/15-Browser tut's nicht. Außer natürlich, du wolltest dein komplettes CMS ausschließlich auf AJAX aufbauen, deine Requests selbst bauen, und dich so von Javascript und den Eigenheiten des nutzerseitig verwendeten Browsers (und seiner Konfiguration) abhängig machen.
Mein CMS basiert nicht auf Ajax und auch nicht auf einem Browser. Der UA, den ich dazu gebaut habe, ist eine nur wenige Zeilen umfassende Funktion, eine Methode des Lokal erstellten URL-Objekts zum Filetransfer.
Das ist eine wichtige Randinformation, die eigentlich ins Eröffnungsposting gehört hätte. Wann wolltest du uns das verraten? - Dann bin ich aus dem Thread raus, weil ich nicht ahnen kann, was du für deinen eigenen Bedarf zusammenperlst.
So long,
Martin
moin,
Mein CMS basiert nicht auf Ajax und auch nicht auf einem Browser. Der UA, den ich dazu gebaut habe, ist eine nur wenige Zeilen umfassende Funktion, eine Methode des Lokal erstellten URL-Objekts zum Filetransfer.
Das ist eine wichtige Randinformation, die eigentlich ins Eröffnungsposting gehört hätte. Wann wolltest du uns das verraten? - Dann bin ich aus dem Thread raus, weil ich nicht ahnen kann, was du für deinen eigenen Bedarf zusammenperlst.
Scheinbar denken viele beim Begriff CMS, dass zum Managen von Content ein gewöhnlicher Browser benutzt wird. Das mag für die große Masse an CMSsn zutreffen aber nicht für meine Eigenentwicklung, hätte ich schreiben sollen, ja ;-)
Hotti