tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ronald Klop <>
Subject Re: POST request with timeout acts weird
Date Mon, 05 Oct 2009 12:23:47 GMT

Op zondag, 4 oktober 2009 22:23 schreef Christopher Schultz <>:
> Ronald,
> On 10/2/2009 9:20 AM, Ronald Klop wrote:
> > But I don't send any data. My servlet than waits in getParameterMap(),
> > because that try's to read the inputstream and parse the parameters.
> > After 20 seconds (Connector has connectionTimeout="20000") the reading
> > of the inputstream ends, but my application just gets an empty Map in
> > stead of some TimeoutException.
> What leads you to believe that a TimeoutException would be thrown? The
> documentation for the HTTP connector's "connectionTimeout" attribute says:
> "
> The number of milliseconds this Connector will wait, after accepting a
> connection, for the request URI line to be presented. The default value
> is 60000 (i.e. 60 seconds).
> "
> You provided the URI line within plenty of time. If you didn't enter
> anything, Tomcat would disconnect. Since you did, it doesn't.
> > Why? And how should I handle this?
> Honestly, I'm not sure if there's a way to check to see if all bytes
> advertised in Content-Length were actually consumed by a request.
> > (The real problem is that IE has some issue's and that some of my
> > customers sometimes send synchronous ajax calls which don't send any
> > data. I'm investigating that too. If somebody has a tip about that it is
> > also appreciated.)
> Technically speaking, the HTTP spec does not require the Content-Length
> to be correct(!). I think this is something that your webapp is just
> going to have to tolerate.
> Perhaps you could add a parameter to all your requests like 'last=true'
> and always make that the last parameter submitted. If the last parameter
> has the value "true" then the POST was sane. Otherwise, reject the
> request. Just a thought.
> - -chris

There is even more fun about the documentation of connectionTimeout. It states that it waits
for the URI after accepting the connection, but in my example Tomcat is not waiting for the
URI, but for data from the request. So connectionTimeout does much more than what is mentioned
in the documentation.

I know about the issue of interpreting the Content-Length in comination with charsets and
Content-Encoding and Transfer-Encoding.

But I guess Tomcat does something like this.
Socket s = ...;
InputStream in = s.getInputStream();
try {;
} catch (SocketTimeoutException e) {
   // Ignore and give (part of the) data to the Servlet, because the specs of getParameter(...)
gives us no room for bubbling up this exception.

I will verify if this is correct in the code, but I hope to illustrate what I puzzled by.
I can't handle this situation without workarounds, while the problem is so simple.
I think the lazy evaluation of the POST parameters in Tomcat is making it very difficult to
give good errors. But don't take this wrong. I'm not telling that the advantages of lazy evalution
are bigger of smaller.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message