Re: Tomcat 8.5.5 (8.5+) Default Cookie Processor breaks persistent cookies for all IE versions
2016-11-10 16:02 GMT+01:00 Christopher Schultz : > http://mrcoles.com/media/test/cookies-max-age-vs-expires.html > > Just tested with Edge and MSIE11 on Win 10. Both fail to recognize the > expiration of a cookie when "expires" is not set and only max-age is set > . > > Perhaps it behaves differently in "Trusted domains" or something like > that. > > No idea about the domain. I went to test on Windows, and verified it doesn't work without expires. So the link I posted had bad information, and it's difficult to find something for IEs newer than 8. Rémy
Re: Tomcat 8.5.5 (8.5+) Default Cookie Processor breaks persistent cookies for all IE versions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Rémy, On 11/10/16 8:38 AM, Rémy Maucherat wrote: > 2016-11-10 11:51 GMT+01:00 Mark Thomas : > >> 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. >> > > http://promincproductions.com/blog/set-cookie-expiration-date-browser- compatiability/ > > There's really conflicting info on this ... http://mrcoles.com/media/test/cookies-max-age-vs-expires.html Just tested with Edge and MSIE11 on Win 10. Both fail to recognize the expiration of a cookie when "expires" is not set and only max-age is set . Perhaps it behaves differently in "Trusted domains" or something like that. - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJYJIwgAAoJEBzwKT+lPKRYbK8QALku/KtGcwQ3ezSxhoqYaZfV XiHgCVgjZ+nujAb9aOvcrQCCkOkrmsXggOWmNm/c8m2g+Hfxh+mbFSuujsHvO9wa k586b4mSZYo+uyzl2t3WRGOZ8tQTK7oGbUahlArrfUCGOt58VKb9Cn2yut9U8YV3 EmblFE81aeDZJ1HAurrj+0japBFqjyNCxYXXlC4v7IyE/a8tgAM77neTGbpC8br9 YPC5BajXnNVNlCGKfgc2LraBI9JH4rgxpulnyFL9aZhJsL8vpE94BGRRx6aXN2OM 3Kxysn/U8O5ODOlnbdGJpR8bUIRZHrfWxDyHWxQLLE8CVbhUgDZPQWeqo+y+SHpi YueZ/4HYZna5SJxCDHC8rhMz1gdtw73a/DZ8aB7bQ5koXQNeyTA/4IYdiAUBkQs3 pL63HP4dO6AYUxyw1J71BF3zfAY6ydNGolgY/tc6YzQy7UW8BDaL/lurzOVPliq+ Vn9m+JvRN/I1AKJ7Stqp5Sb0eUfSpMVdDwZvNnJ+5p2q7K6C7jHxKMgjNDWksJme 9ioJumixJ15zqil3QjQAKuDhkx14xmCJFumS0No8IVwW2oUuLOF/dDUBPXv/q1FC b/q9XLbFFe2Jks3Q3Pm7Mnu0BUJjQdm9qE8mof+OY7E94E+f1ys1QSiCHB5ZRjIi bMICCb1Ox8JeYXJTTXLQ =IcwU -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 8.5.5 (8.5+) Default Cookie Processor breaks persistent cookies for all IE versions
2016-11-10 11:51 GMT+01:00 Mark Thomas : > 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. > http://promincproductions.com/blog/set-cookie-expiration-date-browser-compatiability/ There's really conflicting info on this ... Rémy
Re: Tomcat 8.5.5 (8.5+) Default Cookie Processor breaks persistent cookies for all IE versions
On 07/11/2016 18:41, Rémy Maucherat wrote: > 2016-11-05 23:58 GMT+01:00 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.) >> >> 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
Re: Tomcat 8.5.5 (8.5+) Default Cookie Processor breaks persistent cookies for all IE versions
2016-11-05 23:58 GMT+01:00 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.) > > 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
RE: Tomcat 8.5.5 (8.5+) Default Cookie Processor breaks persistent cookies for all IE versions
Thanks Mark and everyone else. I appreciate all of the sentiments. It is very annoying that MS can't get on the bus for something like this, even in Edge. But as you said IE remains the default corporate browser on Windows. I appreciate your working on this. Brooke Hedrick -Original Message- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Sent: Monday, November 07, 2016 9:25 AM To: Tomcat Users List Subject: Re: Tomcat 8.5.5 (8.5+) Default Cookie Processor breaks persistent cookies for all IE versions -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Stefan, On 11/6/16 4:31 AM, Stefan Mayr wrote: > Am 05.11.2016 um 23:58 schrieb Mark Thomas: >> 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. I'm +1 on adding an option, and I think it should be enabled *by default*. The name of the option should be more clear about what it actually does rather than "fix cookies for stupid MSIE" (as satisfying as that would be). It should be something more like supplyExpiresAndMaxAgeWithCookies. - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJYIJzaAAoJEBzwKT+lPKRYPHAQAL/zTmi/A4wdWUVoWZlSM+Jd jrxpewT/a2QmhFChpTworCYGk8U4qkfPwuCuh8SEc91+5e8RuUiUQH+HAmnzjaHc f/h40HJIE3EFdKQVt5+QLagrD0XTlt/p+AjmlyEVVlTDAGqx67JX9NaFjvRe0GD+ 7i3BgBJeuw9Mo4rAVZmOtTkW1njR+1I066Bq1X8+fK48u7Btq4rJgOjiVmNTjPax HhemAPtg/rgaNFCM/TmWdCj1XfmVHHlwwoWxbvn+fPO2IXBJccNBscxZBjaeOvuD lXjzvsHxeWMxa9JkqgwBxQQNeE2PZNd5od5nbayhhpehhqAMEjKlKhPGx/SHZno9 thNxvhQ+3x0u7JzZMgZi2dVsmZSa7vWAiGLdJHWzpiyQI7m9vwYMMlr/d8s5irXi NR6nhf/dyjEKbSNqEqEKH+oJHblkEedcKn5vaLMKFTpD1dT5itvslGum3PdyJgAj 647qnxJnkhRJkZ5zxwO1KHSIQjcQRZHrKsWMWsuh2rJbchwvvi9q7Ts/uBc+nRO6 idfWUr5SqLaC7a/HA9zq7jeJwfqAWyu3fC2ZZFMctKq7K6+Ebf8wH4PhUD5vov8O 3GfOh2im+6IrAepMDCZJxcSgFRRi+Xbsd+kaw8YLQh2utCkrgBjmvkKxOrSIfcVq PFQuAUNv3sDqmEPsJuKv =kL5K -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 8.5.5 (8.5+) Default Cookie Processor breaks persistent cookies for all IE versions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Stefan, On 11/6/16 4:31 AM, Stefan Mayr wrote: > Am 05.11.2016 um 23:58 schrieb Mark Thomas: >> 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. I'm +1 on adding an option, and I think it should be enabled *by default*. The name of the option should be more clear about what it actually does rather than "fix cookies for stupid MSIE" (as satisfying as that would be). It should be something more like supplyExpiresAndMaxAgeWithCookies. - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJYIJzaAAoJEBzwKT+lPKRYPHAQAL/zTmi/A4wdWUVoWZlSM+Jd jrxpewT/a2QmhFChpTworCYGk8U4qkfPwuCuh8SEc91+5e8RuUiUQH+HAmnzjaHc f/h40HJIE3EFdKQVt5+QLagrD0XTlt/p+AjmlyEVVlTDAGqx67JX9NaFjvRe0GD+ 7i3BgBJeuw9Mo4rAVZmOtTkW1njR+1I066Bq1X8+fK48u7Btq4rJgOjiVmNTjPax HhemAPtg/rgaNFCM/TmWdCj1XfmVHHlwwoWxbvn+fPO2IXBJccNBscxZBjaeOvuD lXjzvsHxeWMxa9JkqgwBxQQNeE2PZNd5od5nbayhhpehhqAMEjKlKhPGx/SHZno9 thNxvhQ+3x0u7JzZMgZi2dVsmZSa7vWAiGLdJHWzpiyQI7m9vwYMMlr/d8s5irXi NR6nhf/dyjEKbSNqEqEKH+oJHblkEedcKn5vaLMKFTpD1dT5itvslGum3PdyJgAj 647qnxJnkhRJkZ5zxwO1KHSIQjcQRZHrKsWMWsuh2rJbchwvvi9q7Ts/uBc+nRO6 idfWUr5SqLaC7a/HA9zq7jeJwfqAWyu3fC2ZZFMctKq7K6+Ebf8wH4PhUD5vov8O 3GfOh2im+6IrAepMDCZJxcSgFRRi+Xbsd+kaw8YLQh2utCkrgBjmvkKxOrSIfcVq PFQuAUNv3sDqmEPsJuKv =kL5K -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 8.5.5 (8.5+) Default Cookie Processor breaks persistent cookies for all IE versions
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 https://blogs.msdn.microsoft.com/ieinternals/2009/08/20/internet-explorer-cookie-internals-faq/ and the last response to https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/8183708/ 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: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > Stefan - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 8.5.5 (8.5+) Default Cookie Processor breaks persistent cookies for all IE versions
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. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
