Talk:Query string

From Wikipedia, the free encyclopedia
Jump to: navigation, search

Sessions[edit]

It would be nice to have an expert's assessment of query strings as an alternative to session-based cookies. Cookie opponents often recommend query strings as a viable, if not superior, alternative, but rarely mention their disadvantages. Perhaps this assessment could provide a basis for a "Criticisms" paragraph in the Wikipedia entry for query strings. Thank you.

HTTP cookie[edit]

I have submitted the article HTTP cookie for peer review (I am posting this notice here as this article is related). Comments are welcome here: Wikipedia:Peer review/HTTP cookie/archive1. Thanks. - Liberatore(T) 16:57, 14 January 2006 (UTC)


Query String: size limit?[edit]

It would seem that there might be a size limit on the query string. If there is, what is it? If there is or is not a limit it should be stated in this article. I, however, do not have this knowledge. —Preceding unsigned comment added by 66.25.155.9 (talkcontribs) 04:16, 19 June 2005

I think there is a limit on the total lenght of the URL, not on the query string itself. Tizio, Caio, Sempronio 16:19, 6 October 2006 (UTC)
There is no standard limit on either the length of a query-part or the length of a URL or URI; however, some clients, proxies, and servers have implementation limits. From RFC 2616, section 3.2.1 (General Syntax):
The HTTP protocol does not place any a priori limit on the length of a URI. Servers MUST be able to handle the URI of any resource they serve, and SHOULD be able to handle URIs of unbounded length if they provide GET-based forms that could generate such URIs. A server SHOULD return 414 (Request-URI Too Long) status if a URI is longer than the server can handle (see section 10.4.15).
Note: Servers ought to be cautious about depending on URI lengths above 255 bytes, because some older client or proxy implementations might not properly support these lengths.
So no, there's no hard limit, just a recommendation to keep the overall URI under a reasonable size to deal with legacy code, and a mechanism for a server to notify a client that it loses because of an oversized URI. Bear in mind, though, that this spec is (in 2008) going on a decade old, so it's a bit conservative by modern standards. For example, it's not hard to get Google Maps to generate a URL with a query string that pushes the 500-byte mark.Tlesher (talk) 00:50, 15 January 2008 (UTC)
About a practical size limit: Apache web server by default accepts URLs slightly over 8000 bytes, but this limit can be changed in httpd.conf. Long requests that I find in my logfiles are invariably buffer overflow attempts, so I guess many server administrators will have considerably lowered the limit. That would mean all we can say about a practical size limit is that it varies wildly. Jaho (talk) 03:18, 13 January 2011 (UTC)

encoding: + for space[edit]

I came here hoping to find something more definitive about the use of + for space. It does seem to be an exception (as the article does already state) to the generic URI rules of RFC 3986. But I'm wishing for something more definitive about the actual scope of the exception (an RFC citation would be ideal). A colleague of mine was just bitten by this exact issue (a mailto: URI can have a portion set off by ? and resembling a query string, but is defined by RFC 2368 with no special meaning for +, so %20 has to be used) which is what started me looking. So does the + exception apply only to particular schemes, such as http or https? Is there an RFC that says so? The only one I have found is RFC 1630, but that's worded more like an early proposal for a generic syntax where + would apply in any scheme (and therefore would seem to conflict with RFC 3986 and the later scheme-specific RFCs). Also, 1630 isn't mentioned at all in rfc-editor's set of obsoletes and updates related to RFC 1738, 3986, etc. which makes it hard to see exactly where 1630 does (or doesn't) fit in the scheme of things. I hoped to find a later RFC that cites it and restates the +-for-space rule with a specific scope for where it applies, but I didn't (which needn't mean it doesn't exist). This turned out a lot more subtle than I expected, and if anybody actually knows the right RFCs to pin it down, it would be a good addition to the article. 128.210.4.214 (talk) 21:41, 24 March 2008 (UTC)

Looks like http://www.w3.org/TR/html4/interact/forms.html#h-17.13.4.1 has the goods. The later RFCs say simply that "+" is a reserved character and should be encoded if encountered, and give no guidance about how it is to be interpreted. 99.241.46.234 (talk) 18:38, 25 January 2012 (UTC)

Encoding: Specification and Convention[edit]

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 (AZ and az), numbers (09) and the characters '.','-','~' and '_' are left as-is
  • SPACE is encoded as '+' or "%20" [1]
  • 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 (AZ and az), (09) 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" [2]
  • 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)

@ etc.[edit]

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)

Could it be that the authors' attention is not focused on the query string part of the RFC? Jidanni (talk) 01:54, 20 January 2012 (UTC)

How about client-side uses?[edit]

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)

How about adding a disambiguation page for this article?[edit]

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)

Multi-value keys[edit]

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 (talkcontribs) 16:23, 3 March 2012 (UTC)

No Equal Sign With Empty Value[edit]

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 (talkcontribs) 10:58, 21 December 2012 (UTC)

  1. ^ "HTML URL Encoding Reference". W3Schools. Retrieved 3/1/2013. 
  2. ^ "HTML URL Encoding Reference". W3Schools. Retrieved 3/1/2013.