Query string

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.

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>|alt=An address bar on Google Chrome showing a URL (Uniform Resource Locator) with the query string title=Query_string&action=edit]]

A web server can handle a 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:

When a server receives a request for such a page, it may run a program, passing the query string, which in this case is <code>name=ferret</code>, unchanged to the program. The question mark is used as a separator, and is not part of the query string.

Web frameworks may provide methods for parsing multiple parameters in the query string, separated by some delimiter.

For each 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. In the recommendations of 1999, W3C recommended that all web servers support semicolon separators in addition to ampersand separators 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.

The form content is only encoded in the URL's query string when the form submission method is GET. The same encoding is used by default when the submission method is POST, but the result is submitted as the HTTP request body rather than being included in a modified URL. This was intended to allow web servers to use the provided text as query criteria so they could return a list of matching pages.

When the text input into the indexed search control is submitted, it is encoded as a query string as follows:

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 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 CGI (e.g., 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.

URL encoding

Some 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 <span lang="en">character</span> <code>#</code> can be used to further specify a subsection (or 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 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>".</blockquote>

If the URL is too long, the web server fails with the 414 Request-URI Too Long HTTP status code.

The common workaround for these problems is to use POST instead of 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.

Structure

URL encoding

See also

References