tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
Subject Re: tomcat on windows 2012 weirdness
Date Thu, 18 Dec 2014 20:09:21 GMT
Hash: SHA256


On 12/18/14 1:31 PM, Mark Eggers wrote:
> Chris,
> On 12/18/2014 9:42 AM, Christopher Schultz wrote:
>> Cris,
>> On 12/18/14 12:22 PM, Cris Berneburg - US wrote:
>>> Chris
>>> cb> I interpret this to mean that my local IE browser thinks
>>> the cb> intranet web site that I access either by name or by IP
>>> is actually cb> 2 different sites in 2 different security
>>> zones.  I will try to cb> adjust my browser security settings
>>> and see if that makes any differences.
>>> cs> That sounds plausible. If IE changes its cookie policy
>>> based upon those zones, then you may have found the issue. I
>>> wonder if your local policy whitelists a certain IP range but
>>> doesn't use hostnames, which may account for the difference.
>>> 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 message.
>> Looking forward to it.
>>> cs> Time to ask your webapp software vendor to fix their web 
>>> application cs> so it can be used without cookies ;)
>>> Ouch!  I *am* the software developer for this web application. 
>>> :-)
>> Well, the good news is that there's a chance it'll get done. 
>> Sometimes 3rd-party vendors will just say "sorry, we simply
>> don't support that configuration; use a supported configuration"
>> which is a lousy answer IMO.
>> You can also fix the application as you go; you don't have to do 
>> 100% of it all at once... nobody has noticed before, so nobody
>> will notice if you do 10% of it and then sit on it for a while.
>> There's no better time to start fixing your URLs than now, so 
>> every time you have to edit a HTML template, just fix the URLs
>> in that file. Here's the recipe you want:
>> Change
>> <a href="/foo/bar">...</a>
>> to
>> <a href="<%= request.getContextPath() + 
>> response.encodeURL("/foo/bar") %>">...</a>
>> Better yet, use JSTL:
> Won't you need:
> <a href="<c:url value='/foo/bar'/>">...</a>
> instead of
>> <a href="<c:url value="/foo/bar"/>">...</a>
> unless you set
> org.apache.jasper.compiler.Parser.STRICT_QUOTE_ESCAPING=false
> in

Good question. I wouldn't think it would matter since the <a href=
should be ignored and the <c:url> should be compiled, but it might
matter if you are using .jsp versus .jspx.

I try to avoid JSP as much as possible, so I'm not a good judge ;)

- -chris
Version: GnuPG v1
Comment: GPGTools -


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message