Talk:Query string

message: I share Jidanni's concern, but need to be expand on it:
The current version of the Query_string#URL encoding section lacks a reference for the given query string rules.  Would explicitly distinguishing between specification and convention be helpful here?
The current HTTP 1.1 URI Specification still references the Query String definition given in rfc3986. 
The full grammar for this definition can be taken from Appendix A of the same spec and the core rules for ABNF Grammars in rfc3986:
   query        = *( pchar / "/" / "?" )
   pchar        = unreserved / pct-encoded / sub-delims / ":" / "@"
   unreserved   = ALPHA / DIGIT / "-" / "." / "_" / "~"
   pct-encoded  = "%" HEXDIG HEXDIG
   sub-delims   = "!" / "$" / "&" / "'" / "(" / ")" / "*" / "+" / "," / ";" / "="
   HEXDIG       = DIGIT / "A" / "B" / "C" / "D" / "E" / "F"
   ALPHA        = %x41-5A / %x61-7A   ; A-Z / a-z
   DIGIT        = %x30-39   ; 0-9
This grammar does not match the current textual description given in the URL encoding section:
In particular, encoding the query string uses the following rules:
* Letters (A–Z and a–z), numbers (0–9) and the characters '.','-','~' and '_' are left as-is
* SPACE is encoded as '+' or "%20"  
* All other characters are encoded as %HH hex representation with any non-ASCII characters first encoded as UTF-8 (or other specified encoding)
The following rule description would match the specification and distinguish between spec and convention:
In particular, encoding the query string uses the following rules:
* The characters (A–Z and a–z),  (0–9) and / ? : @ - . _ ~ are left as-is
* All other ASCII characters are encoded as %HH hex representation
The following rules are also adhered to by convention:
* The use of & and = to seperate parameters and key-value pairs as described for #Web forms is used for non-form parameters as well
* SPACE can be encoded as '+' or "%20"  
* All non-ascii ASCII characters are encoded as %HH hex representation by first encoding as UTF-8 (or other specified encoding)
Of course, references would need to be added as required, and language improved. But would something like this be accepted by page maintainers?
Sam (talk) 13:01, 25 July 2014 (UTC)
thread_title:  Encoding: Specification and Convention 

message: Odd, RFC 3986 says
   pchar         = unreserved / pct-encoded / sub-delims / ":" / "@"
   query         = *( pchar / "/" / "?" )
so why isn't e.g., "@" mentioned as OK? Jidanni (talk) 06:21, 19 January 2012 (UTC)
thread_title:  @ etc.

message: Although the primary use of the query string is to pass info to the server, there are also client-side uses. I am doing some work that involves reading and setting the query string in Javascript, accessed via "location.search", but because my expertise in this area is very limited, I don't feel qualified to add anything to the topic in Wikipedia. Hopefully someone with some expertise in the area can add a bit on the topic.
:Unlike PHP and other server side scripting languages, JavaScript does not support access to query string parameters directly.
:A nice and compact function for getting query string parameters from within JavaScript is described in this blog: http://www.netlobo.com/url_query_string_javascript.html. That script parses window.location.href.
:I'm not sure what you mean by setting the query string. Setting an existing query string is as useless as it is impossible (it would mean you're trying to change a http request that occurred in the past). Of course you can change values that came from the query string, but that's trivial, you can do that in local variables. If you're talking about preparing a query string for a new http request; that's trivial too, a matter of string concatenation.
:Jaho (talk) 03:15, 9 January 2011 (UTC)
thread_title: How about client-side uses?

message: Query string is often used in databases and information retrieval system, and the meaning is a string that encodes a query that was entered by the user or was automatically constructed by some engine.  —Preceding unsigned comment added by 83.149.198.98 (talk) 15:30, 3 June 2008 (UTC)
thread_title:  How about adding a disambiguation page for this article? 

message: This article gives the following example of multi-valued keys:
:field1=value1&field1=value2&field1=value3...
But does not touch upon the important fact that in this format PHP (and other platforms?) will only read the last assigned value for field1. In order to get PHP to recognize multi-value keys (i.e. arrays in a query string), the format should be as follows:
:field1[]=value1&field1[]=value2&field1[]=value3...
My answer on http://stackoverflow.com/a/9547490/165673  deals with this  — Preceding unsigned comment added by Ykessler (talk • contribs) 16:23, 3 March 2012 (UTC)
thread_title:  Multi-value keys 

message: The article states "The equals sign may be omitted if the value is an empty string." but I could not find any infomation about this in http://www.w3.org/TR/2011/WD-html5-20110525/association-of-controls-and-forms.html#url-encoded-form-data
I am sure the article is correct but does anyone have a citation?  — Preceding unsigned comment added by Teambob (talk • contribs) 10:58, 21 December 2012 (UTC)
thread_title:  No Equal Sign With Empty Value 

message: Too bad WP is not a discussion forum. I would then be able to suggest the following: why not use a question mark not only to introduce a query, but also to separate each assignment in the query? That reduces the characters that need to be escaped if they are to appear in an assignment by one, and makes parsing the query, when needed, easier. David Spector (talk) 13:03, 9 October 2018 (UTC)
thread_title:  Question mark separator