Query string

A query string is an optional component string of a URI, used to provide a set of one or more parameter values. When a URI is submitted to a server in a request to access, or otherwise interact with, a resource, the server may adapt its response in relation to those parameters. showing a URL with a two-parameter query string of title=Query_string&action=edit |alt=An address bar on Google Chrome showing a URL with a two-parameter query string of "title=Query_string&action=edit"

A query string is an optional component string of a URI, used to provide a set of one or more parameter values. When a URI is submitted to a server in a request to access, or otherwise interact with, a resource, the server may adapt its response in relation to those parameters. showing a URL with a two-parameter query string of title=Query_string&action=edit |alt=An address bar on Google Chrome showing a URL with a two-parameter query string of "title=Query_string&action=edit"]] ==Purpose== The query string component is formally described in RFC 3986 (Uniform Resource Identifier (URI): Generic Syntax) as "containing data" serving a purpose, in combination with the path component, of identifying a resource, with path being of hierarchical nature and query string being non-hierarchical. Conventionally however, query strings are used for more than just refining resource identification, including communicating the nature of intended interaction; providing data to be utilised in an interaction; or asserting authorisation for the request. Any content returned in response to a request may thus be altered in some way in response to query string data. scheme ":" ["//" authority] path ["?" query] ["#" fragment] The structure of the query string is not well defined in the URI specification itself. Conventionally it consists of one or more key-value pairs, each usually in a key=value form, separated by a delimiter, usually an ampersand ( & ), as standardised in the likes of RFC 6068 for the mailto: scheme, and the HTML specifications for forms submitted as GET requests. An example URL with a single query string parameter: An example URL with multiple query string parameters and a fragment identifier: An example email link with query string parameters for pre-populating certain fields: Within each pair, the field name and value are separated by an equals sign, " = ". The series of pairs is separated by the ampersand, " & " (semicolons " ; " are not recommended by the W3C anymore, see below). While there is no definitive standard, most web frameworks allow multiple values to be associated with a single field (e.g. field1=value1&field1=value2&field2=value3 ). 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. 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. 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, ' + ' within browser URL percent encoding (which today, with the deprecation of indexed search, is all but redundant with %20 ). 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, ' = ' (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. 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. 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. SPACE is encoded as ' + ' or " %20 ". 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 references SPACE is encoded as ' + ' or ' %20 ' Letters ( A – Z and a – z ), numbers ( 0 – 9 ) and the characters ' ~ ',' - ',' . ' and ' _ ' are left as-is + is encoded by %2B All other characters are encoded as a %HH hexadecimal representation with any non-ASCII characters first encoded as UTF-8 (or other specified encoding) 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.

Text derived from https://en.wikipedia.org/w/index.php?oldid=1377904611 under CC BY-SA 4.0; modifications have been made.