Ivo, thank you for this ... we've never had an issue with this before,
but we'll look into IE9 to see what the issue is. I am somewhat
confused by why it doesn't work, because we don't ACTUALLY set the
cookie itself, we rely on the underlying Servlet engine to do that for
us. That is part of the Servlet API to which the underlying engine
implements.
So ... i am somewhat intrigued to see if this is the same issue in Jetty.
The easiest thing you can do to see, is to simply telnet to the port and
issue the following commands:
GET / HTTP/1.1<cr>
<cr>
then look at the header coming back, that will tell us so much information.
as for the expires="never" ... yes, that is something that was always
set for a couple of years in advance.
So give us a shout once you know a little more Ivo. thanks
On 10/04/2012 13:46, Ivo Verbeek wrote:
I have a very nasty issue with CFCOOKIE, which sounds like somebody
else should have picked it up already. I can't believe this is a bug,
because it is so obvious. It seems like the expires="never" simply
doesn't work. Well, it works in Chrome and Firefox. In FF& Firebug I
can see that it sets a cookie with expiry date 1 year from now. I
thought "never" would in practice mean +30 years, but it seems like 1
year. But in Internet Explorer 9, it will always set the cookie
expiring "end-of-session". I can see in the F12-console that such is
what happens. And indeed, if I close my browser and re-open, the
cookie is gone. I have tried all kinds of settings with path, domain,
etc, but whatever I put in the expires attribute, in FF + Chrome it
works, in IE9 the cookie is expiring "end-of-session", always. I am
clueless. Why? Since this is IE9 only, I would expect that the way
openBD sets the cookie, is slightly off, which makes IE interprete it
as end-of-session. I even tried same code on Adobe CF9, there it works
(nice one also: on Adobe if you set path and not domain, it will give
an error, on openBD it does not).
I ran into more troubles with CFCOOKIE, but these issues I can work
around. Still, I will share.
- If you are behind reverse proxy setup, you will have to set the path
attribute. If you don't, it fails, it won't see the cookie. The moment
you put in path="/", it works. Might be logical, still remarkable,
because that path="/" is not where the app is on Tomcat.
- Setting the domain to .mydomain.com specifically while you are on
www.mydomain.com, won't work either. The end result is a cookie set
for domain .www.mydomain.com. Somewhere the "www" is put back in,
while I specifically removed it. This is in FF also, easy to check via
Firebug.
- J2EE sessions don't work in reverse proxy setup, because again the
cookies are set for wrong path. You will have to put output rules in
place for rewriting. Again: logical, but it took me some time to
figure out why J2EE sessions were not working and CFID/CFTOKEN was.
But in the end, the expires="never" doesn't work, which is the worst
one, because I need it for "keep me logged in" functionality. I tried
in both reverse proxy setup (openBD> Tomcat> Windows> IIS> ARR),
but also on Tomcat port 8080 directly. I haven't tried on either Jetty
or Tomcat running on port 80, which might work if I am right and the
problem is in the way the RESPONSE_Set-Cookie header is set. If
somebody has a good tool to monitor that, I will try and get to the
bottom of this :-)
Anybody has equal experience?
--
online documentation: http://openbd.org/manual/
google+ hints/tips: https://plus.google.com/115990347459711259462
http://groups.google.com/group/openbd?hl=en
