In the World Wide Web, a query string is the part of a uniform resource locator containing
data that does not fit conveniently into a hierarchical path structure.
The query string commonly includes fields added to a base URI by a Web browser or other
client application, for example as part of a HTML form.
A web server can handle a Hypertext Transfer Protocol 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 the case that 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:
http:example.comthere?name=ferret
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.
A link in a web page may have a URL that contains a query string, while HTML additionally defines
three ways a user agent can generate the query string:
an HTML form via the ... element a server-side image map via the ismap attribute
on the element with a construction
an indexed search via the now deprecated element
Web forms 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:
field1=value1&field2=value2&field3=value3...
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, '='.
The series of pairs is separated by the ampersand, '&'.
While there is no definitive standard, most web frameworks allow multiple values to be
associated with a single field.
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.
W3C recommends 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.
The form content is only encoded in the URI'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.
Server-side image maps
URL encoding
Some characters cannot be part of a URL and some other characters have a special meaning
in a URL: for example, the character # can be used to further specify a subsection of
a document.
In HTML forms the character = 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.
The HTML specifies the following transformation: Characters that cannot be converted to the
correct charset are replaced with Numeric character references
SPACE is encoded as '+' or "%20" Letters, numbers and the characters '*','-','.' and
'_' are left as-is All other characters are encoded as %HH hex
representation with any non-ASCII characters first encoded as UTF-8
The octet corresponding to the tilde is permitted in query strings by RFC3986 but required to
be percent-encoded in HTML forms to "%7E".
The encoding of SPACE as '+' and the selection of "as-is" characters distinguishes this encoding
from RFC 3986.
Example If a form is embedded in an HTML page as follows:
and the user inserts the strings “this is a field” and “was it clear?”
in the two text fields and presses the submit button, the program test.cgi will receive
the following query string:
first=this+is+a+field&second=was+it+clear+%28already%29%3F
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.
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 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 unique string, such as e0a72cb2a2c7 is chosen, and the page is modified as follows:
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:
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 at the same web server by two independent paths, it will be assigned
two different query strings, while the stored cookies are the same.
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 cache thereby increasing the load on the web server and
slowing down the user experience.
Compatibility issues According to the HTTP specification:
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.
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 LimitRequestBody directive, which specifies
the number of bytes from 0 to 2147483647 that are allowed in a request body.
See also Clean URLs
Common Gateway Interface HTTP cookie
HyperText Transfer Protocol URI scheme
Web beacon References
External links RFC 3986