-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Mark,
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 catalina.properties?
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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJUkzRxAAoJEBzwKT+lPKRYQYYP/3eI8B2CIGvO3z2wxZqTxtq8
lPo1Qky4Kd8jqFnj8s4PUMB+/JixifsDcqYjQUFjD1i8HGSSHGE8bM6gDcgQHC5M
+qgz8K7pkqZ1IKbU7U/I4JDOvVHS7GPfD+SUWPB8shJIC/eLv+fbzmnOnsb5E5Eu
vO9iWmQs4yWfhja9uOjs3SEuhm+PKrA8xcIyyFWqpkMxLWk+26khtMpgHsDrBlRN
I75IdT1hflJ5L+3buXa6sRTTANn4IJtSP8XaV+pZshZKfPNMwJH3whJwt1d+cuH+
7rWEN0F5dJs5zl9kucFAwfWY8fdEYxKuJvO8hyJ8m33OA5veaalMHTOiXPzLaoC6
xfecsJKlhcWHMKgoed7bKknkiMJSaRPEWjkifR2ZdolFr+yo+HUuz85nPVcqgW89
W+/OVlq4wpDm+fMK6EOpKOH5CG6Am5/wKI4hfkl2cVlkQ/DAQ3/xy/m+TyvFOL3H
+rkUc6UZzF5KRuN3WhdpCIjFril1ExoR/4jgBmEZ806maX5rhbHazsGA8YIBXRY4
RnG3oUPiaJCBqIP+GcI98H57c22xQ6ez7tB5N3W5L2MPCgqZ4ebs1iNOBE4twypk
nY8ejtuViZaPjZie4hkaBg1I50Jymec+15KGFo00E2QY4/L1S7yL9Nj3o1a8odMd
u5W12FbVL07ShhLmrfvB
=lSJX
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
