tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Thomas <>
Subject Re: Tomcat 8.5.5 (8.5+) Default Cookie Processor breaks persistent cookies for all IE versions
Date Sat, 05 Nov 2016 22:58:36 GMT
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.)

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:

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.

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.


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

View raw message