Vraagtekenreeks - Query string

Image
Een adresbalk in Google Chrome met een URL met de queryreeks title=Query_string&action=edit.

Een querytekenreeks is een onderdeel van een uniform resource locator (URL) die waarden toewijst aan opgegeven parameters. Een queryreeks bevat gewoonlijk velden die door een webbrowser of een andere clienttoepassing aan een basis-URL zijn toegevoegd, bijvoorbeeld als onderdeel van een HTML-formulier.

Een webserver kan een HTTP-verzoek ( Hypertext Transfer Protocol ) afhandelen door een bestand uit het bestandssysteem te lezen op basis van het URL- pad of door het verzoek af te handelen met behulp van logica die specifiek is voor het type bron. In gevallen waarin speciale logica wordt aangeroepen, is de queryreeks beschikbaar voor die logica voor gebruik bij de verwerking ervan, samen met de padcomponent van de URL.

Structuur

Een typische URL die een querytekenreeks bevat, is als volgt:

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

Wanneer een server een verzoek voor een dergelijke pagina ontvangt, kan deze een programma uitvoeren, waarbij de queryreeks, die in dit geval name=ferretongewijzigd is , wordt doorgegeven aan het programma. Het vraagteken wordt gebruikt als scheidingsteken en maakt geen deel uit van de queryreeks.

Webframeworks kunnen methoden bieden voor het ontleden van meerdere parameters in de queryreeks, gescheiden door een scheidingsteken. In de onderstaande voorbeeld-URL worden meerdere queryparameters gescheiden door het ampersand , " &":

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

De exacte structuur van de querystring is niet gestandaardiseerd. De methoden die worden gebruikt om de queryreeks te ontleden, kunnen per website verschillen.

Een koppeling op een webpagina kan een URL hebben die een zoekreeks bevat. HTML definieert drie manieren waarop een user-agent de queryreeks kan genereren:

  • een HTML-formulier via het <form>...</form>element
  • een server-side image map via het ismapattribuut op het <img>element met een <img ismap>constructie
  • een geïndexeerde zoekopdracht via het nu verouderde <isindex>element

Webformulieren

Een van de oorspronkelijke toepassingen was om de inhoud van een HTML-formulier te bevatten , ook wel webformulier genoemd. In het bijzonder, wanneer een formulier met de velden field1, field2, field3wordt ingediend, wordt de inhoud van de velden als volgt gecodeerd als een queryreeks:

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

  • De querytekenreeks bestaat uit een reeks veldwaardeparen.
  • Binnen elk paar worden de veldnaam en waarde gescheiden door een gelijkteken , " =".
  • De reeks paren wordt gescheiden door het ampersand , " &" (of puntkomma , " ;" voor URL's die zijn ingesloten in HTML en niet worden gegenereerd door een <form>...</form>. Zie hieronder).

Hoewel er geen definitieve standaard is, laten de meeste webframeworks het toe om meerdere waarden aan een enkel veld te koppelen (bijv. field1=value1&field1=value2&field2=value3).

Voor elk veld van het formulier bevat de queryreeks een paar . Webformulieren kunnen velden bevatten die niet zichtbaar zijn voor de gebruiker; deze velden worden opgenomen in de queryreeks wanneer het formulier wordt verzonden. field=value

Deze conventie is een W3C- aanbeveling. W3C raadt aan dat alle webservers puntkomma- scheidingstekens ondersteunen naast ampersand- scheidingstekens om application/x-www-form-urlencoded querystrings in URL's in HTML-documenten toe te staan ​​zonder de entities van de entities te hoeven maken.

De inhoud van het formulier wordt alleen gecodeerd in de queryreeks van de URL als de methode voor het indienen van het formulier GET is . Dezelfde codering wordt standaard gebruikt wanneer de verzendmethode POST is , maar het resultaat wordt ingediend als de HTTP-aanvraagtekst in plaats van te worden opgenomen in een gewijzigde URL.

Geïndexeerde zoekopdracht

Voordat formulieren aan HTML werden toegevoegd, gaven browsers het <isindex>element weer als een besturingselement voor tekstinvoer met één regel. De tekst die in dit besturingselement is ingevoerd, is naar de server verzonden als een queryreeks die wordt toegevoegd aan een GET- verzoek voor de basis-URL of een andere URL die is opgegeven door het actionkenmerk. Dit was bedoeld om webservers in staat te stellen de verstrekte tekst als zoekcriteria te gebruiken, zodat ze een lijst met overeenkomende pagina's konden retourneren.

Wanneer de tekstinvoer in het geïndexeerde zoekbesturingselement wordt ingediend, wordt deze als volgt gecodeerd als een querytekenreeks:

argument1+argument2+argument3...

  • De queryreeks is samengesteld uit een reeks argumenten door de tekst op de spaties in woorden te ontleden.
  • De reeks wordt gescheiden door het plusteken , ' +'.

Hoewel het <isindex>element verouderd is en de meeste browsers het niet langer ondersteunen of weergeven, zijn er nog steeds enkele sporen van geïndexeerd zoeken. Dit is bijvoorbeeld de bron van de speciale behandeling van plusteken , ' +' binnen de codering van browser-URL's (wat tegenwoordig, met de afschaffing van geïndexeerd zoeken, bijna overbodig is met %20). Ook zullen sommige webservers die CGI ondersteunen (bijv. Apache ) de queryreeks verwerken in opdrachtregelargumenten als deze geen isgelijkteken , ' =' bevat (volgens paragraaf 4.4 van CGI 1.1). Sommige CGI-scripts zijn nog steeds afhankelijk van en gebruiken dit historische gedrag voor URL's die zijn ingesloten in HTML.

URL-codering

Hoofd artikel: Percentage-codering

Sommige tekens kunnen geen onderdeel zijn van een URL (bijvoorbeeld de spatie) en sommige andere tekens hebben een speciale betekenis in een URL: het teken #kan bijvoorbeeld worden gebruikt om een ​​subsectie (of fragment ) van een document nader te specificeren . In HTML-formulieren wordt het teken =gebruikt om een ​​naam van een waarde te scheiden. De generieke URI-syntaxis maakt gebruik van URL-codering om dit probleem op te lossen, terwijl HTML-formulieren enkele aanvullende vervangingen maken in plaats van procentuele codering toe te passen voor al dergelijke tekens. SPACE is gecodeerd als ' +' of ' %20'.

HTML 5 specificeert de volgende transformatie voor het verzenden van HTML-formulieren met de "GET"-methode naar een webserver. Hieronder volgt een korte samenvatting van het algoritme:

  • Tekens die niet kunnen worden geconverteerd naar de juiste tekenset, worden vervangen door numerieke HTML- tekenverwijzingen
  • SPACE is gecodeerd als ' +' of ' %20'
  • Letters ( A– Zen a– z), cijfers ( 0– 9) en de tekens ' ~',' -',' .' en ' _' blijven ongewijzigd
  • + is gecodeerd door %2B
  • Alle andere tekens worden gecodeerd als een %HH hexadecimale weergave met alle niet-ASCII-tekens eerst gecodeerd als UTF-8 (of een andere gespecificeerde codering)

Het octet dat overeenkomt met de tilde (" ~") is toegestaan ​​in queryreeksen door RFC3986, maar moet in HTML-formulieren procentueel worden gecodeerd naar " %7E".

De codering van SPACE als ' +' en de selectie van "as-is"-tekens onderscheidt deze codering van RFC 3986.

Voorbeeld

Als een formulier als volgt is ingesloten in een HTML- pagina: 

<form action="/cgi-bin/test.cgi" method="get">
  <input type="text" name="first" />
  <input type="text" name="second" />
  <input type="submit" />
</form>

en de gebruiker voegt de strings "dit is een veld" en "was het (al) duidelijk?" in de twee tekstvelden en op de verzendknop drukt, zal het programma test.cgi(het programma gespecificeerd door het action attribuut van het form element in het bovenstaande voorbeeld) de volgende vraagreeks ontvangen: first=this+is+a+field&second=was+it+clear+%28already%29%3F.

Als het formulier op de server wordt verwerkt door een CGI - script , kan het script de queryreeks doorgaans ontvangen als een omgevingsvariabele met de naam QUERY_STRING.

Volgen

Een programma dat een querystring ontvangt, kan een deel of het geheel negeren. Als de gevraagde URL overeenkomt met een bestand en niet met een programma, wordt de hele queryreeks genegeerd. Echter, ongeacht of de query string wordt gebruikt of niet, de hele URL waaronder het wordt opgeslagen in de server log files .

Dankzij deze feiten kunnen queryreeksen worden gebruikt om gebruikers te volgen op een manier die vergelijkbaar is met die van HTTP-cookies . Om dit te laten werken, moet elke keer dat de gebruiker een pagina downloadt, een unieke identifier worden gekozen en als een queryreeks worden toegevoegd aan de URL's van alle links die de pagina bevat. Zodra de gebruiker een van deze links volgt, wordt de bijbehorende URL opgevraagd bij de server. Op deze manier wordt de download van deze pagina gekoppeld aan de vorige.

Wanneer bijvoorbeeld een webpagina met het volgende wordt gevraagd: 

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

een unieke string, zoals e0a72cb2a2c7gekozen, en de pagina wordt als volgt gewijzigd: 

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

De toevoeging van de queryreeks verandert niets aan de manier waarop de pagina aan de gebruiker wordt getoond. Wanneer de gebruiker bijvoorbeeld de eerste link volgt, vraagt ​​de browser de pagina op foo.html?e0a72cb2a2c7bij de server, die negeert wat volgt ?en de pagina verzendt foo.htmlzoals verwacht, waarbij de querystring ook aan de links wordt toegevoegd.

Op deze manier zal elk volgend paginaverzoek van deze gebruiker dezelfde queryreeks bevatten e0a72cb2a2c7, waardoor kan worden vastgesteld dat al deze pagina's door dezelfde gebruiker zijn bekeken. Querystrings worden vaak gebruikt in combinatie met webbakens .

De belangrijkste verschillen tussen queryreeksen die worden gebruikt voor tracking en HTTP-cookies zijn dat:

  1. Query-strings maken deel uit van de URL en worden daarom opgenomen als de gebruiker de URL opslaat of naar een andere gebruiker verzendt; cookies kunnen tijdens browsesessies worden bewaard, maar worden niet opgeslagen of verzonden met de URL.
  2. Als de gebruiker via twee (of meer) onafhankelijke paden bij dezelfde webserver aankomt, krijgt hij twee verschillende queryreeksen toegewezen, terwijl de opgeslagen cookies hetzelfde zijn.
  3. De gebruiker kan cookies uitschakelen, in welk geval het gebruik van cookies voor tracking niet werkt. Het gebruik van queryreeksen voor tracking zou echter in alle situaties moeten werken.
  4. Verschillende queryreeksen die door verschillende bezoeken aan de pagina worden doorgegeven, betekenen dat de pagina's nooit worden bediend vanuit de browser (of proxy, indien aanwezig) cache, waardoor de belasting van de webserver toeneemt en de gebruikerservaring wordt vertraagd.

Compatibiliteit problemen

Volgens de HTTP- specificatie:

In de praktijk komen diverse ad-hocbeperkingen voor de lengte van de verzoekregel voor. Het wordt AANBEVOLEN dat alle HTTP-afzenders en -ontvangers minimaal een verzoekregellengte van 8000 octetten ondersteunen.

Als de URL te lang is, mislukt de webserver met de HTTP-statuscode 414 Request-URI Too Long .

De algemene oplossing voor deze problemen is om POST te gebruiken in plaats van GET en de parameters op te slaan in de hoofdtekst van de aanvraag. De lengtelimieten voor verzoekinstanties zijn doorgaans veel hoger dan die voor de URL-lengte. De limiet voor de POST-grootte is bijvoorbeeld standaard 2 MB voor IIS 4.0 en 128 KB voor IIS 5.0. De limiet is configureerbaar op Apache2 met behulp van de LimitRequestBodyrichtlijn, die het aantal bytes specificeert van 0 (wat betekent onbeperkt) tot 2147483647 (2 GB) dat is toegestaan ​​in een aanvraagtekst.

Zie ook

Referenties