On 07/11/2016 18:41, Rémy Maucherat wrote: > 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,
Tempting. But IE/Edge represents ~30% of the current browser usage. If we were talking about a browser will a much smaller - and shrinking - market share I could be convinced. > 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). It was configurable before because a strict reading of RFC2109 is that it should not be there. RFC6265 allows both so there is no spec compliance reason to not send it. The only thing against not always sending it is the time taken to compute it and the bytes required to send it. However, given the number of end users this is likely to impact, I don't see much point in making it optional (it will only get sent on cookie creation/update and then only if max age is set). Mark --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
