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.
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?
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 184.108.40.206 (talk • contribs) 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
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. 220.127.116.11 (talk) 21:41, 24 March 2008 (UTC)
Looks like http://www.w3.org/TR/html4/interact/forms.html#h-18.104.22.168 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. 22.214.171.124 (talk) 18:38, 25 January 2012 (UTC)
Encoding: Specification and Convention
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?
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:
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 (
/ ? : @ - . _ ~are left as-is
- All other ASCII characters are encoded as
The following rules are also adhered to by convention:
Of course, references would need to be added as required, and language improved. But would something like this be accepted by page maintainers?
Odd, RFC 3986 says
pchar = unreserved / pct-encoded / sub-delims / ":" / "@" query = *( pchar / "/" / "?" )
How about client-side uses?
- 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?
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 126.96.36.199 (talk) 15:30, 3 June 2008 (UTC)
This article gives the following example of multi-valued keys:
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:
No Equal Sign With Empty Value
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
Correct GET request?
I'm attempting to write a program that downloads files directly through sockets. It works alright on normal URLs but is giving weird results for query strings. For example if I had to download the page of "www.youtube.com/watch?v=wzodHBCqmtY" would this be the right request?
GET /watch?v=wzodHBCqmtY Host: www.youtube.com
Because this is giving 404 errors.
Please clarify this point. Cheers.