Hi Michael, use LiveHttpHeaders to track all requests until you get your
"session" expired.
Then post the log from that here. You only posted one request, how can a
session expire for one request :) -> it can't
Filip
Michael Andreas Omerou wrote:
Dear all,
Thanks for your replies to my problem. However, I think the discussion has
been "diverted" into a debate totally irrelevant to the issue.
As far as Chuck's question whether this could be related to the popup, this
is not the case as the problem happens on other pages too, even on index.jsp
(first page)
Regarding Filip's email and monitoring HTTP Headers I am impressed that it
seems to work for you. I run FireFox on Windows XP Pro SP2 and what happens
is that when a page finishes loading, the session expires on the server.
When the user/browser requests another page the correct session id is sent
from the browser but the server detects that this session id sent is no more
valid (expired) and so we have a timeout. However, this behaviour, only
occurs with FireFox. I tried it from another PC with XP Pro SP2 too but
the problem is the same. With IE, NetScape and Opera all is ok.
I want to emphasize that this behaviour does not happen only when switching
from SSL to non-SSL or vice versa. Even if I try to access pages such as
the About Us or the Contact Us the session expires again. However, in that
case the problem is not "visible" to the user since those pages do not
contain any session specific data so even with a new session it is ok. Try
the following though and you will see what I mean. On tophotelchoices.com
do a search for a hotel. Let the results be displayed and then, go to the
About Us page. Then, click your browser's back button and instead of going
back to the search results you get a timeout (if you get search results it
will be from browser's cache, do a reload and you will get timeout).
Monitoring the HTTP headers for both IE and Firefox using HttpAnalyzer for
IE and LiveHttpHeaders for Firefox gives the following:
1) IE
(Request-Line):GET http://www.tophotelchoices.com/ HTTP/1.1
Accept:*/*
Accept-Language:en-gb
Accept-Encoding:gzip, deflate
User-Agent:Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR
1.1.4322; InfoPath.1)
Host:www.tophotelchoices.com
Proxy-Connection:Keep-Alive
Pragma:no-cache
Cookie:JSESSIONID=6F187E9E698F5D81A09DF6AD0D25115D
(Status-Line):HTTP/1.0 200 OK
Date:Thu, 16 Feb 2006 22:09:18 GMT
Server:Apache/1.3.33 (Unix) mod_jk/1.2.15
Cache-Control:no-cache
Pragma:no-cache
Expires:Wed, 31 Dec 1969 23:59:59 GMT
Content-Type:text/html;charset=UTF-8
X-Cache:MISS from proxy01.spidernet.net
X-Cache-Lookup:MISS from proxy01.spidernet.net:83
Proxy-Connection:close
2) FIREFOX:
GET http://www.tophotelchoices.com/index.jsp HTTP/1.1
Host: www.tophotelchoices.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.7.12)
Gecko/20050919 Firefox/1.0.7
Accept:
text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=
0.8,image/png,*/*;q=0.5
Accept-Language: en-gb,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Proxy-Connection: keep-alive
Referer: http://www.tophotelchoices.com/timeout.jsp
Cookie: JSESSIONID=3849A82D2F9B6991FE41073D771D1358
Cache-Control: max-age=0
HTTP/1.x 200 OK
Date: Thu, 16 Feb 2006 22:12:27 GMT
Server: Apache/1.3.33 (Unix) mod_jk/1.2.15
Cache-Control: no-cache
Pragma: no-cache
Expires: Wed, 31 Dec 1969 23:59:59 GMT
Content-Type: text/html;charset=UTF-8
X-Cache: MISS from proxy01.spidernet.net
X-Cache-Lookup: MISS from proxy01.spidernet.net:83
Proxy-Connection: close
Obviously, the response is the same in both cases, however, for FireFox the
important difference I see in Request is the one saying Cache-control:
max-age=0 and also, the Keep-Alive value 300. I do not think the Keep-Alive
value is the problem, however, the Cache-Control: max-age=0 is suspicious.
In my code I have response.setHeader("Cache-Control","no-cache") but I think
this is different. Does anyone have a clue what the max-age:0 is doing?
Your help will be greatly appreciated.
Thanks and regards,
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]