tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Looijmans, Mike" <>
Subject RE: AJP with HTTPD - Buffer Size on long URLs
Date Tue, 01 Dec 2009 07:30:45 GMT
I stand corrected.

What I do recall is that in the 1999's I was forced to build an HTTP/1.1
server from scratch (in objective-C) and, when faced with the question
"at what point in reading the URI should I give up and decide this is
not a HTTP request?", I found 4k to be the 'correct' answer. Since
RFC2068 was the basis for that server, I was lazy and assumef that
that's where it originated.

Anyway, when creating arbitrary long URIs, you can be sure that at some
point any HTTP server will give up, because it is more or less forced to
store the URI in precious RAM. Probably the 4k limit was intended as
"the maximum size you can expect a HTTP server to accept", anything
beyond that is "at your own peril".

The "SHOULD return 414" is easily explained: If it stops reading the
URL, it has no knowledge of the client's intended protocol yet, it is
not aware of the other headers in the request, and as such the server
may not be able to determine whether the client really expects a HTTP
response at all. So the safe thing to do is just close the connection
and give up.

Having said that, there is a very clear distinction between GET and POST
requests. The main difference is that POST requests in general have a
side-effect, and cannot be expected to return the same result twice. For
example, "POST /mything" might return "created a file" the first time,
and "file already exists" the second time.



> -----Original Message-----
> From: Caldarale, Charles R [] 
> Sent: maandag 30 november 2009 15:54
> To: Tomcat Users List
> Subject: RE: AJP with HTTPD - Buffer Size on long URLs
> > From: Looijmans, Mike []
> > 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.
>  - Chuck

This message and attachment(s) are intended solely for use by the addressee and may contain
information that is privileged, confidential or otherwise exempt from disclosure under applicable

If you are not the intended recipient or agent thereof responsible for delivering this message
to the intended recipient, you are hereby notified that any dissemination, distribution or
copying of this communication is strictly prohibited.

If you have received this communication in error, please notify the sender immediately by
telephone and with a 'reply' message.

Thank you for your co-operation.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message