Hi Chris, I apologise in advance if the formatting is absolutely terrible.
>Are you using cookies for session-tracking? >Can you watch the HTTP conversation to see what's being sent back and forth >during that workflow? LiveHttpHeaders is great for Firefox, and these days >Chrome, Firefox, and IE have something similar built-into them. >From the looks of it, the cookie is storing the session ID. Server - nginx/1.6.2 (Ubuntu) Date - Fri, 30 Jan 2015 15:52:35 GMT Content-Type - text/html;charset=utf-8 Transfer-Encoding - chunked Connection - keep-alive Cache-Control - no-cache, no-store, must-revalidate, max-age=0 X-XSS-Protection - 1; mode=block x-content-type-options - nosniff x-frame-options - SAMEORIGIN Set-Cookie - ib=da7f36e0f53827383a262940d2f75fcef8bbb32b57bd3fced7149ae6a8bf4e3a; path=/; expires=Fri, 30 Jan 2015 15:57:35 -0000; HttpOnly Content-Encoding - gzip Everything in the HTTP requests seem fine, except the response from my POST at the Challenge point, where, instead of a 200, I'm receiving a 302. This is what tipped me off that it was the session that was causing the issue. >You might want a fully-qualified host name in the host's "name" >field... or at least whatever your clients DNS will resolve to your server. >That may actually be "virtual1" but I just thought I'd mention it. It >shouldn't have any >bearing on the session-handling, unless your web >application switches hostnames by telling a client requesting "virtual1" >that it should redirect to >"testsitex.site.io" or vice-versa. I went ahead and changed this as well, as it does seem like a good practice to use. Kind Regards, Rory --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
