Query string

From Wikipedia, the free encyclopedia - View original article

Jump to: navigation, search
The Mozilla address bar showing a URL with the query string title=Main_page&action=raw

In the World Wide Web, a query string is the part of a uniform resource locator (URL) that contains data to be passed to web applications such as CGI programs.

When a web page is requested via the Hypertext Transfer Protocol, the server locates a file in its file system based on the requested URL. This file may be a regular file or a program. In the second case, the server may (depending on its configuration) run the program, sending its output as the requested page. The query string is a part of the URL which is passed to the program. Its use permits data to be passed from the HTTP client (often a web browser) to the program which generates the web page.


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 unchanged to the program. The question mark is used as a separator and is not part of the query string.[1][2]

A link in a web page may have a URL that contains a query string, however, HTML defines three ways a web browser can generate the query string:

Web forms[edit]

The main use of query strings is to contain the content of an HTML form, also known as web form. In particular, when a form containing the fields field1, field2, field3 is submitted, the content of the fields is encoded as a query string as follows:


While there is no definitive standard, most web frameworks allow multiple values to be associated with a single field.[3][4]

For each field of the form, the query string contains a pair field=value. 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.[5] W3C recommends that all web servers support semicolon separators in addition to ampersand separators[6] to allow application/x-www-form-urlencoded query strings in URLs within HTML documents without having to entity escape ampersands.

Technically, the form content is only encoded as a 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 not sent as a query string, that is, is not added to the action URL of the form. Rather, the string is sent as the body of the HTTP request.[7]

Server-side image maps[edit]

See also: Image map

URL encoding[edit]

Main article: Percent-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 character # can be used to further specify a subsection (or fragment) of a document; the character = is used to separate a name from a value. A query string may need to be converted to satisfy these constraints. This can be done using a schema known as URL encoding.

In particular, encoding the query string uses the following rules:

The octet corresponding to the tilde ("~") character is often encoded as "%7E" by older URI processing implementations; the "%7E" can be replaced by "~" without changing its interpretation.

The encoding of SPACE as '+' and the selection of "as-is" characters distinguishes this encoding from RFC 1738.


As defined in RFC 1738, a URL of scheme http can contain a searchpart following the rest of the URL and separated from it by a ? character. RFC 3986 specifies that the query component of a URI is the part between the ? and the end of the URI or the character #. The term query string is of common usage for referring to this part for the case of HTTP URLs.


If a form is embedded in an HTML page as follows:

 <form action="cgi-bin/test.cgi" method="get">   <input type="text" name="first" />   <input type="text" name="second" />   <input type="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 will receive the following query string:


If the form is processed on the server by a CGI script, 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:

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

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

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

The addition of the query string does not change the way the page is shown to the user. When the user follows, for example, the first link, the browser requests the page foo.html?e0a72cb2a2c7 to the server, which ignores what follows ? and sends the page foo.html as expected, adding the query string to its links as well.

This way, any subsequent page request from this user will carry the same query string e0a72cb2a2c7, making it possible to establish that all these pages have been viewed by the same user. Query strings are often used in association with web beacons.

The main differences between query strings used for tracking and HTTP cookies are that:

  1. 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.
  2. If the user arrives at the same web server by two (or more) independent paths, it will be assigned two different query strings, while the stored cookies are the same.
  3. 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.
  4. 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[edit]

According to the HTTP specification:

Servers should be cautious about depending on URI (which includes URLs) lengths above 255 bytes, because some older client or proxy implementations may not properly support these lengths.[9]

The HTML 3 specification declares that any attribute value (e.g. url in <a href="url">) cannot have more than 1024 characters.[10] However, the HTML 4 specification omits this restriction.[11]

The specification does not dictate a minimum or maximum URL length, but implementation varies by browser and version. For example, Internet Explorer does not support URLs that have more than 2083 characters.[12][13] There is no limit on the number of parameters in a URL; only the raw (as opposed to URL encoded) character length of the URL matters. Web servers may also impose limits on the length of the query string, depending on how the URL and query string is stored. 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.[14] The limit is configurable on Apache2 using the LimitRequestBody directive, which specifies the number of bytes from 0 (meaning unlimited) to 2147483647 (2 GB) that are allowed in a request body.[15]

See also[edit]


  1. ^ T. Berners-Lee, W3C/MIT, R. Fielding, Day Software, L. Masinter, Adobe Systems (January 2005), "RFC 3986", "Syntax Components" (section 3). 
  2. ^ T. Berners-Lee, W3C/MIT, R. Fielding, Day Software, L. Masinter, Adobe Systems (January 2005), "RFC 3986", "Query" (section 3.4). 
  3. ^ ServletRequest (Java EE 6 ). Docs.oracle.com (2011-02-10). Retrieved on 2013-09-08.
  4. ^ uri - Authoritative position of duplicate HTTP GET query keys. Stack Overflow (2013-06-09). Retrieved on 2013-09-08.
  5. ^ Forms in HTML documents. W3.org. Retrieved on 2013-09-08.
  6. ^ Performance, Implementation, and Design Notes. W3.org. Retrieved on 2013-09-08.
  7. ^ Forms in HTML documents. W3.org. Retrieved on 2013-09-08.
  8. ^ "HTML URL Encoding Reference". W3Schools. Retrieved 3/1/2013. 
  9. ^ HTTP/1.1: Protocol Parameters. W3.org. Retrieved on 2013-09-08.
  10. ^ Understanding HTML and SGML. W3.org (1994-04-25). Retrieved on 2013-09-08.
  11. ^ On SGML and HTML. W3.org. Retrieved on 2013-09-08.
  12. ^ Maximum URL length is 2,083 characters in Internet Explorer. Support.microsoft.com. Retrieved on 2013-09-08.
  13. ^ Address Bar Improvements in Internet Explorer 8 Beta 1 - IEBlog - Site Home - MSDN Blogs. Blogs.msdn.com (2008-03-11). Retrieved on 2013-09-08.
  14. ^ What is the limit on QueryString / GET / URL parameters?. Classicasp.aspfaq.com (2001-11-13). Retrieved on 2013-09-08.
  15. ^ core - Apache HTTP Server. Httpd.apache.org. Retrieved on 2013-09-08.

External links[edit]