Hi Konstantin,
thanks for you answer.
Am 08.07.2014 10:22, schrieb Konstantin Kolinko:
2014-07-08 11:48 GMT+04:00 Simon Kulessa <kule...@flexsecure.de>:
Hi,
we are running a server on Apache Tomcat 7.0.29 with usage of the
servlet-api 3.0.1.
1. The current version is 7.0.54
We updated to this version now, but since our server is already running
at the customer
exchanging the tomcat might not be a option for now.
Before we can do this, we should at least have an idea about where the
problem is coming from.
2. What is "3.0.1". You may use any servlet-api jar when compiling,
but at run time you must use the one that comes with Tomcat.
Ok. So correct would be we compile against the servlet-api 3.0.1 (maven
dependecy groupId=javax.servlet, artifactId=javax.servlet-api)
and use the one from tomcat in production. The tomcat version seems to
provide a different version 3.0.FR (taken from the manifest).
Could this be an issue?
From one of our customers we received a bug report that in certain times an
IOException (Stream is closed)
is thrown while reading the data from a HttpServletRequest.
After some investigation we added some logging and now we see the following
information:
First we logged the headers of the http request (by using
HttpServletRequest#getHeaders()) and
we see a JSESSIONID cookie with a value of 'A'.
After this we use HttpServletRequest#getCookies() to log the cookies as
well.
Here we only see a JSESSIONID cookie with a value of 'B'.
The requested sessionId from the servletRequest has value 'A' as well.
My question is: How can this be?
How is it possible that getCookies returns a cookie that is not defined in
the header of the http request?
Where does this cookie come from? And were did the cookie go that was
defined in the header?
3. Usually that is caused by bad programming in a web application,
when newbie programmers share "request" object between requests. The
unexpected "Stream is closed" issues are also symptoms of that.
An example:
http://markmail.org/thread/pxh6bk6saowy3rk6
Currently I see nothing in our code that indicates this, but I will have
another look at that,
since this seems to be the most likely explanation.
4. I think getHeaders() may return some garbage for Cookie header (as
the value may be corrupted when parsing the value into a cookie), but
it should not contain a value from different user.
Currently I can not verify whether the cookie value of 'B' is linked to
some other user
(I am still missing some log files from the previous days).
For now I can only say it does not seem to be the case, that the cookie
value is linked
to another user.
What I can see is that the problem seems to be reoccurring. All the
requests were
the Exception actually happens are being send from the same IP. The
cookie value in
the header is always different, while the cookie value returned from
getCookies() is
always the same.
5. A browser may send several JSESSIONID cookies in the same request.
Yes, but in this case there should be multiple cookies returned by the
getHeaders() and getCookies()
method. Currently there is only one in each.
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
