What are the limits on a GET query string?

Giganews Newsgroups
Subject: What are the limits on a GET query string?
Posted by:  Alan J. Flavell (flave…@ph.gla.ac.uk)
Date: Sun, 11 Sep 2005

What are the theoretical and practical limits on the length
of a GET query string, currently?

Strange to say, I found this rather simple question hard to answer,
possibly because of searching the wrong terms, or, rather, because
the terms ("get", "form", "length" etc.) are so common as to be
useless for searching.

An email correspondent assures me that there's an RFC which limits the
length of a URI, including query string, to 1024 bytes, but he has
"forgotten" which RFC it was.  I have to say that the only relevant
reference I found was a statement that in (early) versions of HTML,
the "SGML declaration" limited the value of a URI reference to 1024
because this was the value of LITLEN - but in current versions of
HTML, LITLEN is set to 65k minus 1 - and that's presumably only for
formal reasons.

Worse, this correspondent claimed to have "proved" the claimed limit
in versions of MSIE and other browsers.  Well, a quick hack with MSIE
has demonstrated to me that there seems to be some kind of limit on
the length of individual submitted field values (or maybe the limit is
on the name=value combination?), at least, though it's /not/ at 1024.
I stopped there, rather than investigating how many more name=value
combinations I could add before hitting a limit, because I don't
really want to spend a lot of time challenging different browsers with
different length URLs to find where the limit is, if someone has done
it all before.

And, as I say, if there is any theoretical (e.g RFC-specified) limit
on a query string and/or on the whole URL, I'm interested in a cite.

Could anyone please direct me to any known resources on this topic?

(The particular context was the distress caused by idempotent
transactions which, on account of potentially long query strings, have
been designed to use POST instead: browsers get stroppy, and keep
throwing dialogs at the user to protect them from re-submitting this
potentially non-idempotent method.  Indeed my correspondent argued
eloquently that there ought to be a third method for forms submission
- one which used method POST, but was defined to be idempotent, and
thus free of re-submission protection mechanisms.  However, that's
another topic...)