tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Mayr <>
Subject Re: Tomcat 8.5.5 (8.5+) Default Cookie Processor breaks persistent cookies for all IE versions
Date Sun, 06 Nov 2016 09:31:31 GMT
Am 05.11.2016 um 23:58 schrieb Mark Thomas:
> On 04/11/2016 19:10, Hedrick, Brooke - 43 wrote:
>> Sorry if this has been already asked.   I searched the archives and
>> didn't find what I was looking for.
> I don't recall anyone raising it before now.
>> Has anyone else run into an issue with persistent cookies in Tomcat
>> 8.5+ and IE not working?
> I can confirm I see the same issue.
>> Does it make sense that the shipping configuration would not work
>> with IE for persistent cookies?
> I'll turn that around. The shipping Tomcat configuration is RFC 6265
> compliant. Does it make sense that Microsoft would ship multiple
> versions of their browser for over a decade and fail to correctly
> implement any of the cookie specifications that were considered current
> throughout that period? (IE's cookie support is a sore point for me - I
> have been dealing with IE's spec non-compliance for almost as long as I
> have been working on Tomcat and it has always been unpleasant.)

When I read
and the last response to
from the Microsoft Edge Team I fear full RFC6265 support is still some
years away in Microsoft world

> The default Tomcat community position in cases like this is that we do
> not implement workarounds for bugs in third-party code. You need to
> raise a bug with the provider of the buggy code.
> We do make exceptions and they are typically for IE. Part of me thinks
> that if everyone refused to work-around Microsoft's poor implementations
> of various standards (WebDAV is another area that comes to mind) a)
> people would see just how bad some Microsoft code really is and b)
> Microsoft might come under pressure to actually fix it.
> While we could make a stand on this particular point, I suspect that
> Microsoft won't even notice and all it will do is make life difficult
> for our users. As annoyed as I am with Microsoft about this, making life
> difficult for Tomcat users is not what this community is about. As much
> as it pains me to say it, I think we are going to have to work around this.
> Maybe an new option:
> enableWorkaroundForBrokenMicrosoftCookieHandling
> Seriously, we need to decide if this needs to be configurable or not.
> Given that RFC6265 allows both expires and max-age to be sent and the
> the legacy processor sends both by default I'm currently leaning towards
> just sending both in the RFC6265 processor.

+1 sending both headers

Assume the following: people upgrade Tomcat and the app stops working in
IE (most corporate users default browser). They will blame Tomcat - not
IE. Why should we risk to damage Tomcats reputation if sending both
headers is still standards compliant? This "hack" seems quite acceptable
for me. Adding a configuration option for a "strict" mode would make it
easier to test future browser implementations with real applications.

> Assuming no-one objects, I'll aim to get this fixed for the next release
> (not the one currently in progress but the one expected early next month).
> We also need to update the note in the docs about IE versions.
> Mark
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:


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

View raw message