Abfragezeichenfolge

Eine Abfragezeichenfolge ist Teil einer URL ( Uniform Resource Locator ), die bestimmten Parametern Werte zuweist. Üblicherweise enthält eine Abfragezeichenfolge Felder, die von einem Webbrowser oder einer anderen Clientanwendung zur Basis-URL hinzugefügt werden, beispielsweise als Teil eines HTML-Dokuments, zur Auswahl des Seitenlayouts oder zum Springen zu bestimmten Positionen in Multimedia-Inhalten.

Ein Webserver kann eine HTTP-Anfrage entweder durch Lesen einer Datei aus seinem Dateisystem anhand des URL- Pfads oder durch Verarbeitung der Anfrage mithilfe einer ressourcenspezifischen Logik bearbeiten. Wird eine spezielle Logik aufgerufen, steht dieser die Abfragezeichenfolge zusammen mit dem Pfadbestandteil der URL zur Verarbeitung zur Verfügung.

Eine typische URL mit einer Abfragezeichenfolge sieht wie folgt aus:

https://example.com/over/there?name=ferret

Wenn ein Server eine Anfrage für eine solche Seite empfängt, kann er ein Programm ausführen und die Abfragezeichenfolge, die in diesem Fall lautet name=ferret, unverändert an das Programm übergeben. Das Fragezeichen dient als Trennzeichen und ist nicht Teil der Abfragezeichenfolge. ^{[ 1 ] [ 2 ]}

Web-Frameworks können Methoden zum Parsen mehrerer Parameter in der Abfragezeichenfolge bereitstellen, die durch ein Trennzeichen getrennt sind . ^{[ 3 ]} In der folgenden Beispiel-URL sind mehrere Abfrageparameter durch das kaufmännische Und-Zeichen (& &) getrennt:

https://example.com/path/to/page?name=ferret&color=purple

Die genaue Struktur der Suchanfrage ist nicht standardisiert. Die Methoden zur Analyse der Suchanfrage können sich von Website zu Website unterscheiden.

Ein Link auf einer Webseite kann eine URL enthalten, die eine Abfragezeichenfolge umfasst. HTML definiert drei Möglichkeiten, wie ein Benutzeragent die Abfragezeichenfolge generieren kann:

• ein HTML-Formular über das <form>...</form>Element
• eine serverseitige Image-Map über das ismapAttribut des <img>Elements mit einer <img ismap>Konstruktion
• eine indizierte Suche über das jetzt veraltete <isindex>Element

Eine der ursprünglichen Anwendungen bestand darin, den Inhalt eines HTML-Formulars , auch bekannt als Webformular, zu speichern. Insbesondere wird beim Absenden eines Formulars mit den Feldern field1, field2, field3der Inhalt der Felder wie folgt als Abfragezeichenfolge kodiert:

field1=value1&field2=value2&field3=value3...

• Die Abfragezeichenfolge besteht aus einer Reihe von Feld-Wert-Paaren.
• Innerhalb jedes Paares werden Feldname und Wert durch ein Gleichheitszeichen , " =" getrennt.
• Die einzelnen Paare werden durch das kaufmännische Und-Zeichen " &" getrennt ( Semikolone " ;" werden vom W3C nicht mehr empfohlen, siehe unten).

Obwohl es keinen endgültigen Standard gibt, erlauben die meisten Web-Frameworks , dass einem einzelnen Feld mehrere Werte zugeordnet werden (z. B. field1=value1&field1=value2&field2=value3). ^{[ 4 ] [ 5 ]}

Für jedes Feld des Formulars enthält die Abfragezeichenfolge ein Paar . Webformulare können Felder enthalten, die für den Benutzer nicht sichtbar sind; diese Felder werden beim Absenden des Formulars in die Abfragezeichenfolge aufgenommen. field=value

Diese Konvention ist eine W3C- Empfehlung. ^{[ 3 ]} In den Empfehlungen von 1999 empfahl das W3C, dass alle Webserver neben dem kaufmännischen Und- Zeichen (&) auch Semikolons als Trennzeichen unterstützen sollten ^{[ 6 ]} , um application/x-www-form-urlencoded- Query-Strings in URLs innerhalb von HTML-Dokumenten zu ermöglichen, ohne dass kaufmännische Und-Zeichen maskiert werden müssen. Seit 2014 empfiehlt das W3C jedoch, ausschließlich das kaufmännische Und-Zeichen als Query-Trennzeichen zu verwenden . ^{[ 7 ]}

Der Formularinhalt wird nur dann in der URL-Abfragezeichenfolge kodiert, wenn die Formularübermittlungsmethode GET ist . Dieselbe Kodierung wird standardmäßig verwendet, wenn die Übermittlungsmethode POST ist; das Ergebnis wird jedoch als HTTP-Anfragetext übermittelt und nicht in eine modifizierte URL eingebunden. ^{[ 8 ]}

Bevor Formulare in HTML eingeführt wurden, stellten Browser das <form> <isindex>-Element als einzeiliges Texteingabefeld dar. Der in dieses Feld eingegebene Text wurde als Query-String an den Server gesendet, zusätzlich zu einer GET- Anfrage an die Basis-URL oder eine andere, durch das actionAttribut angegebene URL. ^{[ 9 ]} Dies sollte es Webservern ermöglichen, den angegebenen Text als Suchkriterium zu verwenden, um eine Liste passender Seiten zurückzugeben. ^{[ 10 ]}

Wenn der in das Suchfeld des indizierten Systems eingegebene Text abgeschickt wird, wird er wie folgt als Abfragezeichenfolge kodiert:

argument1+argument2+argument3...

• Die Abfragezeichenfolge setzt sich aus einer Reihe von Argumenten zusammen, indem der Text an den Leerzeichen in Wörter zerlegt wird.
• Die einzelnen Teile der Reihe sind durch das Pluszeichen ' +' getrennt.

Obwohl das <isindex>Element veraltet ist und von den meisten Browsern nicht mehr unterstützt oder dargestellt wird, existieren noch immer Spuren der indizierten Suche. Beispielsweise ist dies die Quelle der speziellen Behandlung des Pluszeichens (' +') in der URL-Prozentkodierung des Browsers (die heute, da die indizierte Suche veraltet ist, nahezu überflüssig ist %20). Auch einige Webserver, die CGI unterstützen (z. B. Apache ), verarbeiten die Abfragezeichenfolge zu Kommandozeilenargumenten, wenn sie kein Gleichheitszeichen (' =') enthält (gemäß Abschnitt 4.4 von CGI 1.1). Manche CGI-Skripte verwenden dieses historische Verhalten weiterhin für in HTML eingebettete URLs.

Einige Zeichen dürfen nicht Teil einer URL sein (z. B. das Leerzeichen), und andere Zeichen haben in einer URL eine besondere Bedeutung: Beispielsweise kann das Zeichen# verwendet werden, um einen Unterabschnitt (oder ein Fragment ) eines Dokuments genauer zu spezifizieren. In HTML-Formularen =dient das Zeichen dazu, einen Namen von einem Wert zu trennen. Die generische URI-Syntax verwendet URL-Codierung , um dieses Problem zu lösen, während HTML-Formulare zusätzliche Ersetzungen vornehmen, anstatt für alle diese Zeichen eine Prozentcodierung anzuwenden. Das Leerzeichen wird als ' +' oder " %20" codiert. ^{[ 11 ]}

HTML 5 legt die folgende Transformation für das Absenden von HTML-Formularen mit der „GET“-Methode an einen Webserver fest. Nachfolgend eine kurze Zusammenfassung des Algorithmus:

• Zeichen, die nicht in den korrekten Zeichensatz konvertiert werden können, werden durch numerische HTML-Zeichenreferenzen ersetzt ^{[ 12 ].}
• Leerzeichen werden als ' +' oder ' %20' kodiert.
• Buchstaben ( A– Zund a– z), Zahlen ( 0– 9) und die Zeichen ' ~',' -',' .' und ' _' bleiben unverändert.
• +wird durch %2B kodiert
• Alle anderen Zeichen werden als %HHHexadezimaldarstellung kodiert , wobei alle Nicht-ASCII-Zeichen zuerst als UTF-8 (oder eine andere angegebene Kodierung) kodiert werden.

Das Oktett, das der Tilde (" ") entspricht ~, ist gemäß RFC3986 in Abfragezeichenfolgen zulässig, muss aber in HTML-Formularen als Prozentkodierung in " %7E" dargestellt werden.

Die Kodierung des Leerzeichens als ' +' und die Auswahl von "unveränderlichen" Zeichen unterscheidet diese Kodierung von RFC 3986.

Wenn ein Formular wie folgt in eine HTML- Seite eingebettet ist :

<formaction="/cgi-bin/test.cgi"method="get"><inputtype="text"name="first"/><inputtype="text"name="second"/><inputtype="submit"/></form>

and the user inserts the strings "this is a field" and "was it clear (already)?" in the two text fields and presses the submit button, the program test.cgi (the program specified by the actionattribute of the formelement in the above example) will receive the following query string: first=this+is+a+field&second=was+it+clear+%28already%29%3F.

If the form is processed on the server by a CGIscript, the script may typically receive the query string as an environment variable named QUERY_STRING.

A program receiving a query string can ignore part or all of it. If the requested URL corresponds to a file and not to a program, the whole query string is ignored. However, regardless of whether the query string is used or not, the whole URL including it is stored in the server log files.

These facts allow query strings to be used to track users in a manner similar to that provided by HTTP cookies. For this to work, every time the user downloads a page, a unique identifier must be chosen and added as a query string to the URLs of all links the page contains. As soon as the user follows one of these links, the corresponding URL is requested to the server. This way, the download of this page is linked with the previous one.

For example, when a web page containing the following is requested:

<ahref="foo.html">see my page!</a><ahref="bar.html">mine is better</a>

a unique string, such as e0a72cb2a2c7 is chosen, and the page is modified as follows:

<ahref="foo.html?e0a72cb2a2c7">see my page!</a><ahref="bar.html?e0a72cb2a2c7">mine is better</a>

Das Hinzufügen des Query-Strings ändert nichts daran, wie die Seite dem Benutzer angezeigt wird. Wenn der Benutzer beispielsweise dem ersten Link folgt, fordert der Browser die Seite foo.html?e0a72cb2a2c7vom Server an. Dieser ignoriert die nachfolgenden Elemente ?und sendet die Seite foo.htmlwie erwartet, wobei der Query-String auch zu den Links hinzugefügt wird.

Dadurch enthält jede nachfolgende Seitenanfrage dieses Nutzers dieselbe Abfragezeichenfolge e0a72cb2a2c7, wodurch sich feststellen lässt, dass alle diese Seiten vom selben Nutzer aufgerufen wurden. Abfragezeichenfolgen werden häufig in Verbindung mit Web-Beacons verwendet .

Die Hauptunterschiede zwischen Query-Strings zur Nachverfolgung und HTTP-Cookies sind folgende:

1. Query-Strings sind Bestandteil der URL und werden daher mitgesendet, wenn der Benutzer die URL speichert oder an einen anderen Benutzer weiterleitet; Cookies können über mehrere Browsersitzungen hinweg erhalten bleiben, werden aber nicht mit der URL gespeichert oder gesendet.
2. Wenn der Benutzer über zwei (oder mehr) unabhängige Wege auf denselben Webserver gelangt, werden ihm zwei unterschiedliche Abfragezeichenfolgen zugewiesen, während die gespeicherten Cookies identisch sind.
3. Der Nutzer kann Cookies deaktivieren; in diesem Fall funktioniert die Verwendung von Cookies für Tracking-Zwecke nicht. Die Verwendung von Query-Strings für Tracking-Zwecke sollte jedoch in allen Situationen funktionieren.
4. Unterschiedliche Abfragezeichenfolgen, die bei verschiedenen Besuchen der Seite übergeben werden, bedeuten, dass die Seiten nie aus dem Browser-Cache (oder dem Proxy-Cache, falls vorhanden) geladen werden, wodurch die Last auf dem Webserver erhöht und die Benutzererfahrung verlangsamt wird.

Gemäß der HTTP- Spezifikation:

In der Praxis finden sich verschiedene, individuell festgelegte Beschränkungen der Anforderungszeilenlänge. Es wird EMPFOHLEN, dass alle HTTP-Sender und -Empfänger mindestens eine Anforderungszeilenlänge von 8000 Oktetten unterstützen. ^{[ 13 ]}

Ist die URL zu lang, schlägt der Webserver mit dem HTTP-Statuscode 414 Request-URI Too Long fehl.

Die gängige Lösung für diese Probleme besteht darin, POST anstelle von GET zu verwenden und die Parameter im Anfragetext zu speichern. Die Längenbeschränkungen für Anfragetexte sind typischerweise deutlich höher als die für die URL-Länge. Beispielsweise beträgt die Standardgröße für POST-Anfragen 2 MB unter IIS 4.0 und 128 KB unter IIS 5.0. Unter Apache2 lässt sich diese Beschränkung mithilfe der LimitRequestBodyDirektive konfigurieren, die die Anzahl der im Anfragetext zulässigen Bytes von 0 (unbegrenzt) bis 2147483647 (2 GB) angibt. ^{[ 14 ]}