So you're saying that you've seen Tomcat *not* rewrite URLs in a response to a first request from a client that *does* support cookies, and *does* rewrite the URLs in a response to a first request from a client that doesn't support cookies? That would indeed be very powerful software.
Tomcat needs at least one request/response cycle to be able to determine if cookies are enabled or not; which it does on the subsequent request/response cycle. Your request comes in. You have no cookie (either because you don't allow them, or it's your first visit this session) Tomcat responds with a session cookie, and if you've run URLs through that method, URLs are rewritten too. The next time you request something, your browser sends back the cookie (if you allowed the cookie). Tomcat sees this cookie, and then stops rewriting URLs. If your browser doesn't send back a cookie with the next request, the method continues to rewrite URLs. My only doubt is: Does it continue to also send the cookie in a 'faint hope' that it might one day be accepted? This could be easily investigated with liveheaders in firefox. Come to think of it, liveheaders would help you confirm what I've just said. ;) Mike Curwen > -----Original Message----- > From: Harry Mantheakis [mailto:[EMAIL PROTECTED] > Sent: Thursday, January 27, 2005 10:12 AM > To: Tomcat Users List > Subject: Re: How does Tomcat know that a browser supports cookies? > > > I understand what you are saying, Javier, if you have a > round-trip situation, where you set cookies in one response, > and then test for them in a follow-up request. > > But I'm not convinced that's how Tomcat does it. > > The first time a client connects to a server, there will not > be any cookies, session or otherwise, for the client browser > to send to the server - but Tomcat can still figure out > whether or not cookies are enabled in the client browser. > > At least, that seems to be the case with my application: > Tomcat automatically decides whether or not to apply URL > rewriting if I call the > HttpServletResponse.encodeURL() method. > > I wonder if anyone here knows for sure? > > Regards > > Harry > > > > I use a HttpSession object. > > > > HttpSession object = null; > > > > When user access to site, i use: > > > > object = request.getSession(); > > > > later i use: > > > > boolean n = object.isNew(); > > > > if n = true, then user is not using cookies. > > > > I suppose that tomcat is using Session Cookies and not re-writting > > politic.. > > > > because, tomcat keep session with user using cookies, so.. > if session > > is new mean that user is new for tomcat, because it can't > send cookie. > > > > regards.. > > > > Javier > > > > At 10:12 27-01-2005 +0000, you wrote: > >> The API for the HttpServletResponse.encodeURL() method states that > >> "the implementation of this method includes the logic to determine > >> whether the session ID needs to be encoded in the URL". > >> > >> How does Tomcat know whether or not a browser supports cookies, or > >> session tracking is turned off? > >> > >> Is it simply a case of looking for the presence of a > "Cookie:" header > >> in the request, and assuming that cookies are enabled if > the header > >> is found? > >> > >> And if that is the case, would I be correct in assuming > that browsers > >> (when permitted by their users) will set "Cookie:" headers > in their > >> requests even if they do NOT actually have any (previously set) > >> cookies to send back to the server? > >> > >> I'm just guessing, of course - and I know I should not generalise > >> about > >> browsers: I'm thinking of IE, Mozilla/Firefox and Opera. > >> > >> TIA > >> > >> Harry Mantheakis > >> > >> > >> > --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > >> For additional commands, e-mail: > [EMAIL PROTECTED] > > > > Javier Villalobos Arancibia > > Ing. Civ. Electrónico > > ImageMaker Information Technology > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
