You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by "Hedrick, Brooke - 43" <br...@rainhail.com> on 2016/11/04 19:10:18 UTC
Tomcat 8.5.5 (8.5+) Default Cookie Processor breaks persistent
cookies for all IE versions
Sorry if this has been already asked. I searched the archives and didn't find what I was looking for.
Has anyone else run into an issue with persistent cookies in Tomcat 8.5+ and IE not working?
We are seeing an issue where the new default cookie processor, org.apache.tomcat.util.http.Rfc6265CookieProcessor, is not writing out the expires tag for the cookies. It is only writing out max-age in the generateHeader() method. This is a change from the previous cookie processing.
Here's the current code:
https://svn.apache.org/repos/asf/tomcat/trunk/java/org/apache/tomcat/util/http/Rfc6265CookieProcessor.java
There is documentation at https://tomcat.apache.org/tomcat-8.5-doc/config/cookie-processor.html which explains the new vs legacy cookie handler and that this behavior is intentional. It doesn't explain that this behavior isn't limited to IE6-7. It also affects IE8-11 and Edge and as a result, by default, Tomcat 8.5+ does not create persistent cookies that work with IE on any IE version.
Does it make sense that the shipping configuration would not work with IE for persistent cookies?
There are other gotchas like blank/null cookie values cause problems with the new default processor and a leading period in the cookie domain causes issues. We have fixed these issues across many applications, but weren't expecting issues with persistent cookies not working at all in IE. The documentation on the Tomcat page alludes to IE6-7 having the issue. It doesn't mention the other versions.
We are looking into short term solutions (while avoiding the legacy cookie processor ) - writing our own headers, creating a filter, ...
Another interesting observation is that the ExpiresFilter included with Tomcat still writes both the expires and max-age attributes. https://tomcat.apache.org/tomcat-8.5-doc/api/org/apache/catalina/filters/ExpiresFilter.html
Here's a page where you can see the issue of IE not reading the max-age attribute. On Chrome, FF, and Safari, the test will complete after a few runs. On IE, it runs indefinitely.
http://mrcoles.com/media/test/cookies-max-age-vs-expires.html
If I have missed some configuration, tested incorrectly, etc., please let me know.
RE: Tomcat 8.5.5 (8.5+) Default Cookie Processor breaks persistent
cookies for all IE versions
Posted by "Hedrick, Brooke - 43" <br...@rainhail.com>.
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:chris@christopherschultz.net]
Sent: Monday, November 07, 2016 9:25 AM
To: Tomcat Users List <us...@tomcat.apache.org>
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat 8.5.5 (8.5+) Default Cookie Processor breaks persistent
cookies for all IE versions
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat 8.5.5 (8.5+) Default Cookie Processor breaks persistent
cookies for all IE versions
Posted by Stefan Mayr <st...@mayr-stefan.de>.
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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat 8.5.5 (8.5+) Default Cookie Processor breaks persistent
cookies for all IE versions
Posted by Rémy Maucherat <re...@apache.org>.
2016-11-10 16:02 GMT+01:00 Christopher Schultz <chris@christopherschultz.net
>:
> 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
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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 <ma...@apache.org>:
>
>> 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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat 8.5.5 (8.5+) Default Cookie Processor breaks persistent
cookies for all IE versions
Posted by Rémy Maucherat <re...@apache.org>.
2016-11-10 11:51 GMT+01:00 Mark Thomas <ma...@apache.org>:
> 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
Posted by Mark Thomas <ma...@apache.org>.
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat 8.5.5 (8.5+) Default Cookie Processor breaks persistent
cookies for all IE versions
Posted by Rémy Maucherat <re...@apache.org>.
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
Re: Tomcat 8.5.5 (8.5+) Default Cookie Processor breaks persistent
cookies for all IE versions
Posted by 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.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org