Ameer (and Chris)

I discovered something else.  When accessing the internal web site by name, it 
does not work right.  But when I access the web site by IP address, it 
functions correctly!

> If you are using IE9, it has a very useful utility in its developer tool to 
> capture network traffic. Few simple steps to capture it:
> Press F12 --> Go to network tab--> start capturing You can save/export the 
> captured data in an xml file and then can see everything going to-and-fro 
> between your browser and server.

> Compare the traffic when you are communicating from localhost, which you say 
> is working fine, with the traffic when you are accessing from an outside 
> client.
> Pay special attention to the headers section of the HTTP calls.

Thanks for your suggestion.  I tried the IE9 Developer Tools trace, and it was 
revealing.  I noticed something strange.  Accessing the web server by IP, the 
User-Agent was "Mozilla/5.0", but by server name User-Agent was "Mozilla/4.0".  
There are other header differences too.  By IP has the session and cookie info, 
but by name does not - aha!  The "Accept" header was different also.

I interpret this to mean that my local IE browser thinks the intranet web site 
that I access either by name or by IP is actually 2 different sites in 2 
different security zones.  I will try to adjust my browser security settings 
and see if that makes any differences.

--
Cris Berneburg, Lead Software Engineer
CACI, IRMA Project, 703-679-5313


-----Original Message-----
From: Ameer Mawia [mailto:ameer.ma...@gmail.com] 
Sent: Friday, December 12, 2014 3:12 PM
To: Tomcat Users List
Subject: Re: tomcat on windows 2012 weirdness

On Sat, Dec 13, 2014 at 1:06 AM, Christopher Schultz < 
ch...@christopherschultz.net> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Cris,
>
> On 12/12/14 2:18 PM, Cris Berneburg - US wrote:
> > Hi Chris
> >
> > Thanks for your replies.  I am somewhat new to Tomcat, only been 
> > using it for 1 year, so some of the technical details are new to me.
> >
> >> Is it possible that you are not using URL-based session ids, and 
> >> that your browser has cookies disabled via a policy?
> >
> > I will need to check URL-based session ids.  How do I check?
>
> If your browser has cookies disabled, then all the links on the web 
> pages in this web application should have a ";jsessionid=[id]" path 
> parameter added to them. See below.
>
> > Also, my browser does not have cookies disabled.
>
> This is almost certainly the issue.
>
>
Chris, I think he meant cookies are already enabled on his browser.


> If your browser does not support cookies (Tomcat knows if you support 
> cookies if you send a JSESSIONID cookie, but it can't tell if you send 
> nothing), then the web application must fall-back to using URL-based 
> session-tracking.
>
> Unfortunately, this isn't entirely auto-magical: the web application 
> needs to support it properly. Most 3rd-party web applications should 
> already be doing things properly, but if you have an in-house 
> application, it may not be written properly.
>
> When emitting a URL onto a page for a client, the application needs to 
> run the URL through a call to HttpServletResponse.encodeURL(String) or 
> HttpServletResponse.encodeRedirectURL(String). These methods will add 
> the ";jsessionid=[id]" path parameter to the URL when the client does 
> not support cookies. In this way, session-tracking will still work.
>
> If the application isn't doing this for *every URL in the whole 
> application*, then sessions can be dropped and the user will have to 
> re-authenticate. If this is the case, you only have two options:
>
> 1. Re-enable cookies on your browser
> 2. Review the application and fix every instance of a URL on a page 
> (it's a huge job)
>
> >> Is the browser or the server (or both) on Windows 2012?
> >
> > The server is on Win 2012. It works OK when both the browser and 
> > server are the same 2012 VM. I don't know if it works when both 
> > client and server are both Win 2012 but different machines. I will 
> > be able to check that soon. It does not work with different client 
> > OS version and box than the server, but that may simply be 
> > coincidence.
>
> It may be a cookie policy: if localhost is trusted, the cookie policy 
> may change.
>
> >> Try using a protocol sniffer to see if the browser is sending a 
> >> session id to the server, and if the server is responding with a 
> >> session id either before or after login.
> >
> > Wow, that sounds intimidating - never done that before.  :-)
>
> It's worth learning how to do. I think there's a plug-in for MSIE 
> called IEHeaders (or something similar). Install that and you can 
> watch the conversation between client and server -- even when TLS is 
> being used.
>
>
If you are using IE9, it has a very useful utility in its developer tool to 
capture network traffic. Few simple steps to capture it:
Press F12 --> Go to network tab--> start capturing You can save/export the 
captured data in an xml file and then can see everything going to-and-fro 
between your browser and server.

Compare the traffic when you are communicating from localhost, which you say is 
working fine, with the traffic when you are accessing from an outside client.
Pay special attention to the headers section of the HTTP calls.

Hope that helps,
> - -chris
>
> > -----Original Message----- From: Christopher Schultz 
> > [mailto:ch...@christopherschultz.net] Sent: Thursday, December 11,
> > 2014 1:35 PM To: Tomcat Users List Subject: Re: tomcat on windows
> > 2012 weirdness
> >
> > Cris,
> >
> > On 12/11/14 12:41 PM, Christopher Schultz wrote:
> >> Cris,
> >
> >> On 12/11/14 11:28 AM, Cris Berneburg - US wrote:
> >>> I'm having trouble with my JSP web app using Tomcat 6 and 7 on  
> >>> Windows Server 2012.
> >
> >>> The issue is that no matter what file I request in the browser 
> >>> URL, it always returns the app welcome file, that is, the login 
> >>> page. Even when requesting an image.  The one exception is that 
> >>> after logging in, the main menu page appears, but none of the 
> >>> graphics or CSS files load.  Clicking on the app links, it just 
> >>> brings up the welcome page again.  Checking the Tomcat log files, 
> >>> I see that Tomcat is returning the welcome page instead of the 
> >>> files requested in the main menu page.
> >
> >>> Using the Tomcat manager, I see that my application has a 
> >>> ridiculous number of sessions, instead of just one.  I interpret 
> >>> that for every single file requested, a new Tomcat session is 
> >>> being generated and possibly invalidated.
> >
> >>> FYI, using the same setup on Windows Server 2003 and 2008 works 
> >>> fine. Opening the same firewall ports on all three OS's has been 
> >>> done. Even disabling the firewall on 2012 does not affect the 
> >>> issue in any way. And to make things even weirder, accessing the 
> >>> application from a browser on the server itself using localhost 
> >>> works fine!
> >
> >>> I wonder if there is some mystery setting somewhere that is 
> >>> crippling the app.  Got any suggestions?  Please help.
> >>> Thanks!
> >
> >> Check two quick things:
> >
> >> 1. Do you have any security-constraints in WEB-INF/web.xml? If so, 
> >> do they all make sense, and can users actually access those 
> >> resources once logged-in (or at all)?
> >
> >> 2. Do you have any servlets in WEB-INF/web.xml mapped to "/"
> >> other than the DefaultServlet (which should be configured by 
> >> default so you shouldn't have to configure it yourself)?
> >
> > After re-reading your post, it's pretty clear that my initial 
> > questions will be worthless and not help you.
> >
> > Is it possible that you are not using URL-based session ids, and 
> > that your browser has cookies disabled via a policy? Is the browser 
> > or the server (or both) on Windows 2012?
> >
> > Try using a protocol sniffer to see if the browser is sending a 
> > session id to the server, and if the server is responding with a 
> > session id either before or after login.
> >
> > -chris
> >
> >
> > --------------------------------------------------------------------
> > -
> >
> >
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> > For additional commands, e-mail: users-h...@tomcat.apache.org
> >
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
> Comment: GPGTools - http://gpgtools.org
>
> iQIcBAEBCAAGBQJUi0O5AAoJEBzwKT+lPKRY75IQAMAXlA67XF2xe6YZg+cZNdmF
> XYzYeijvh4GOclJJPYYSkrkvTdLUB49WHEVCH8U+zI8aNVXMLGoFj8WrD79gHNvI
> d7UBvd16blrJnYCArTpzk0UlhgD84mLNaVTpyrv8wD6Vqsky6B9lrk/sYl3J/lbr
> Tu/S2KxPektrd2JtqCsXCQefeniCOvGTbbWA5oEdEYMkwM7Q9DO5uwL+nRE0KgGr
> rp0//nbj3Fm+QsQ2Qm1CILUEQrh/ZT1IvEy/OON0wp/OSd0RwoWzBQna7+T7iP50
> Y3toyAyJ1IWj/jN45XWVoMBHZYBrSrka/rOw38Y2mygIthQkjI1N0/m14fvcJ0A5
> +YbRuZTdB785nFesOaNPCDPRjynxaHZUiG7FbiSGTZuVgKrVvP9T8l6ILfrgab9c
> O5PjBcyn6MQWlDWHCwvgFaNbfFpC8phUc0TZQ2x0eDP4/SYw1U1MBsWvS5iA6AP1
> ekWWb7BdJhydKSBId+hHsVDNNQfCVfKbc2QrbOkyDITc4XW04O/b1xWq2+KRwhzg
> ubZZNrj9KKWr/pUWx/g1pUlhpAUpSFOc5ltgcHi/BN9BPxylKezg1hYZzSXTEndg
> RbQXPkWBY6GRngVIRyjg1fp7IloPYgKnkbY6gkGTXw9sjG2XeeIuzdi1lGoZerk3
> TQ2uHb9ELH34ITqb+9oI
> =THku
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> 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

Reply via email to