tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cris Berneburg - US <>
Subject RE: tomcat on windows 2012 weirdness
Date Thu, 18 Dec 2014 17:22:01 GMT

Thanks for your response.  I was encouraged by your suggestion, thinking that setting would
be the magic solution to my problem.  :-)

I wrote a very simple filter to set the response header for "X-UA-Compatible: IE=edge".  However,
it did not solve the problem.  I could see in the IE developer tools that the name and value
were set.  But the request header User-Agent remained "Mozilla/4.0", and the still browser
would not accept cookies.

Turning off IE Compatibility Mode for intranet sites did boost the request header User-Agent
from "Mozilla/4.0" to "Mozilla/5.0", but the browser still would not accept cookies.

I have since found the source of the problem and the solution, which I will send in a follow-up

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

-----Original Message-----
From: Konstantin Preißer [] 
Sent: Wednesday, December 17, 2014 2:45 PM
To: 'Tomcat Users List'
Subject: RE: tomcat on windows 2012 weirdness


> -----Original Message-----
> From: Cris Berneburg - US []
> Sent: Wednesday, December 17, 2014 8:15 PM
> To: 'Tomcat Users List'
> Subject: RE: tomcat on windows 2012 weirdness
> 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.

Just some additional notes about IE (I don't know if they are applicable to your situation):

- IE displays "intranet sites" in "Compatibility mode" by default (that is, IE7 mode). This
is why I always add the following HTTP header to websites:
X-UA-Compatible: IE=edge

This will ensure IE always uses the latest document mode/level. Note that with this header
IE's browser mode can still be compatibility view (sending a Mozilla/4.0 MSIE 7.0 User-Agent)
although the document mode will be the latest (IE9 on IE9, IE11 on IE11 etc.)

The Developer Tools should show the current browser mode and document mode of IE.

- In IE on a Windows Server OS, for security reasons the IE enhanced security mode is active
which will block some content on websites in the "internet" security zone (while for intranet
sites it will use a lower security level). This mode can be enabled or disabled in the Server

Konstantin Preißer

View raw message