Heinzelhund: Separieren von GET-Übergaben mit Semikolon

Hallo Allesamt,

bin gerade auf die Empfehlung des W3Cs gestoßen, man solle Variablen bei der GET-Übergabe mittels einem Semikolon und nicht mehr mittels einem kaufmännischen Und trennen, also:
& => ;

Da es mir in PHP etwas mehr Arbeit machen würde, hätte ich gerne mal eure Meinung dazu gehört. Ist dies sinnvoll oder wiedereinmal eine Empfehlung, die irgendwann einmal im Nirvana verschwinden wird? Muss ich vielleicht irgenwo mit Problemen rechnen?

http://www.w3.org/TR/html4/appendix/notes.html#h-B.2.2

Ciao
Heinzelhund

  1. Hello out there!

    Da es mir in PHP etwas mehr Arbeit machen würde,

    ??

    [dedlfix 2005, dedlfix 2006, wahsaga 2006, Willi 2007]

    See ya up the road,
    Gunnar

    --
    „Wer Gründe anhört, kommt in Gefahr nachzugeben.“ (Goethe)
    1. Hello out there!

      Da es mir in PHP etwas mehr Arbeit machen würde,

      ??

      See ya up the road,
      Gunnar

      Ich hab verschiedene Klassen geschrieben, die automatisch Links mit GET-Übergaben generieren. Zudem komme ich nicht überall an die php-Ini-Dateien der Server rann, in denen man die automatische Behandlung der GET-Variablen durch PHP einstellen kann. Ich müsste also auch überall mit ini_set() arbeiten.

      Um deiner Neugierde Genüge zu tun. ;-)

      Ciao
      Heinzelhund

      1. hi,

        Ich hab verschiedene Klassen geschrieben, die automatisch Links mit GET-Übergaben generieren.

        http_build_query nimmt einen arg_separator als Argument; ohne diesen würde es auch arg_separator.output verwenden.

        Zudem komme ich nicht überall an die php-Ini-Dateien der Server rann, in denen man die automatische Behandlung der GET-Variablen durch PHP einstellen kann. Ich müsste also auch überall mit ini_set() arbeiten.

        Für arg_separator.input bist du mit ini_set zu spät dran.

        gruß,
        wahsaga

        --
        /voodoo.css:
        #GeorgeWBush { position:absolute; bottom:-6ft; }
        1. Hallo wahsaga,

          http_build_query nimmt einen arg_separator als Argument; ohne diesen würde es auch arg_separator.output verwenden.

          Ich verwende http_build_query nicht, sondern baue die GET "per Hand", da - zumindest wüsste ich nicht wie - http_build_query nicht mit mehrdimensionalen Arrays klar kommt, welche für die Verarbeitung automatisch generierter Formulare überaus hilfreich sind.

          Aber es ist natürlich auch ein Leichtes dem Konstruktor meiner Klasse einen Parameter mitzugeben, der zwischen & und ; wählen kann.
          Ich sagte ja auch, dass es mir nur _etwas_ mehr Arbeit machen würde. :-)
          Generell stellt sich mir halt die Frage, ob es überhaupt sinnvoll ist.

          Ciao
          Heinzelhund

    2. Hallo Gunnar,

      ich bin's noch mal. Erst mal Dank für die verschiedenen Links, deren Threads ich mir nun zu Gemüte geführt habe. Ich hätte jedoch noch eine Frage, die mir, so scheints, nicht beantwortet wurde. Wie kriege ich nun einem HTML-Formular, dass mit GET seine Daten verschicken soll, beigebracht, dass es auch ein Semikolon verwenden soll? Sorry, falls ich es bereits überlesen haben sollte.

      Ich habe gerade versuchsweise im Firefox 2.0 ein Formular versendet und mir den HTTP-Header angeschaut. Dort wird fröhlich und lustig das & verwendet.

      Ciao
      Heinzelhund

      1. Hallo,

        Wie kriege ich nun einem HTML-Formular, dass mit GET seine Daten verschicken soll, beigebracht, dass es auch ein Semikolon verwenden soll?

        Gar nicht, das geht nicht.

        Mathias

        1. Wie kriege ich nun einem HTML-Formular, dass mit GET seine Daten verschicken soll, beigebracht, dass es auch ein Semikolon verwenden soll?

          Gar nicht, das geht nicht.

          Das ist theoretisch falsch.

          Mit JavaScript geht das. Man fügt im <form> ein  onsubmit ein kein onclick im submit-Button, wegen Entertaste.

          Beispiel:

            
          <head>  
          <script type="javascript">  
          
          
            
          function send()  
          {  
           location.href = "index.php?textbox:" + document.formular.textbox.value + ";submit=" + document.formular.submit.value";  
          }  
          
          
            
          </script>  
          </head>  
          <body>  
          <form name="formular" method="get" action="" onsubmit="send();return false;">  
            
          <input name="textbox" value="" type="text">  
            
          <input name="submit" type="submit" value="Hier klicken!">  
            
          </form>  
          </body>  
          
          

          Selbstverständlich ist dieser Code nur für JavaScript fähige und eingeschaltete Browser das ist natürlich der Riesengrosse Nachteil :(

          die grossmutter grüßt euch

          1. Hallo grossmutter,

            auch wenn ich der Verwendung von JS keineswegs abgeneigt bin und JS sehr nützliche Unterstützungen für einen User gerade beim Ausfüllen eines Formulars bieten kann, würde ich auf eine Funktion, die das bloße Übermitteln der eingegebenen Daten im Falle der Nichtaktivierung von JS beeinträchtigen kann, eher verzichten.

            Akademisch Betrachtet haste sicherlich recht. ;-)

            Ciao
            Heinzelhund

            1. Hallo grossmutter,

              auch wenn ich der Verwendung von JS keineswegs abgeneigt bin und JS sehr nützliche Unterstützungen für einen User gerade beim Ausfüllen eines Formulars bieten kann, würde ich auf eine Funktion, die das bloße Übermitteln der eingegebenen Daten im Falle der Nichtaktivierung von JS beeinträchtigen kann, eher verzichten.

              Akademisch Betrachtet haste sicherlich recht. ;-)

              Nunja sagen wir mal so: Mein Beispiel funktioniert auch wenn JavaScript nicht verarbeitet wird, nur dann wird eben das Formular mit der alten Methode '&' verschickt. Das wiederum wäre dann auch ein Erkennungszeichen dafür ob der User JavaScript hat oder nicht. Wenn er es nämlich nicht hat könnte man beim nächsten mal jegliches JavaScript weglassen. Das ist vorallem hilfreich wenn man viel JavaScript verwendet. Man müsste nur immer einen kleinen Testteil drinnen lassen der prüft ob der User vielleicht für diese Seite JavaScript mittlerweile aktiviert hat. Das wiederum ist auch nicht leicht aber doch möglich.

              eure grossmutter

      2. echo $begrüßung;

        Wie kriege ich nun einem HTML-Formular, dass mit GET seine Daten verschicken soll, beigebracht, dass es auch ein Semikolon verwenden soll?

        Da ist es nicht notwendig, das & gegen etwas anderes zu tauschen, weil zu dem Zeitpunkt kein HTML-Kontext vorliegt, in dem das & ja eine Sonderbedeutung hat.

        echo "$verabschiedung $name";

        1. echo $begrüßung;

          Wie kriege ich nun einem HTML-Formular, dass mit GET seine Daten verschicken soll, beigebracht, dass es auch ein Semikolon verwenden soll?

          Da ist es nicht notwendig, das & gegen etwas anderes zu tauschen, weil zu dem Zeitpunkt kein HTML-Kontext vorliegt, in dem das & ja eine Sonderbedeutung hat.

          echo "$verabschiedung $name";

          Wohl wahr, aber ich will in meinen Scripten ja nun nicht unentwegt zwischen ; und & bei der Auswertung hin und her springen.

          Nimm bspw. eine Suchanfrage, die über ein Formular verschickt wird und über einen Link die GET-Variablen an die 2. Seite weitergeben soll.

          Ciao
          Heinzelhund

          1. echo $begrüßung;

            Wohl wahr, aber ich will in meinen Scripten ja nun nicht unentwegt zwischen ; und & bei der Auswertung hin und her springen.
            Nimm bspw. eine Suchanfrage, die über ein Formular verschickt wird und über einen Link die GET-Variablen an die 2. Seite weitergeben soll.

            Ja, ein arg_separator.input=";&" kümmert sich um beide Varianten gleichermaßen. Wenn du unbedingt vorhandenes Verhalten nachbilden willst, und auch nicht parse_str() verwenden willst, was spricht dann dagegen, beide Zeichen gleichberechtigt in deine Trennroutine aufzunehmen?

            echo "$verabschiedung $name";

            1. Hallo,

              Ja, ein arg_separator.input=";&" kümmert sich um beide Varianten gleichermaßen. Wenn du unbedingt vorhandenes Verhalten nachbilden willst, und auch nicht parse_str() verwenden willst, was spricht dann dagegen, beide Zeichen gleichberechtigt in deine Trennroutine aufzunehmen?

              An sich erst einmal nichts, außer dass ich dann darauf achten müsste, dass ggf. beide Zeichen - falls als Wert gewünscht - maskiert werden müssten.

              Ciao
              Heinzelhund

  2. Hallo,

    bin gerade auf die Empfehlung des W3Cs gestoßen, man solle Variablen bei der GET-Übergabe mittels einem Semikolon und nicht mehr mittels einem kaufmännischen Und trennen, also ...

    Ich bin da skeptisch. In der URI-Syntax tauchen das Semikolon (und die Geschwister Gleichheitszeichen und Komma) nur in einem Nebenabsatz auf, wirklich empfohlen werden die nicht. Und sie dienen zur Parametrisierung von Segmenten im Pfad-Bestandteil der URI; sind also kein Bestandteil des Query-Abschnittes einer URI.

    Das Web-Framework Ruby on Rails hat letztes Jahr mit Semikolons geflirtet um ein paar Nicht-HTTP-Aspekte unterzubringen um damit Begrenzungen der HTML-Formulare zu umgehen. Letzten Monat hat Rails-Chefentwickler DHH das wieder rückgängig gemacht. In seiner Change-Nachricht schreibt er, dass u.a. die Semikolon-Parameter Probleme mit Caching und und Authentifizierung in Safari machen. Nicht so toll.

    Da es mir in PHP etwas mehr Arbeit machen würde, hätte ich gerne mal eure Meinung dazu gehört.

    Ich würde es lassen. Get-Parameter zur Identifizierung von Webseiten sind eh nicht so toll, wenn man nicht Suchen oder ähnliches nutzt. Sollte es für das PHP-Programm unbedingt notwendig sein, kann man mit mod_rewrite wunderbar saubere, &-freie URIs schaffen; ich würde das vorziehen.

    Tim

    1. Hallo,

      Das Web-Framework Ruby on Rails hat letztes Jahr mit Semikolons geflirtet um ein paar Nicht-HTTP-Aspekte unterzubringen um damit Begrenzungen der HTML-Formulare zu umgehen. Letzten Monat hat Rails-Chefentwickler DHH das wieder rückgängig gemacht. In seiner Change-Nachricht schreibt er, dass u.a. die Semikolon-Parameter Probleme mit Caching und und Authentifizierung in Safari machen. Nicht so toll.

      ich vermute ja auch eher, dass man mit Fremdbibliotheken Probleme bekommt. Das & erscheint mir mittelweile ein Defakto-Standard.

      Da es mir in PHP etwas mehr Arbeit machen würde, hätte ich gerne mal eure Meinung dazu gehört.

      Ich würde es lassen. Get-Parameter zur Identifizierung von Webseiten sind eh nicht so toll, wenn man nicht Suchen oder ähnliches nutzt. Sollte es für das PHP-Programm unbedingt notwendig sein, kann man mit mod_rewrite wunderbar saubere, &-freie URIs schaffen; ich würde das vorziehen.

      Ich verwende es ausschließlich für Suchen oder der Übergabe von Parametern, die mit der URI eigentlich nichts näheres zu tun haben. Aber selbst die könnte man über mod_rewrite ja theoretisch in die URI verpflanzen. Gibt es da noch, außer dem menschlichen Auge, einen bestimmten Grund für? Suchmaschinen indizieren ja mittlerweile auch Seiten über GET-Übergaben. Und wenn die Parameter eh nicht 'sprechend' sind, dürfte das doch auch für das Ranking oder die Treffer nicht von Belang sein?

      Ciao
      Heinzelhund

      1. Hallo,

        ich vermute ja auch eher, dass man mit Fremdbibliotheken Probleme bekommt. Das & erscheint mir mittelweile ein Defakto-Standard.

        In der Formularverarbeitung von Browsern auf jeden Fall. Der erwähnte Tip in der HTML Spezifikation ist für Anwender nur dann relevant, wenn URLs mit GET-Parametern verlinkt oder mittels einer Programmiersprache wie Javascript oder ähnlichem zusammengebastelt und abgesendet werden.

        Ich verwende es ausschließlich für Suchen oder der Übergabe von Parametern, die mit der URI eigentlich nichts näheres zu tun haben. Aber selbst die könnte man über mod_rewrite ja theoretisch in die URI verpflanzen. Gibt es da noch, außer dem menschlichen Auge, einen bestimmten Grund für?

        Nur das &amp;-Problem – und das ist nicht unbedingt ein Problem.

        Tim