hotti: Serialize Objects for HTTP

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

  1. 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

    --
    Lieber Blödeleien als blöde Laien.
    1. 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

      --
      Wenn der Kommentar nicht zum Code passt, kann auch der Code falsch sein.
      1. 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

        --
        Dieser Satz wurde in mühsamer Kleinstarbeit aus einzelnen Wörtern zusammengesetzt.
          (Hopsel)
        1. 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

          --
          Ammonite sind Sicherheitstreibstoffe, die keine schlagende Wetter auslösen.