2016-11-05 23:58 GMT+01:00 Mark Thomas <ma...@apache.org>: > 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: > 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. > > 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. > > I don't understand, this is the same as the alwaysAddExpires field in LegacyCookieProcessor. IMO, it's a very good time to kill off IE support (HTTP/2, etc) in the default configuration, so it's not worth restoring this in your new cookie processor. If you do still want to restore it, it should use the same default value (based on the strict compliance flag).
Rémy
