Caldarale, Charles R wrote:
From: Looijmans, Mike [mailto:mike.looijm...@oce.com]
Subject: RE: AJP with HTTPD - Buffer Size on long URLs
Looijmans, Mike wrote:
The RFC specs a maximum URL size of 4k.
Where precisely did you find that ?
RFC2068 (old HTTP/1.1 spec)
Citing an obsoleted RFC is a bit odd. Regardless, the actual wording from
section 3.2.1 of 2068 and 2616 (the superseding document) is:
"The HTTP protocol does not place any a priori limit on the length of a URI."
Followed shortly by:
"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 the SHOULD, not MUST.)
There is also a warning note:
"Note: Servers should be cautious about depending on URI lengths above 255 bytes,
because some older client or proxy implementations may not properly support these
lengths."
No mention of a 4K limit anywhere that I can find.
Right. +1.
My point here (toward Mike) was that one should avoid propagating rumors
or incorrect information, on a list that is read by unsuspecting users
which may then believe that this is the ultimate truth.
This being said, the specs do not set a specific limit to a URI length,
but it is certain that any server software has a practical one, if only
to avoid some types of DoS attacks.
So my point to the original poster, was to recommend the use of a POST
rather than a GET, if the application is such that it already now
exceeds 8K for a URI.
In addition, even if one knows how many individual input fields there
may be in a form which sends such a URI, and how long each field is in
principle, it is much harder to predict how long a URI this will
actually generate once URI-escaping has taken place, and each non-ASCII
character has been replaced by a triplet of bytes.
There is no such arbitrary limit (or if there is, it is MUCH higher) for
the body of a POST.
In addition, at least for the body of a POST, there is a possibility of
indicating the character set of the data, which in fact there is not for
data contained in a URI.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
