Řetězec dotazu

Řetězec dotazu je nepovinná část URL (Uniform Resource Locatoru), která umožňuje WWW klientovi předat WWW serveru jednu nebo více hodnot obvykle zadaných uživatelem jako dotaz nebo výsledek vyplnění HTML formuláře. V URL je za znakem otazník téměř na konci URL (za řetězcem dotazu může být pouze kotva uvozená znakem křížek) a nejčastěji má tvar seznamu dvojic jméno-hodnota, v němž se přiřazují hodnoty zadaným parametrům. Uživatelské volby přenášené v řetězci dotazu mohou obsahovat například výběr formátu nebo vzhledu stránky nebo skok na určité místo v multimediálním obsahu.

Adresní řádek v prohlížeči Google Chrome ukazující URL s řetězcem dotazu titul=Query_string&action=edit

WWW server může na HTTP požadavek reagovat načtením souboru uloženého v souborovém systému v adresáři, jehož jméno je odvozeno z cesty v URL nebo zpracováním požadavku pomocí logiky specifické pro daný typ prostředku. V případech, kdy je vyvolána speciální logika, bude mít tato logika k dispozici řetězec dotazu pro použití při zpracování požadavku, spolu se cestou zadanou v URL.

Struktura

Typické URL obsahující řetězec dotazu vypadá takto:

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

Když server přijme požadavek na takovou stránku, může spustit program, kterému jako parametr předá řetězec dotazu v nezměněné podobě, v tomto případě name=ferret. Otazník slouží jako oddělovač dotazu, ale není součástí řetězce dotazu.

Webové frameworky mohou poskytovat metody pro analýzu několika parametrů v řetězci dotazu, oddělených určitými oddělovači. V níže uvedeném příkladu URL jsou parametry dotazu odděleny znaky ampersand &:

https://example.com/cesta/ke/stránce?name=ferret&color=purple

Přesná struktura řetězce dotazu není standardizována. Metody používané pro analýzu řetězce dotazu různými webovými severy se mohou mírně lišit.

Odkazem na WWW stránku může být URL, které obsahuje řetězec dotazu. Hypertext Markup Language definuje tři způsoby, jak může uživatelský agent vytvořit řetězec dotazu:

• pomocí HTML formuláře zadaného elementem <form>
• pomocí klikací mapy na straně serveru použitím atributu ismap elementu <img> s konstrukcí <img>
• pomocí nyní nedoporučovaného elementu <isindex> pro indexované vyhledávání

Webové formuláře

Jedním z původních použití byl přenos hodnot z HTML (WWW) formulářů. Konkrétně, když je odeslán formulář obsahující pole field1, field2, field3, obsah polí je zakódován do řetězce dotazu takto:

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

• Řetězec dotazu je posloupnost dvojic pole-hodnota.
• V každé dvojici je jméno a hodnota pole odděleno znakem rovnítko, =.
• Jednotlivé dvojice jsou odděleny znakem ampersand & (použití středníků ; W3C vůbec nedoporučuje, viz níže).

Přestože neexistuje žádný definitivní standard, většina webových frameworků umožňuje několik hodnoty být souvisejících s jediný pole (například field1=value1&field1=value2&field2=value3).

Pro každý pole formuláře obsahuje řetězec dotazu dvojici pole=hodnota. Webové formuláře mohou obsahovat i pole, které nejsou pro uživatele viditelná; tato pole jsou obsažena v řetězci dotazu, když je formulář zadaný.

Tato konvence je doporučení W3C. V doporučení z roku 1999 W3C doporučovalo, aby všechny WWW servery podporovaly kromě ampersandu jako oddělovače dvojic také středník umožnit applicationXx-www-form-urlencoded řetězce dotazu v URLs uvnitř HTML dokumenty aniž by měly na entity escape ampersands. Od roku 2014 W3C doporučuje používat jako oddělovač dvojic pouze ampersand.

Obsah formuláře je zakódovaný v URL řetězci dotazu pouze tehdy, pokud metoda zadání formuláře je GET. Stejné kódování se používá implicitně, když metoda zadání je POST, ale výsledek je předáván v těle HTTP požadavku nikoli v URL.

Indexované vyhledávání

Než byly do HTML přidány formuláře, prohlížeče vykreslovaly element <isindex> jako jednořádkový řídicí prvek pro vstup textu. Text zadaný do tohoto prvku byl posílán na server jako řetězec dotazu přidaný k GET požadavku na základní URL nebo URL zadané atributem action. Měl umožňovat WWW serverům použít zadaný text jako kritérium dotazu tak, aby mohly vracet seznam vyhovujících stránek.

Textový vstup zadaný pro indexované vyhledávání je přenášen zakódovaný následujícím způsobem:

argument1+argument2+argument3...

• Řetězec dotazu se skládá z několika argumentů, které jsou tvořeny slovy oddělenými mezerou.
• Jednotlivá slova jsou oddělena znaky plus +.

I když je element <isindex> nedoporučovaný a většina prohlížečů jej už nepodporuje ani nevykresluje, některé pozůstatky indexovaného vyhledávání stále existují. Jedním z nich je speciální zpracovávání znaku plus, +, při URL kódování pomocí výrazů s procenty (který je v době, kdy je indexované vyhledávání nedoporučované, by docela dobře mohlo být %20). Některé WWW servery podporující CGI (například Apache) převádějí řetězec dotazu, který neobsahuje rovnítko = (podle části 4.4 standardu CGI 1.1), na argumenty příkazového řádku. Některé CGI skripty stále používají toto historické chování pro URL zadaná v HTML.

URL kódování

Podrobnější informace naleznete v článku URL kódování.

Některé znaky (například mezera) se v URL nesmí objevit a některé jiné znaky mají speciální význam: například znak # slouží pro bližší udání subsekce (nebo části) dokumentu. Znak = se v HTML formulářích používá pro oddělení jména a hodnoty. Obecný syntax URI používá URL kódování pro odstranění tohoto problému, ale HTML formuláře provádějí některé další substituce místo toho, aby pro všechny takové znaky použily kódování pomocí výrazů s procentem. Znak mezera je zakódován jako + nebo %20.

HTML 5 udává následující transformace pro zpracování HTML formuláře přenášeného mětodou „GET“ na WWW server:

• Znak plus + je zakódován jako %2B
• Znak mezera je zakódován jako + nebo %20
• Písmena (A–Z a a–z), číslice (0–9) a znaky ~, -, . a _ jsou ponechány beze změny
• Znaky, které nelze zkonvertovat do použitého kódování, jsou nahrazeny číselnou HTML entitou
• Všechny ostatní ne-ASCII znaky jsou nejprve zkonvertovány do zadaného kódování (obvykle UTF-8) a pak jsou jednotlivé bajty zakódovány posloupností %HH, kde HH je kód bajtu v šestnáctkové soustavě

V řetězcích dotazu podle RFC3986 se může objevit oktet odpovídající znaku tilda (~), který v HTML formulářích musí být zakódován jako %7E.

Toto kódování se odlišuje od RFC 3986 kódováním znaku mezera jako + a výběrem znaků, které se ponechávají nezakódované.

Příklad

Pokud je formulář vložen do HTML stránky takto:

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

a uživatel vloží text „první pole“ do prvního textového pole a „další pole (poslední)“ do druhého a stiskne tlačítko Submit, program zadaný parametrem action HTML prvku form ve výše uvedeném příkladě, tj. program test.cgi) přijme následující řetězec dotazu: first=prvn%C3%AD+pole&second=dal%C5%A1%C3%AD+pole+%28posledn%C3%AD%29.

Pokud je formulář na webovém serveru zpracován CGI skriptem, je mu řetězec dotazu obvykle předán jako hodnota proměnné prostředí se jménem QUERY_STRING.

Sledování

Program, kterému se předává řetězec dotazu, může jeho část nebo celý řetězec ignorovat. Pokud požadované URL odpovídá souboru a ne programu, je ignorován celý řetězec dotazu. Bez ohledu na to, zda byl řetězec dotazu použit nebo ne, bude však do žurnálového souboru webového serveru uloženo kompletní URL včetně řetězce dotazu.

To umožňuje používat řetězce dotazu pro sledování uživatelů podobným způsobem, jaký poskytují HTTP cookies. Aby to fungovalo, musí být pokaždé, když uživatel načte stránku, vytvořen jedinečný identifikátor a přidán jako řetězec dotazu k URL všech odkazů, které stránka obsahuje. Jakmile uživatel následuje libovolný z těchto odkazů, ze serveru je požadováno odpovídající URL. Tímto způsobem lze načtení stránky provázat s předchozí činností.

Pokud je například požadována WWW stránka obsahující

 <a href="foo.html">podívej se na moji stránku!</a>
 <a href="bar.html">moje je lepší</a>

a jako jedinečný řetězec je zvoleno např. e0a72cb2a2c7, bude uvedený kus stránky zaslán takto:

 <a href="foo.html?e0a72cb2a2c7">podívej se na moji stránku!</a>
 <a href="bar.html?e0a72cb2a2c7">moje je lepší</a>

Přidání řetězce dotazu nemění, jakým způsobem bude stránka zobrazena, ale mění adresy odkazů; když uživatel klikne na první odkaz, prohlížeč si ze serveru vyžádá stránku foo.html?e0a72cb2a2c7; server ignoruje, co následuje za znakem ?, pošle soubor foo.html, ale řetězec dotazu přidá i do URL odkazů uvedených v tomto souboru.

Tímto způsobem libovolný další požadavek na stránku od tohoto uživatele bude obsahovat stejný řetězec dotazu e0a72cb2a2c7, což umožňuje zjistit, že si tyto stránky prohlížel stejný uživatel. Řetězce dotazu se často používají se sledovacím pixelem.

Hlavní rozdíly ve sledování pomocí řetězců dotazu a HTTP cookies jsou tyto:

1. Řetězec dotazu je částí URL, takže pokud si uživatel URL uloží nebo jej pošle jinému uživateli, bude zahrnovat i řetězec dotazu; cookies mohou být zachovány v rámci komunikace jednoho uživatele s WWW serverem, ale nejsou ukládány ani posílány v URL.
2. Pokud uživatel dospěje na stejný WWW server dvěma (nebo více) nezávislými cestami, budou mu přiřazeny dva různé řetězce dotazu, zatímco uložené cookies budou stejná.
3. Uživatel může cookies zakázat, a pak sledování pomocí cookies nebude fungovat. Sledování pomocí řetězců dotazů bude fungovat ve všech situacích.
4. Protože při různých návštěvách jsou předávány různé řetězce dotazu, nebudou fungovat cache prohlížeče ani případné proxy, což může způsobit zvýšené zatížení WWW serveru a zpomalení komunikace.

Problémy s kompatibilitou

Podle specifikace HTTP:

V praxi se objevují různá ad hoc omezení na délku požadavek řádku. DOPORUČUJE se, aby všechny klientské i serverové aplikace HTTP podporovaly délku řádku požadavku minimálně 8000 oktetů.

Pokud je URL příliš dlouhé, WWW server informuje o chybě stavovým kódem 414 Request-URI Too Long.

Obvyklou nápravou této chyby je použití metody POST místo metody GET a uvedení parametrů v těle požadavku. Limity délky těla požadavku jsou typicky mnohem větší než limity délky URL. IIS 4.0 má například limit velikosti těla POST požadavku implicitně 2 MB, a IIS 5.0 128 KB. U WWW serveru Apache2 se limit délky těla POST dotazu konfiguruje direktivou LimitRequestBody, která udává počet bytů od 0 (neomezená délka) do 2147483647 (2 GB).

Odkazy

Reference

V tomto článku byl použit překlad textu z článku Query string na anglické Wikipedii.

Související články

• Kotva
• URI normalizace
• Uniform Resource Locator
• Slug
• Common Gateway Interface (CGI)
• HTTP cookie
• Hypertext Transfer Protocol (HTTP)
• Sémantické URL
• Uniform Resource Identifier#schéma
• UTM parametry
• Sledovací pixel