Content deleted Content added
m →Tracking: an -> a |
m Reverted edits by 2409:40E4:110C:DA9F:DD:46FF:FEF8:CDEF (talk): editing tests (HG) (3.4.13) |
||
| (584 intermediate revisions by more than 100 users not shown) | |||
Line 1:
{{Short description|Part of a URL that assigns values to specified parameters}}
A '''query string''' is a part of a uniform resource locator ([[URL]]) that assigns values to specified parameters. A query string commonly includes fields added to a base URL by a Web browser or other client application, for example as part of an HTML document, choosing the appearance of a page, or jumping to positions in multimedia content.
[[File:Query string.png|frame|center|An [[address bar]] on [[Google Chrome]] showing a URL (Uniform Resource Locator) with the query string <code>?title=Query_string&action=edit</code>]]
A web server can handle a [[HTTPS|Hypertext Transfer Protocol]] (HTTP) request either by reading a file from its [[file system]] based on the [[URL]] path or by handling the request using logic that is specific to the type of resource. In cases where special logic is invoked, the query string will be available to that logic for use in its processing, along with the path component of the URL.
== Structure ==
A typical URL containing a query string is as follows:{{quote|1=<code><nowiki>https://example.com/over/there?name=ferret</nowiki></code>}}
When a server receives a request for such a page, it
| url = http://tools.ietf.org/html/rfc3986#section-3
| title = RFC 3986
| author = T. Berners-Lee
| author2 = R. Fielding
| author3 = L. Masinter
| date = January 2005
| at = "Syntax Components" (section 3)}}</ref><ref>{{cite web
| url = http://tools.ietf.org/html/rfc3986#section-3.4
| title = RFC 3986
| author = T. Berners-Lee
| author2 = R. Fielding
| author3 = L. Masinter
| date = January 2005
| at = "Query" (section 3.4)}}</ref>
[[Web Framework|Web frameworks]] may provide methods for parsing multiple parameters in the query string, separated by some delimiter.<ref name="w3c-recom" /> In the example URL below, multiple query parameters are separated by the [[ampersand]], "<code>&</code>":
{{quote|1=<code><nowiki>https://example.com/path/to/page?name=ferret&color=purple</nowiki></code>}}
The exact structure of the query string is not standardized. Methods used to parse the query string may differ between websites.
* an [[form (HTML)|HTML form]] via the {{tag|form}} element
* a [[Image map#Server-side|server-side image map]] via the {{code|ismap}} attribute on the {{tag|img|open}} element with an {{tag|img|open|params=ismap}} construction
* an indexed search via the now deprecated {{tag|isindex|open}} element
=== Web forms ===
One of the original uses was to contain the content of an [[form (HTML)|HTML form]], also known as web form. In particular, when a form containing the fields <code>field1</code>, <code>field2</code>, <code>field3</code> is submitted, the content of the fields is encoded as a query string as follows:
{{quote|1=<code>field1=value1&field2=value2&field3=value3...</code>}}
* The query string is composed of a series of field-value pairs.
* Within each pair, the field name and value are separated by an [[equals sign]], "<code>=</code>".
* The series of pairs is separated by the [[ampersand]], "<code>&</code>" ([[semicolons]] "<code>;</code>" are not recommended by the [[W3C]] anymore, see below).
While there is no definitive standard, most [[web framework]]s allow multiple values to be associated with a single field (e.g. <code>field1=value1&field1=value2&field2=value3</code>).<ref>{{cite web|url=https://docs.oracle.com/javaee/6/api/javax/servlet/ServletRequest.html#getParameterValues(java.lang.String) |title=ServletRequest (Java EE 6 )|website=docs.oracle.com |date=2011-02-10|access-date=2013-09-08}}</ref><ref>{{cite web|url=https://stackoverflow.com/questions/1746507/authoritative-position-of-duplicate-http-get-query-keys |title=uri – Authoritative position of duplicate HTTP GET query keys|website=Stack Overflow |date=2013-06-09|access-date=2013-09-08}}</ref>
For each [[Field (computer science)|field]] of the form, the query string contains a pair <code><var>field</var>=<var>value</var></code>. Web forms may include fields that are not visible to the user; these fields are included in the query string when the form is submitted.
This convention is a [[W3C]] recommendation.<ref name="w3c-recom">[https://www.w3.org/TR/REC-html40/interact/forms.html#form-content-type Forms in HTML documents]. W3.org. Retrieved on 2013-09-08.</ref> In the recommendations of 1999, W3C recommended that all web servers support [[semicolon]] separators in addition to [[ampersand]] separators<ref>[http://www.w3.org/TR/1999/REC-html401-19991224/appendix/notes.html#h-B.2.2 Performance, Implementation, and Design Notes]. W3.org. Retrieved on 2013-09-08.</ref> to allow [[application/x-www-form-urlencoded]] query strings in URLs within HTML documents without having to entity escape ampersands. Since 2014, W3C recommends to use only [[ampersand]] as query separator.<ref name="w3c-recom-2014">{{cite web | url=https://www.w3.org/TR/2014/REC-html5-20141028/forms.html#url-encoded-form-data | title=4.10 Forms — HTML5 }}</ref>
The form content is only encoded in the URL's query string when the form submission method is [[GET (HTTP)|GET]]. The same encoding is used by default when the submission method is [[POST (HTTP)|POST]], but the result is submitted as the [[HTTP request]] body rather than being included in a modified URL.<ref name="html5" />
=== Indexed search ===
Before [[form (HTML)|forms]] were added to HTML, browsers rendered the –{{tag|isindex|open}} element as a single-line text-input control. The text entered into this control was sent to the server as a query string addition to a [[GET (HTTP)|GET]] request for the base URL or another URL specified by the {{code|action}} attribute.<ref>{{cite web |title=<isindex> |url=https://developer.mozilla.org/en-US/docs/Web/HTML/Element/isindex |website=HTML (HyperText Markup Language) |access-date=2015-11-21 |archive-date=2017-10-19 |archive-url=https://web.archive.org/web/20171019030835/https://developer.mozilla.org/en-US/docs/Web/HTML/Element/isindex |url-status=dead }}</ref> This was intended to allow web servers to use the provided text as query criteria so they could return a list of matching pages.<ref>{{cite web |title=HTML/Elements/isindex |url=https://www.w3.org/wiki/HTML/Elements/isindex |website=W3C Wiki |access-date=2020-03-20 |archive-date=2021-06-22 |archive-url=https://web.archive.org/web/20210622024419/https://www.w3.org/wiki/HTML/Elements/isindex |url-status=dead }}</ref>
When the text input into the indexed search control is submitted, it is encoded as a query string as follows:
{{quote|1=<code>argument1+argument2+argument3...</code>}}
* The query string is composed of a series of arguments by parsing the text into words at the spaces.
* The series is separated by the [[plus sign]], '<code>+</code>'.
Though the {{tag|isindex|open}} element is deprecated and most browsers no longer support or render it, there are still some vestiges of indexed search in existence. For example, this is the source of the special handling of [[plus sign]], '<code>+</code>' within browser URL percent encoding (which today, with the deprecation of indexed search, is all but redundant with <code>%20</code>). Also some web servers supporting [[Common Gateway Interface|CGI]] (e.g., [[Apache HTTP Server|Apache]]) will process the query string into command line arguments if it does not contain an [[equals sign]], '<code>=</code>' (as per section 4.4 of CGI 1.1). Some CGI scripts still depend on and use this historic behavior for URLs embedded in HTML.
==
{{Main|Percent-encoding}}
Some [[Character (computing)|characters]] cannot be part of a URL (for example, the space) and some other characters have a special meaning in a URL: for example, the character <code>#</code> can be used to further specify a subsection (or [[Fragment identifier|fragment]]) of a document. In HTML forms, the character <code>=</code> is used to separate a name from a value. The URI generic syntax uses [[Percent-encoding#Percent-encoding reserved characters|URL encoding]] to deal with this problem, while HTML forms make some additional substitutions rather than applying percent encoding for all such characters. SPACE is encoded as '<code>+</code>' or "<code>%20</code>".<ref name="w3schools" />
[[HTML 5]] specifies the following transformation for submitting HTML forms with the "GET" method to a web server. The following is a brief summary of the algorithm:
* Characters that cannot be converted to the correct charset are replaced with HTML [[numeric character reference]]s<ref name="html5 urlencoded" />
* SPACE is encoded as '<code>+</code>' or '<code>%20</code>'
* Letters (<code>A</code>–<code>Z</code> and <code>a</code>–<code>z</code>), numbers (<code>0</code>–<code>9</code>) and the characters '<code>~</code>','<code>-</code>','<code>.</code>' and '<code>_</code>' are left as-is
* <code>+</code> is encoded by %2B
* All other characters are encoded as a <code>%HH</code> [[hexadecimal]] representation with any non-ASCII characters first encoded as UTF-8 (or other specified encoding)
The octet corresponding to the tilde ("<code>~</code>") is permitted in query strings by RFC3986 but required to be percent-encoded in HTML forms to "<code>%7E</code>".
The encoding of SPACE as '<code>+</code>' and the selection of "as-is" characters distinguishes this encoding from RFC 3986.
== Example ==
If a [[Form (web)|form]] is embedded in an [[HTML]] page as follows:
<syntaxhighlight lang="html">
<form action="/cgi-bin/test.cgi" method="get">
<input type="text" name="first" />
<input type="text" name="second" />
<input type="submit" />
</form>
</syntaxhighlight>
and the user inserts the strings "this is a field" and "was it clear (already)?" in the two [[Text box|text fields]] and presses the submit button, the program <code>test.cgi</code> (the program specified by the <code>action</code> [[HTML attribute|attribute]] of the <code>form</code> [[HTML element|element]] in the above example) will receive the following query string:
<code>first=this+is+a+field&second=was+it+clear+%28already%29%3F</code>.
If the form is processed on the [[web server|server]] by a [[Common Gateway Interface|CGI]] [[Scripting language|script]], the script may typically receive the query string as an [[environment variable]] named <code>QUERY_STRING</code>.
== Tracking ==
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 [[computer data logging|log files]].
These facts allow query strings to be used to track users in a manner similar to that provided by [[HTTP cookie]]s. 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:
<syntaxhighlight lang="html">
<a href="
<a href="bar.html">mine is better</a>
</syntaxhighlight>
a unique string, such as <code>
<syntaxhighlight lang="html">
<a href="
<a href="bar.html?e0a72cb2a2c7">mine is better</a>
</syntaxhighlight>
The addition of the query string
This way, any subsequent page request from this user will carry the same query string <code>
The main differences between query strings used for tracking and HTTP cookies are that:
# Query strings form part of the URL, and are therefore included if the user saves or sends the URL to another user; cookies can be maintained across browsing sessions, but are not saved or sent with the URL.
# If the user arrives
# The user can disable cookies, in which case using cookies for tracking does not work. However, using query strings for tracking should work in all situations.
# Different query strings passed by different visits to the page will mean that the pages are never served from the browser (or proxy, if present) cache thereby increasing the load on the web server and slowing down the user experience.
== Compatibility issues ==
<blockquote>Various ad hoc limitations on request-line length are found in practice. It is RECOMMENDED that all HTTP senders and recipients support, at a minimum, request-line lengths of 8000 octets.<ref>[https://tools.ietf.org/html/rfc7230#section-3.1.1 HTTP/1.1 Message Syntax and Routing]. ietf.org. Retrieved on 2014-07-31.</ref></blockquote>
If the URL is too long, the web server fails with the [[List of HTTP status codes#414|414 Request-URI Too Long]] HTTP status code.
The common workaround for these problems is to use [[POST (HTTP)|POST]] instead of [[GET (HTTP)|GET]] and store the parameters in the request body. The length limits on request bodies are typically much higher than those on URL length. For example, the limit on POST size, by default, is 2 MB on IIS 4.0 and 128 KB on IIS 5.0. The limit is configurable on Apache2 using the <code>LimitRequestBody</code> directive, which specifies the number of bytes from 0 (meaning unlimited) to 2147483647 (2 GB) that are allowed in a request body.<ref>[https://httpd.apache.org/docs/2.2/mod/core.html#limitrequestbody core – Apache HTTP Server]. Httpd.apache.org. Retrieved on 2013-09-08.</ref>
== See also ==
{{div-col}}
* [[Clean URL]]
* [[DoubleClick Click Identifier|Click identifier]]
* [[Common Gateway Interface]] (CGI)
* [[HTTP cookie]]
* [[HyperText Transfer Protocol]] (HTTP)
* [[Semantic URL]]s
* [[URI fragment]]
* [[URI normalization]]
* [[URI scheme]]
* [[UTM parameters]]
* [[Web beacon]]
{{div-col-end}}
==
{{Reflist | refs=
<ref name="html5">[https://www.w3.org/TR/html52/sec-forms.html#form-submission-algorithm], HTML5.2, W3C recommendation, 14 December 2017</ref>
<ref name="w3schools">{{cite web|title=HTML URL Encoding Reference|url=https://www.w3schools.com/tags/ref_urlencode.asp|publisher=W3Schools|access-date=May 1, 2013}}</ref>
<ref name="html5 urlencoded">The [https://www.w3.org/TR/html52/sec-forms.html#application-x-www-form-urlencoded-encoding-algorithm ''application/x-www-form-urlencoded'' encoding algorithm], HTML5.2, W3C recommendation, 14 December 2017</ref>
}}
[[Category:URL]]
[[Category:String (computer science)]]
| |||