Cookies are broken in 6.0.16?
Hi all, This is a follow up to thread Cookies are broken in 6.0.16? http://marc.info/?t=12025394451r=2w=2 Before submitting a bug report on the matter exposed below I wanted to open a discussion with Tomcat developpers about it. Summary of the above thread : - Problem : If a webapp is using an equal sign in the value of a cookie, Tomcat alter the cookie value. - Explanation : For security reason a change has been introduced in 5.5.26 and 6.0.16 to cookie management regarding the equal sign. - Solution suggested by Filip Hanik in the thread: All applications should be modified to use cookie.setVersion(1) if they want to use equal sign in their value. Using version 1 cookie surrounds all cookies attributes with quotes and leave the value intact. First of all, I'd like to point out that breaking existing cookie behavior and requiring applications to be updated in order to work properly is probably not the best choice ... Clients tend to think twice before upgrading their application to a more recent version and it is not a process they want to perform every day... In our webapp, we use an equal sign in a cookie's value. Even though all other application server we use (BEA Weblogic, IBM WebSphere) do not have the above problem. I have decided not to brag too much about this decision for Tomcat and I was in the process of updating our CMS to use cookie version 1... but... ... it does not work with IE 7. Why ? Because a path is specified in our cookie. And Tomcat also surrounds the path with quotes, which is not accepted by IE 7 (probably other version of IE too, I have not tested yet). Here is a simple test case. Place this jsp in a directory subdir inside a ROOT webapp. % Cookie cookie1 = new Cookie(Cookie1, Hello World 1!); Cookie cookie2 = new Cookie(Cookie2, Hello World 2!); cookie2.setVersion(1); Cookie cookie3 = new Cookie(Cookie3, Hello World 3!); cookie3.setPath(/subdir); Cookie cookie4 = new Cookie(Cookie4, Hello World 4!); cookie4.setPath(/subdir); cookie4.setVersion(1); response.addCookie(cookie1); response.addCookie(cookie2); response.addCookie(cookie3); response.addCookie(cookie4); % Here is the Tomcat response will output : Set-Cookie: Cookie1=Hello World 1! Set-Cookie: Cookie2=Hello World 2!; Version=1 Set-Cookie: Cookie3=Hello World 3!; Path=/subdir Set-Cookie: Cookie4=Hello World 4!; Version=1; Path=/subdir == IE 7 does not send back the cookie #4. If using fiddler, we alter the response that way : Set-Cookie: Cookie1=Hello World 1! Set-Cookie: Cookie2=Hello World 2!; Version=1 Set-Cookie: Cookie3=Hello World 3!; Path=/subdir Set-Cookie: Cookie4=Hello World 4!; Version=1; Path=/subdir == IE 7 accepts all the cookie I can understand the security reasons behind the modification requiring quotes around cookies' attribute value. So my questions are : - What could be done in Tomcat to fix this ? - Is the security problem real if it is why do other application server vendors do not have this behavior ? - As it break older application and it is not compatible with IE 7 in some circumstances. Do you really think this modification should be kept that way ? Thanks in advance for your replies! Best regards, Olivier Jaquemet - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cookies are broken in 6.0.16?
Olivier Jaquemet wrote: So my questions are : - What could be done in Tomcat to fix this ? This has been discussed extensively on the dev list and there is a patch proposed. See the archives for details. - Is the security problem real if it is why do other application server vendors do not have this behavior ? Yes the problem is real. It won't affect every installation or every application but it does affect some. As for the other app servers: don't know - haven't tested them. - As it break older application and it is not compatible with IE 7 in some circumstances. Do you really think this modification should be kept that way ? No. Again, see the discussion in the archives. Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cookies are broken in 6.0.16?
Thank you for your answer Mark. Accept my apologies for bothering you with already fixed issues. I had not found the appropriate discussions in the archive. Olivier Mark Thomas wrote: Olivier Jaquemet wrote: So my questions are : - What could be done in Tomcat to fix this ? This has been discussed extensively on the dev list and there is a patch proposed. See the archives for details. - Is the security problem real if it is why do other application server vendors do not have this behavior ? Yes the problem is real. It won't affect every installation or every application but it does affect some. As for the other app servers: don't know - haven't tested them. - As it break older application and it is not compatible with IE 7 in some circumstances. Do you really think this modification should be kept that way ? No. Again, see the discussion in the archives. Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cookies are broken in 6.0.16?
One last question Mark... The tc6.6.x trunk has the patch and it works fine, but not yet the tc5.5.x. Is it planned for the next 5.5.x release ? Olivier Jaquemet wrote: Thank you for your answer Mark. Accept my apologies for bothering you with already fixed issues. I had not found the appropriate discussions in the archive. Olivier Mark Thomas wrote: Olivier Jaquemet wrote: So my questions are : - What could be done in Tomcat to fix this ? This has been discussed extensively on the dev list and there is a patch proposed. See the archives for details. - Is the security problem real if it is why do other application server vendors do not have this behavior ? Yes the problem is real. It won't affect every installation or every application but it does affect some. As for the other app servers: don't know - haven't tested them. - As it break older application and it is not compatible with IE 7 in some circumstances. Do you really think this modification should be kept that way ? No. Again, see the discussion in the archives. Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cookies are broken in 6.0.16?
even the 6.0.x needs one more patch in order to be backwards compatible Filip Olivier Jaquemet wrote: One last question Mark... The tc6.6.x trunk has the patch and it works fine, but not yet the tc5.5.x. Is it planned for the next 5.5.x release ? Olivier Jaquemet wrote: Thank you for your answer Mark. Accept my apologies for bothering you with already fixed issues. I had not found the appropriate discussions in the archive. Olivier Mark Thomas wrote: Olivier Jaquemet wrote: So my questions are : - What could be done in Tomcat to fix this ? This has been discussed extensively on the dev list and there is a patch proposed. See the archives for details. - Is the security problem real if it is why do other application server vendors do not have this behavior ? Yes the problem is real. It won't affect every installation or every application but it does affect some. As for the other app servers: don't know - haven't tested them. - As it break older application and it is not compatible with IE 7 in some circumstances. Do you really think this modification should be kept that way ? No. Again, see the discussion in the archives. Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cookies are broken in 6.0.16?
On Feb 13, 2008, at 7:37 AM, Filip Hanik - Dev Lists wrote: what do you guys think of this one http://people.apache.org/~fhanik/patches/cookie-default-v1.patch basically what it does, instead of forcing all cookies to v1, it does this if the cookie is v0 and the switchToV1 flag is true (let me know what the default value should be) and the cookie contains invalid characters then - quote the cookie and set the version to 1 Personally, I think the default should be false (switchToV1), which I think would be in keeping with the principle of least astonishment... But I'm fine either way. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cookies are broken in 6.0.16?
what do you guys think of this one http://people.apache.org/~fhanik/patches/cookie-default-v1.patch basically what it does, instead of forcing all cookies to v1, it does this if the cookie is v0 and the switchToV1 flag is true (let me know what the default value should be) and the cookie contains invalid characters then - quote the cookie and set the version to 1 Filip Bill Barker wrote: Remy Maucherat [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] On Sun, 2008-02-10 at 23:29 +, Mark Thomas wrote: Filip Hanik - Dev Lists wrote: Would this be ok, given its a spec class? or do we have to leave this class untouched and modify it elsewhere, in which case it'd be more of a hack. I think, as long as we leave the public interface unchanged, changing the spec class would be fine. The spec says that RFC 2109 should be used by default so if org.apache.catalina.STRICT_SERVLET_COMPLIANCE is true I think v0 cookies should be used. There's also an opportunity to force the version in addCookie. Not as nice, but this may cause less problems. +1 to put in addCookie or in ServerCookie. Other projects use Tomcat's version of the servlet-api.jar, and I don't like the idea of publishing one that isn't strictly spec compliant. Of course, as Remy pointed out, this has the effect of forcing v1 cookies as a downside. Probably better than forcing the version is to revert to 'always quote' in ServerCookie unless the STRICT_SERVLET_COMPIANCE flag is true. We did the 'always quote' in the first place because it is more browser friendly (at least for 21st century browsers). Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cookies are broken in 6.0.16?
Sven Köhler wrote: The difficulty here is that although '=' is the delimiter between NAME and VALUE there is no need to encode it if it appears in the name or the value. This causes some ambiguities when parsing a header of the form: Set-Cookie: foo=bar=bartoo Is the name 'foo' or 'foo=bar'? Is the value 'bar=bartoo' or 'bartoo'? The changes to the cookie parsing mean the second '=' and any text beyond it are now ignored. !??? By instinct, i would have chosen the first = to split the string into NAME and VALUE. Why have you chosen the second = or maybe eben the last = occuring in the cookie-string? Actually, the spec doesn't disagree with chosing any of the = ... But some users have supplied some reasonable arguments (base64 is padding with =, etc.) to rather chose the first = over the other ones. in that case, the user should use v1 cookies :) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cookies are broken in 6.0.16?
Sven Köhler wrote: And it seems to be the case, that people don't use names containg the = character but rather use values that do which was possible with the old behaviour - and indeed seems to me to be the use-case used much more often then the name contains = use-case. I got bit on this once. My app was using = in the value. Worked great under Tomcat 5, but under 4.0 (I think) it didn't work. I ended up forcing my cookie types to v1. -- George Sexton MH Software, Inc. Voice: +1 303 438 9585 URL: http://www.mhsoftware.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cookies are broken in 6.0.16?
The difficulty here is that although '=' is the delimiter between NAME and VALUE there is no need to encode it if it appears in the name or the value. This causes some ambiguities when parsing a header of the form: Set-Cookie: foo=bar=bartoo Is the name 'foo' or 'foo=bar'? Is the value 'bar=bartoo' or 'bartoo'? The changes to the cookie parsing mean the second '=' and any text beyond it are now ignored. !??? By instinct, i would have chosen the first = to split the string into NAME and VALUE. Why have you chosen the second = or maybe eben the last = occuring in the cookie-string? Actually, the spec doesn't disagree with chosing any of the = ... But some users have supplied some reasonable arguments (base64 is padding with =, etc.) to rather chose the first = over the other ones. signature.asc Description: OpenPGP digital signature
Re: Cookies are broken in 6.0.16?
v0 cookies, the spec says /NAME/=/VALUE/ This string is a sequence of characters excluding semi-colon, comma and white space. If there is a need to place such data in the name or value, some encoding method such as URL style %XX encoding is recommended, though no encoding is defined or required. the problem was that encoding wasn't defined nor required. so when we followed the spec, and added %XX encoding, TCK tests failed. Does splitting at the first = fail the TCK tests? signature.asc Description: OpenPGP digital signature
Re: Cookies are broken in 6.0.16?
Filip Hanik - Dev Lists wrote: Jim Manico wrote: I guess we could throw a run time exception if the value contained any of those. other than that, I'm not sure how to behave I think this is the best case scenario for v0 cookies. Perhaps, if you really want to get fancy, you can add a flag to let legacy solutions roll back to the old/non-standard cookie handling methodology? no, we wont do that. we fixed the cookie behavior in this release due to security issues filed against the old parsing. The security issue only exists because of a fundamentally broken servlet in the examples, and assumes the user will click on a URL. That's not what I call a security problem. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cookies are broken in 6.0.16?
Remy Maucherat wrote: Filip Hanik - Dev Lists wrote: Jim Manico wrote: I guess we could throw a run time exception if the value contained any of those. other than that, I'm not sure how to behave I think this is the best case scenario for v0 cookies. Perhaps, if you really want to get fancy, you can add a flag to let legacy solutions roll back to the old/non-standard cookie handling methodology? no, we wont do that. we fixed the cookie behavior in this release due to security issues filed against the old parsing. The security issue only exists because of a fundamentally broken servlet in the examples, and assumes the user will click on a URL. That's not what I call a security problem. The root cause of the issue wasn't the servlet in the examples. If it were, that servlet would have been fixed. The issue was a number of bugs/inconsistencies in the handling of cookie headers, particularly around quoting and unquoting which enabled XSS attacks in some instances. That said the issues were all hard to exploit and required the application to use user provided data directly as the cookie value. This was why these issues were rated as low severity. An enhancement request to log when Tomcat ignores/truncates a value or identifies some other issue when parsing cookies seems reasonable to me. Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cookies are broken in 6.0.16?
The security issue only exists because of a fundamentally broken servlet in the examples, and assumes the user will click on a URL. That's not what I call a security problem. There is a whole class of security problems that are driven by bad server code and user interaction, such as reflective XSS due to poor input validation. Low risk as Filip saz, but a security problem none-the-less. - Jim Filip Hanik - Dev Lists wrote: Jim Manico wrote: I guess we could throw a run time exception if the value contained any of those. other than that, I'm not sure how to behave I think this is the best case scenario for v0 cookies. Perhaps, if you really want to get fancy, you can add a flag to let legacy solutions roll back to the old/non-standard cookie handling methodology? no, we wont do that. we fixed the cookie behavior in this release due to security issues filed against the old parsing. The security issue only exists because of a fundamentally broken servlet in the examples, and assumes the user will click on a URL. That's not what I call a security problem. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cookies are broken in 6.0.16?
Mark Thomas wrote: Remy Maucherat wrote: Filip Hanik - Dev Lists wrote: Jim Manico wrote: I guess we could throw a run time exception if the value contained any of those. other than that, I'm not sure how to behave I think this is the best case scenario for v0 cookies. Perhaps, if you really want to get fancy, you can add a flag to let legacy solutions roll back to the old/non-standard cookie handling methodology? no, we wont do that. we fixed the cookie behavior in this release due to security issues filed against the old parsing. The security issue only exists because of a fundamentally broken servlet in the examples, and assumes the user will click on a URL. That's not what I call a security problem. The root cause of the issue wasn't the servlet in the examples. If it were, that servlet would have been fixed. The issue was a number of bugs/inconsistencies in the handling of cookie headers, particularly around quoting and unquoting which enabled XSS attacks in some instances. That said the issues were all hard to exploit and required the application to use user provided data directly as the cookie value. This was why these issues were rated as low severity. An enhancement request to log when Tomcat ignores/truncates a value or identifies some other issue when parsing cookies seems reasonable to me. the thing is, the javadoc as very very clear on this, to create a v0 cookie, and put == in the end, is obviously not good :) Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cookies are broken in 6.0.16?
Filip - you are 100% correct on this thread. Are you basically the traffic cop guarding the core of Tomcat? - Jim Mark Thomas wrote: Remy Maucherat wrote: Filip Hanik - Dev Lists wrote: Jim Manico wrote: I guess we could throw a run time exception if the value contained any of those. other than that, I'm not sure how to behave I think this is the best case scenario for v0 cookies. Perhaps, if you really want to get fancy, you can add a flag to let legacy solutions roll back to the old/non-standard cookie handling methodology? no, we wont do that. we fixed the cookie behavior in this release due to security issues filed against the old parsing. The security issue only exists because of a fundamentally broken servlet in the examples, and assumes the user will click on a URL. That's not what I call a security problem. The root cause of the issue wasn't the servlet in the examples. If it were, that servlet would have been fixed. The issue was a number of bugs/inconsistencies in the handling of cookie headers, particularly around quoting and unquoting which enabled XSS attacks in some instances. That said the issues were all hard to exploit and required the application to use user provided data directly as the cookie value. This was why these issues were rated as low severity. An enhancement request to log when Tomcat ignores/truncates a value or identifies some other issue when parsing cookies seems reasonable to me. the thing is, the javadoc as very very clear on this, to create a v0 cookie, and put == in the end, is obviously not good :) Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cookies are broken in 6.0.16?
Mark Thomas wrote: Remy Maucherat wrote: Filip Hanik - Dev Lists wrote: Jim Manico wrote: I guess we could throw a run time exception if the value contained any of those. other than that, I'm not sure how to behave I think this is the best case scenario for v0 cookies. Perhaps, if you really want to get fancy, you can add a flag to let legacy solutions roll back to the old/non-standard cookie handling methodology? no, we wont do that. we fixed the cookie behavior in this release due to security issues filed against the old parsing. The security issue only exists because of a fundamentally broken servlet in the examples, and assumes the user will click on a URL. That's not what I call a security problem. The root cause of the issue wasn't the servlet in the examples. If it were, that servlet would have been fixed. The issue was a number of bugs/inconsistencies in the handling of cookie headers, particularly around quoting and unquoting which enabled XSS attacks in some instances. That said the issues were all hard to exploit and required the application to use user provided data directly as the cookie value. This was why these issues were rated as low severity. An enhancement request to log when Tomcat ignores/truncates a value or identifies some other issue when parsing cookies seems reasonable to me. I just thought some more on this, the easiest suggestion I would come up with would be to have a flag that defaults all cookies to v1. turning on this flag, will make all values work correctly. Filip - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cookies are broken in 6.0.16?
On Sun, 2008-02-10 at 11:44 -0500, Jim Manico wrote: Filip - you are 100% correct on this thread. Are you basically the traffic cop guarding the core of Tomcat? I understand, you are not impacted by the behavior change, and as a result this allows you to be fair, I suppose. The issue is that the behavior of Tomcat has been different, in all prior releases, and changing it of all a sudden without any configuration capability because it feels nice to play spec lawyer is wrong to me. Similar decisions have been made in the past, and this did cause problems, it's simply faster to add the appropriate options right away. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cookies are broken in 6.0.16?
That post was meant to go to Filip only, since he is an old friend. I was not trying to poke fun at your perspective on this public list, Remy. I'm going exit stage left and stop adding my thoughts to this thread. My apologies. - Jim On Sun, 2008-02-10 at 11:44 -0500, Jim Manico wrote: Filip - you are 100% correct on this thread. Are you basically the traffic cop guarding the core of Tomcat? I understand, you are not impacted by the behavior change, and as a result this allows you to be fair, I suppose. The issue is that the behavior of Tomcat has been different, in all prior releases, and changing it of all a sudden without any configuration capability because it feels nice to play spec lawyer is wrong to me. Similar decisions have been made in the past, and this did cause problems, it's simply faster to add the appropriate options right away. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cookies are broken in 6.0.16?
Remy Maucherat wrote: On Sun, 2008-02-10 at 11:44 -0500, Jim Manico wrote: Filip - you are 100% correct on this thread. Are you basically the traffic cop guarding the core of Tomcat? I understand, you are not impacted by the behavior change, and as a result this allows you to be fair, I suppose. The issue is that the behavior of Tomcat has been different, in all prior releases, and changing it of all a sudden without any configuration capability because it feels nice to play spec lawyer is wrong to me. Similar decisions have been made in the past, and this did cause problems, it's simply faster to add the appropriate options right away. what about my suggestion, to add a flag to default to v1 cookies. they get quoted and old behavior will continue to work. Filip - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cookies are broken in 6.0.16?
On Sun, 2008-02-10 at 11:17 -0700, Filip Hanik - Dev Lists wrote: Remy Maucherat wrote: On Sun, 2008-02-10 at 11:44 -0500, Jim Manico wrote: Filip - you are 100% correct on this thread. Are you basically the traffic cop guarding the core of Tomcat? I understand, you are not impacted by the behavior change, and as a result this allows you to be fair, I suppose. The issue is that the behavior of Tomcat has been different, in all prior releases, and changing it of all a sudden without any configuration capability because it feels nice to play spec lawyer is wrong to me. Similar decisions have been made in the past, and this did cause problems, it's simply faster to add the appropriate options right away. what about my suggestion, to add a flag to default to v1 cookies. they get quoted and old behavior will continue to work. This is the sort of configuration option which seems appropriate. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cookies are broken in 6.0.16?
Remy Maucherat wrote: On Sun, 2008-02-10 at 11:17 -0700, Filip Hanik - Dev Lists wrote: Remy Maucherat wrote: On Sun, 2008-02-10 at 11:44 -0500, Jim Manico wrote: Filip - you are 100% correct on this thread. Are you basically the traffic cop guarding the core of Tomcat? I understand, you are not impacted by the behavior change, and as a result this allows you to be fair, I suppose. The issue is that the behavior of Tomcat has been different, in all prior releases, and changing it of all a sudden without any configuration capability because it feels nice to play spec lawyer is wrong to me. Similar decisions have been made in the past, and this did cause problems, it's simply faster to add the appropriate options right away. what about my suggestion, to add a flag to default to v1 cookies. they get quoted and old behavior will continue to work. This is the sort of configuration option which seems appropriate. essentially, browsers treated our previous v0 cookies as v1 when we quoted them. question, obviously it would be easiest for us to put the global flag in the javax.servlet.http.Cookie class directly -private int version = 0;// ;Version=1 ... means RFC 2109++ style +private int version = Integer.parseInt(System.getProperty(org.apache.catalina.cookie.version,1)); // ;Version=1 ... means RFC 2109++ style Would this be ok, given its a spec class? or do we have to leave this class untouched and modify it elsewhere, in which case it'd be more of a hack. Filip - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cookies are broken in 6.0.16?
Filip Hanik - Dev Lists wrote: Would this be ok, given its a spec class? or do we have to leave this class untouched and modify it elsewhere, in which case it'd be more of a hack. I think, as long as we leave the public interface unchanged, changing the spec class would be fine. The spec says that RFC 2109 should be used by default so if org.apache.catalina.STRICT_SERVLET_COMPLIANCE is true I think v0 cookies should be used. Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cookies are broken in 6.0.16?
On Sun, 2008-02-10 at 23:29 +, Mark Thomas wrote: Filip Hanik - Dev Lists wrote: Would this be ok, given its a spec class? or do we have to leave this class untouched and modify it elsewhere, in which case it'd be more of a hack. I think, as long as we leave the public interface unchanged, changing the spec class would be fine. The spec says that RFC 2109 should be used by default so if org.apache.catalina.STRICT_SERVLET_COMPLIANCE is true I think v0 cookies should be used. There's also an opportunity to force the version in addCookie. Not as nice, but this may cause less problems. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cookies are broken in 6.0.16?
Remy Maucherat [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] On Sun, 2008-02-10 at 23:29 +, Mark Thomas wrote: Filip Hanik - Dev Lists wrote: Would this be ok, given its a spec class? or do we have to leave this class untouched and modify it elsewhere, in which case it'd be more of a hack. I think, as long as we leave the public interface unchanged, changing the spec class would be fine. The spec says that RFC 2109 should be used by default so if org.apache.catalina.STRICT_SERVLET_COMPLIANCE is true I think v0 cookies should be used. There's also an opportunity to force the version in addCookie. Not as nice, but this may cause less problems. +1 to put in addCookie or in ServerCookie. Other projects use Tomcat's version of the servlet-api.jar, and I don't like the idea of publishing one that isn't strictly spec compliant. Of course, as Remy pointed out, this has the effect of forcing v1 cookies as a downside. Probably better than forcing the version is to revert to 'always quote' in ServerCookie unless the STRICT_SERVLET_COMPIANCE flag is true. We did the 'always quote' in the first place because it is more browser friendly (at least for 21st century browsers). Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cookies are broken in 6.0.16?
Bill Barker wrote: Remy Maucherat [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] On Sun, 2008-02-10 at 23:29 +, Mark Thomas wrote: Filip Hanik - Dev Lists wrote: Would this be ok, given its a spec class? or do we have to leave this class untouched and modify it elsewhere, in which case it'd be more of a hack. I think, as long as we leave the public interface unchanged, changing the spec class would be fine. The spec says that RFC 2109 should be used by default so if org.apache.catalina.STRICT_SERVLET_COMPLIANCE is true I think v0 cookies should be used. There's also an opportunity to force the version in addCookie. Not as nice, but this may cause less problems. +1 to put in addCookie or in ServerCookie. Other projects use Tomcat's version of the servlet-api.jar, and I don't like the idea of publishing one that isn't strictly spec compliant. Of course, as Remy pointed out, this has the effect of forcing v1 cookies as a downside. Probably better than forcing the version is to revert to 'always quote' in ServerCookie unless the STRICT_SERVLET_COMPIANCE flag is true. We did the 'always quote' in the first place because it is more browser friendly (at least for 21st century browsers). this comes with all the other side effects of strict servlet compliance. I'm open to either option, ie forcing cookies, or always quoting, but would prefer a separate flag Filip - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cookies are broken in 6.0.16?
Mark Thomas wrote: Filip Hanik - Dev Lists wrote: Would this be ok, given its a spec class? or do we have to leave this class untouched and modify it elsewhere, in which case it'd be more of a hack. I think, as long as we leave the public interface unchanged, changing the spec class would be fine. The spec says that RFC 2109 should be used by default so if org.apache.catalina.STRICT_SERVLET_COMPLIANCE is true I think v0 cookies should be I would agree with this assessment. and it would work for other frameworks that use our servlet-api.jar, as we don't force one version or the other, we just set a default. Filip Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cookies are broken in 6.0.16?
On Feb 10, 2008, at 2:42 PM, Filip Hanik - Dev Lists wrote: Remy Maucherat wrote: On Sun, 2008-02-10 at 11:17 -0700, Filip Hanik - Dev Lists wrote: Remy Maucherat wrote: On Sun, 2008-02-10 at 11:44 -0500, Jim Manico wrote: Filip - you are 100% correct on this thread. Are you basically the traffic cop guarding the core of Tomcat? I understand, you are not impacted by the behavior change, and as a result this allows you to be fair, I suppose. The issue is that the behavior of Tomcat has been different, in all prior releases, and changing it of all a sudden without any configuration capability because it feels nice to play spec lawyer is wrong to me. Similar decisions have been made in the past, and this did cause problems, it's simply faster to add the appropriate options right away. what about my suggestion, to add a flag to default to v1 cookies. they get quoted and old behavior will continue to work. This is the sort of configuration option which seems appropriate. essentially, browsers treated our previous v0 cookies as v1 when we quoted them. question, obviously it would be easiest for us to put the global flag in the javax.servlet.http.Cookie class directly -private int version = 0;// ;Version=1 ... means RFC 2109++ style +private int version = Integer.parseInt(System.getProperty (org.apache.catalina.cookie.version,1)); // ;Version=1 ... means RFC 2109++ style Would this be ok, given its a spec class? or do we have to leave this class untouched and modify it elsewhere, in which case it'd be more of a hack. I would hope that you would put this behavior in a non javax class since it's possible that tomcat may be used with other peoples servlet spec jars. I think consistent behavior independent of which spec jar you happen to pick would be desirable. thanks david jencks Filip - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cookies are broken in 6.0.16?
Maik Jablonski wrote: Hi, I've just encountered that Cookies seem to be a little bit broken in 6.0.16. If you want to read a cookie which ends on one or more equals-sign (=), the equals-signs are removed by Tomcat when the cookie is read. Is it a bug or a undocumented change? It is neither. The changes are documented in the change log. As a result of a couple of minor security issues (see http://tomcat.apache.org/security-6.html) the cookie handling code has been tightened up to make it spec compliant. By default the servlet spec uses version 0 cookies. The name value pairs are defined as: spec-quote NAME=VALUE This string is a sequence of characters excluding semi-colon, comma and white space. If there is a need to place such data in the name or value, some encoding method such as URL style %XX encoding is recommended, though no encoding is defined or required. /spec-quote The difficulty here is that although '=' is the delimiter between NAME and VALUE there is no need to encode it if it appears in the name or the value. This causes some ambiguities when parsing a header of the form: Set-Cookie: foo=bar=bartoo Is the name 'foo' or 'foo=bar'? Is the value 'bar=bartoo' or 'bartoo'? The changes to the cookie parsing mean the second '=' and any text beyond it are now ignored. If you set the cookie version to 1 then the quoting will be applied where necessary and your example will work as you intend. Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cookies are broken in 6.0.16?
Mark Thomas wrote: Maik Jablonski wrote: Hi, I've just encountered that Cookies seem to be a little bit broken in 6.0.16. If you want to read a cookie which ends on one or more equals-sign (=), the equals-signs are removed by Tomcat when the cookie is read. Is it a bug or a undocumented change? It is neither. The changes are documented in the change log. As a result of a couple of minor security issues (see http://tomcat.apache.org/security-6.html) the cookie handling code has been tightened up to make it spec compliant. By default the servlet spec uses version 0 cookies. The name value pairs are defined as: spec-quote NAME=VALUE This string is a sequence of characters excluding semi-colon, comma and white space. If there is a need to place such data in the name or value, some encoding method such as URL style %XX encoding is recommended, though no encoding is defined or required. /spec-quote The difficulty here is that although '=' is the delimiter between NAME and VALUE there is no need to encode it if it appears in the name or the value. This causes some ambiguities when parsing a header of the form: Set-Cookie: foo=bar=bartoo Is the name 'foo' or 'foo=bar'? Is the value 'bar=bartoo' or 'bartoo'? The changes to the cookie parsing mean the second '=' and any text beyond it are now ignored. If you set the cookie version to 1 then the quoting will be applied where necessary and your example will work as you intend. I have an installation that receives callbacks from 3DSecure enabled banking systems, ie Verified by Visa and Mastercard SecureCode. The parameter values submitted in the callback to our system frequently have double equals symbols at the end of the parameter data '...s83jkd9=='. Attempting to upgrade from 6.0.10 to 6.0.16 caused the servlet that receives the callback to see no parameters submitted. I have not satisfied myself yet that there are no other problems, as it was my intention to do so in the coming week, but the above sounds like a reasonable explanation for the apparent fault. Thoughts or comments? p Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cookies are broken in 6.0.16?
On Feb 9, 2008 2:03 PM, Mark Thomas [EMAIL PROTECTED] wrote: It is neither. The changes are documented in the change log. As a result of a couple of minor security issues (see http://tomcat.apache.org/security-6.html) the cookie handling code has been tightened up to make it spec compliant. Hi Mark, thanks for the good explanation, I'm fine with it, but maybe some explicit note about this change of behaviour will help people from running into trouble after an upgrade to 6.0.16... at least I wasn't able to detect this change from the URL mentioned above or the Tomcat-changelog. Just as an example: I'm using some BASE64-encoded strings, which I store in a cookie-value. These strings are padded with equal-signs on their right by the BASE64-encoding. Depending on the application changes and resulting problems in the cookie-parsing by Tomcat maybe hard to detect. Cheers, Maik - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cookies are broken in 6.0.16?
Pid wrote: Mark Thomas wrote: Maik Jablonski wrote: Hi, I've just encountered that Cookies seem to be a little bit broken in 6.0.16. If you want to read a cookie which ends on one or more equals-sign (=), the equals-signs are removed by Tomcat when the cookie is read. Is it a bug or a undocumented change? It is neither. The changes are documented in the change log. As a result of a couple of minor security issues (see http://tomcat.apache.org/security-6.html) the cookie handling code has been tightened up to make it spec compliant. By default the servlet spec uses version 0 cookies. The name value pairs are defined as: spec-quote NAME=VALUE This string is a sequence of characters excluding semi-colon, comma and white space. If there is a need to place such data in the name or value, some encoding method such as URL style %XX encoding is recommended, though no encoding is defined or required. /spec-quote The difficulty here is that although '=' is the delimiter between NAME and VALUE there is no need to encode it if it appears in the name or the value. This causes some ambiguities when parsing a header of the form: Set-Cookie: foo=bar=bartoo Is the name 'foo' or 'foo=bar'? Is the value 'bar=bartoo' or 'bartoo'? The changes to the cookie parsing mean the second '=' and any text beyond it are now ignored. If you set the cookie version to 1 then the quoting will be applied where necessary and your example will work as you intend. I have an installation that receives callbacks from 3DSecure enabled banking systems, ie Verified by Visa and Mastercard SecureCode. The parameter values submitted in the callback to our system frequently have double equals symbols at the end of the parameter data '...s83jkd9=='. Attempting to upgrade from 6.0.10 to 6.0.16 caused the servlet that receives the callback to see no parameters submitted. I have not satisfied myself yet that there are no other problems, as it was my intention to do so in the coming week, but the above sounds like a reasonable explanation for the apparent fault. Thoughts or comments? In fact, please ignore, until requested otherwise. p p Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cookies are broken in 6.0.16?
On Sat, 2008-02-09 at 13:03 +, Mark Thomas wrote: Maik Jablonski wrote: Hi, I've just encountered that Cookies seem to be a little bit broken in 6.0.16. If you want to read a cookie which ends on one or more equals-sign (=), the equals-signs are removed by Tomcat when the cookie is read. Is it a bug or a undocumented change? It is neither. The changes are documented in the change log. As a result of a couple of minor security issues (see http://tomcat.apache.org/security-6.html) the cookie handling code has been tightened up to make it spec compliant. By default the servlet spec uses version 0 cookies. The name value pairs are defined as: spec-quote NAME=VALUE This string is a sequence of characters excluding semi-colon, comma and white space. If there is a need to place such data in the name or value, some encoding method such as URL style %XX encoding is recommended, though no encoding is defined or required. /spec-quote The difficulty here is that although '=' is the delimiter between NAME and VALUE there is no need to encode it if it appears in the name or the value. This causes some ambiguities when parsing a header of the form: Set-Cookie: foo=bar=bartoo Is the name 'foo' or 'foo=bar'? Is the value 'bar=bartoo' or 'bartoo'? The changes to the cookie parsing mean the second '=' and any text beyond it are now ignored. If you set the cookie version to 1 then the quoting will be applied where necessary and your example will work as you intend. It seems to me like an annoying regression. response.addCookie(new Cookie(test_cookie3, 123===)) looks like something which should be working. Are you sure there's nothing that could be done about it ? Maybe some additional encoding for '=' when not quoting ? Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cookies are broken in 6.0.16?
response.addCookie(new Cookie(test_cookie3, 123===)) looks like something which should be working. Honestly, this is not user driven - it's only server programmer driven. I would dare to say this is either absolutely horrible server side programming or a possible attempt at a hack/attack and drop the request altogether. If you really need an equals sign in your cookie data, then you must URL Encode it. If multiple equal signs appear unencodede, then it's malformed and should be rejected outright. - Jim On Sat, 2008-02-09 at 13:03 +, Mark Thomas wrote: Maik Jablonski wrote: Hi, I've just encountered that Cookies seem to be a little bit broken in 6.0.16. If you want to read a cookie which ends on one or more equals-sign (=), the equals-signs are removed by Tomcat when the cookie is read. Is it a bug or a undocumented change? It is neither. The changes are documented in the change log. As a result of a couple of minor security issues (see http://tomcat.apache.org/security-6.html) the cookie handling code has been tightened up to make it spec compliant. By default the servlet spec uses version 0 cookies. The name value pairs are defined as: spec-quote NAME=VALUE This string is a sequence of characters excluding semi-colon, comma and white space. If there is a need to place such data in the name or value, some encoding method such as URL style %XX encoding is recommended, though no encoding is defined or required. /spec-quote The difficulty here is that although '=' is the delimiter between NAME and VALUE there is no need to encode it if it appears in the name or the value. This causes some ambiguities when parsing a header of the form: Set-Cookie: foo=bar=bartoo Is the name 'foo' or 'foo=bar'? Is the value 'bar=bartoo' or 'bartoo'? The changes to the cookie parsing mean the second '=' and any text beyond it are now ignored. If you set the cookie version to 1 then the quoting will be applied where necessary and your example will work as you intend. It seems to me like an annoying regression. response.addCookie(new Cookie(test_cookie3, 123===)) looks like something which should be working. Are you sure there's nothing that could be done about it ? Maybe some additional encoding for '=' when not quoting ? Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cookies are broken in 6.0.16?
no regression, if you do this c = new javax.servlet.http.Cookie(abcv1,123==); c.setVersion(1); response.addCookie(c); then it works just fine. however, if you do c = new javax.servlet.http.Cookie(abcv0,123==); response.addCookie(c); then it doesn't. if we encode it, (which we did at our first attempt for v0 cookies) we actually don't pass the TCK. only v1 cookies should be double quoted, in previous versions of tomcat, I believe everything got double quoted, regardless of version on the cookie. v0 cookies, the spec says /NAME/=/VALUE/ This string is a sequence of characters excluding semi-colon, comma and white space. If there is a need to place such data in the name or value, some encoding method such as URL style %XX encoding is recommended, though no encoding is defined or required. the problem was that encoding wasn't defined nor required. so when we followed the spec, and added %XX encoding, TCK tests failed. at this point I would say, we handle cookies correctly. if one needs == at the end of the cookie, then they need to use v1 cookies, according to spec Filip Remy Maucherat wrote: On Sat, 2008-02-09 at 13:03 +, Mark Thomas wrote: Maik Jablonski wrote: Hi, I've just encountered that Cookies seem to be a little bit broken in 6.0.16. If you want to read a cookie which ends on one or more equals-sign (=), the equals-signs are removed by Tomcat when the cookie is read. Is it a bug or a undocumented change? It is neither. The changes are documented in the change log. As a result of a couple of minor security issues (see http://tomcat.apache.org/security-6.html) the cookie handling code has been tightened up to make it spec compliant. By default the servlet spec uses version 0 cookies. The name value pairs are defined as: spec-quote NAME=VALUE This string is a sequence of characters excluding semi-colon, comma and white space. If there is a need to place such data in the name or value, some encoding method such as URL style %XX encoding is recommended, though no encoding is defined or required. /spec-quote The difficulty here is that although '=' is the delimiter between NAME and VALUE there is no need to encode it if it appears in the name or the value. This causes some ambiguities when parsing a header of the form: Set-Cookie: foo=bar=bartoo Is the name 'foo' or 'foo=bar'? Is the value 'bar=bartoo' or 'bartoo'? The changes to the cookie parsing mean the second '=' and any text beyond it are now ignored. If you set the cookie version to 1 then the quoting will be applied where necessary and your example will work as you intend. It seems to me like an annoying regression. response.addCookie(new Cookie(test_cookie3, 123===)) looks like something which should be working. Are you sure there's nothing that could be done about it ? Maybe some additional encoding for '=' when not quoting ? Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cookies are broken in 6.0.16?
Filip, Would you consider auto-encoding only = and ; in the cookie value, but leaving everything else alone for v0 cookies? Would this possibly pass TCK? - Jim no regression, if you do this c = new javax.servlet.http.Cookie(abcv1,123==); c.setVersion(1); response.addCookie(c); then it works just fine. however, if you do c = new javax.servlet.http.Cookie(abcv0,123==); response.addCookie(c); then it doesn't. if we encode it, (which we did at our first attempt for v0 cookies) we actually don't pass the TCK. only v1 cookies should be double quoted, in previous versions of tomcat, I believe everything got double quoted, regardless of version on the cookie. v0 cookies, the spec says /NAME/=/VALUE/ This string is a sequence of characters excluding semi-colon, comma and white space. If there is a need to place such data in the name or value, some encoding method such as URL style %XX encoding is recommended, though no encoding is defined or required. the problem was that encoding wasn't defined nor required. so when we followed the spec, and added %XX encoding, TCK tests failed. at this point I would say, we handle cookies correctly. if one needs == at the end of the cookie, then they need to use v1 cookies, according to spec Filip Remy Maucherat wrote: On Sat, 2008-02-09 at 13:03 +, Mark Thomas wrote: Maik Jablonski wrote: Hi, I've just encountered that Cookies seem to be a little bit broken in 6.0.16. If you want to read a cookie which ends on one or more equals-sign (=), the equals-signs are removed by Tomcat when the cookie is read. Is it a bug or a undocumented change? It is neither. The changes are documented in the change log. As a result of a couple of minor security issues (see http://tomcat.apache.org/security-6.html) the cookie handling code has been tightened up to make it spec compliant. By default the servlet spec uses version 0 cookies. The name value pairs are defined as: spec-quote NAME=VALUE This string is a sequence of characters excluding semi-colon, comma and white space. If there is a need to place such data in the name or value, some encoding method such as URL style %XX encoding is recommended, though no encoding is defined or required. /spec-quote The difficulty here is that although '=' is the delimiter between NAME and VALUE there is no need to encode it if it appears in the name or the value. This causes some ambiguities when parsing a header of the form: Set-Cookie: foo=bar=bartoo Is the name 'foo' or 'foo=bar'? Is the value 'bar=bartoo' or 'bartoo'? The changes to the cookie parsing mean the second '=' and any text beyond it are now ignored. If you set the cookie version to 1 then the quoting will be applied where necessary and your example will work as you intend. It seems to me like an annoying regression. response.addCookie(new Cookie(test_cookie3, 123===)) looks like something which should be working. Are you sure there's nothing that could be done about it ? Maybe some additional encoding for '=' when not quoting ? Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cookies are broken in 6.0.16?
actually not, in previous version, we double quoted v0 cookies, and so browsers treated them as v1 in terms of value any sort of encoding attempt we made was miserable between different browsers. filip Jim Manico wrote: Filip, Would you consider auto-encoding only = and ; in the cookie value, but leaving everything else alone for v0 cookies? Would this possibly pass TCK? - Jim no regression, if you do this c = new javax.servlet.http.Cookie(abcv1,123==); c.setVersion(1); response.addCookie(c); then it works just fine. however, if you do c = new javax.servlet.http.Cookie(abcv0,123==); response.addCookie(c); then it doesn't. if we encode it, (which we did at our first attempt for v0 cookies) we actually don't pass the TCK. only v1 cookies should be double quoted, in previous versions of tomcat, I believe everything got double quoted, regardless of version on the cookie. v0 cookies, the spec says /NAME/=/VALUE/ This string is a sequence of characters excluding semi-colon, comma and white space. If there is a need to place such data in the name or value, some encoding method such as URL style %XX encoding is recommended, though no encoding is defined or required. the problem was that encoding wasn't defined nor required. so when we followed the spec, and added %XX encoding, TCK tests failed. at this point I would say, we handle cookies correctly. if one needs == at the end of the cookie, then they need to use v1 cookies, according to spec Filip Remy Maucherat wrote: On Sat, 2008-02-09 at 13:03 +, Mark Thomas wrote: Maik Jablonski wrote: Hi, I've just encountered that Cookies seem to be a little bit broken in 6.0.16. If you want to read a cookie which ends on one or more equals-sign (=), the equals-signs are removed by Tomcat when the cookie is read. Is it a bug or a undocumented change? It is neither. The changes are documented in the change log. As a result of a couple of minor security issues (see http://tomcat.apache.org/security-6.html) the cookie handling code has been tightened up to make it spec compliant. By default the servlet spec uses version 0 cookies. The name value pairs are defined as: spec-quote NAME=VALUE This string is a sequence of characters excluding semi-colon, comma and white space. If there is a need to place such data in the name or value, some encoding method such as URL style %XX encoding is recommended, though no encoding is defined or required. /spec-quote The difficulty here is that although '=' is the delimiter between NAME and VALUE there is no need to encode it if it appears in the name or the value. This causes some ambiguities when parsing a header of the form: Set-Cookie: foo=bar=bartoo Is the name 'foo' or 'foo=bar'? Is the value 'bar=bartoo' or 'bartoo'? The changes to the cookie parsing mean the second '=' and any text beyond it are now ignored. If you set the cookie version to 1 then the quoting will be applied where necessary and your example will work as you intend. It seems to me like an annoying regression. response.addCookie(new Cookie(test_cookie3, 123===)) looks like something which should be working. Are you sure there's nothing that could be done about it ? Maybe some additional encoding for '=' when not quoting ? Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cookies are broken in 6.0.16?
On Sat, 2008-02-09 at 16:14 -0700, Filip Hanik - Dev Lists wrote: no regression, if you do this c = new javax.servlet.http.Cookie(abcv1,123==); c.setVersion(1); response.addCookie(c); then it works just fine. however, if you do c = new javax.servlet.http.Cookie(abcv0,123==); response.addCookie(c); then it doesn't. if we encode it, (which we did at our first attempt for v0 cookies) we actually don't pass the TCK. only v1 cookies should be double quoted, in previous versions of tomcat, I believe everything got double quoted, regardless of version on the cookie. v0 cookies, the spec says /NAME/=/VALUE/ This string is a sequence of characters excluding semi-colon, comma and white space. If there is a need to place such data in the name or value, some encoding method such as URL style %XX encoding is recommended, though no encoding is defined or required. the problem was that encoding wasn't defined nor required. so when we followed the spec, and added %XX encoding, TCK tests failed. at this point I would say, we handle cookies correctly. if one needs == at the end of the cookie, then they need to use v1 cookies, according to spec I find the regressions caused by the new behavior problematic, and it will cause lots of problems with existing applications, since the default cookie version used is version 0. As I'm the only one complaining at the moment, I think I'll take my concerns elsewhere, no problem, I get the idea :) Obviously, when I say encoding, I am not talking about quoting the whole value (or name) as was done before. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cookies are broken in 6.0.16?
What about making //cookies v0 c = new javax.servlet.http.Cookie(abcv0,123==); response.addCookie(c); At least throw some kind of malformedCookieData exception instead of just failing gracefully to accelerate programmers ability to upgrade legacy systems? - Jim On Sat, 2008-02-09 at 16:14 -0700, Filip Hanik - Dev Lists wrote: no regression, if you do this c = new javax.servlet.http.Cookie(abcv1,123==); c.setVersion(1); response.addCookie(c); then it works just fine. however, if you do c = new javax.servlet.http.Cookie(abcv0,123==); response.addCookie(c); then it doesn't. if we encode it, (which we did at our first attempt for v0 cookies) we actually don't pass the TCK. only v1 cookies should be double quoted, in previous versions of tomcat, I believe everything got double quoted, regardless of version on the cookie. v0 cookies, the spec says /NAME/=/VALUE/ This string is a sequence of characters excluding semi-colon, comma and white space. If there is a need to place such data in the name or value, some encoding method such as URL style %XX encoding is recommended, though no encoding is defined or required. the problem was that encoding wasn't defined nor required. so when we followed the spec, and added %XX encoding, TCK tests failed. at this point I would say, we handle cookies correctly. if one needs == at the end of the cookie, then they need to use v1 cookies, according to spec I find the regressions caused by the new behavior problematic, and it will cause lots of problems with existing applications, since the default cookie version used is version 0. As I'm the only one complaining at the moment, I think I'll take my concerns elsewhere, no problem, I get the idea :) Obviously, when I say encoding, I am not talking about quoting the whole value (or name) as was done before. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cookies are broken in 6.0.16?
Remy Maucherat wrote: On Sat, 2008-02-09 at 16:14 -0700, Filip Hanik - Dev Lists wrote: no regression, if you do this c = new javax.servlet.http.Cookie(abcv1,123==); c.setVersion(1); response.addCookie(c); then it works just fine. however, if you do c = new javax.servlet.http.Cookie(abcv0,123==); response.addCookie(c); then it doesn't. if we encode it, (which we did at our first attempt for v0 cookies) we actually don't pass the TCK. only v1 cookies should be double quoted, in previous versions of tomcat, I believe everything got double quoted, regardless of version on the cookie. v0 cookies, the spec says /NAME/=/VALUE/ This string is a sequence of characters excluding semi-colon, comma and white space. If there is a need to place such data in the name or value, some encoding method such as URL style %XX encoding is recommended, though no encoding is defined or required. the problem was that encoding wasn't defined nor required. so when we followed the spec, and added %XX encoding, TCK tests failed. at this point I would say, we handle cookies correctly. if one needs == at the end of the cookie, then they need to use v1 cookies, according to spec I find the regressions caused by the new behavior problematic, and it will cause lots of problems with existing applications, since the default cookie version used is version 0. As I'm the only one complaining at the moment, I think I'll take my concerns elsewhere, no problem, I get the idea :) Obviously, when I say encoding, I am not talking about quoting the whole value (or name) as was done before. as always, I'm open to suggestions. it'd be easier if you suggested something. here is the javadoc for the servlet spec setValue public void *setValue*(String http://java.sun.com/j2se/1.5/docs/api/java/lang/String.html newValue) Assigns a new value to a cookie after the cookie is created. If you use a binary value, you may want to use BASE64 encoding. With Version 0 cookies, values should not contain white space, brackets, parentheses, equals signs, commas, double quotes, slashes, question marks, at signs, colons, and semicolons. Empty values may not behave the same way on all browsers. *Parameters:* |newValue| - a |String| specifying the new value *See Also:* |getValue()| http://java.sun.com/javaee/5/docs/api/javax/servlet/http/Cookie.html#getValue%28%29, |Cookie| http://java.sun.com/javaee/5/docs/api/javax/servlet/http/Cookie.html I guess we could throw a run time exception if the value contained any of those. other than that, I'm not sure how to behave Filip Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cookies are broken in 6.0.16?
Remy Maucherat wrote: On Sat, 2008-02-09 at 16:14 -0700, Filip Hanik - Dev Lists wrote: no regression, if you do this c = new javax.servlet.http.Cookie(abcv1,123==); c.setVersion(1); response.addCookie(c); then it works just fine. however, if you do c = new javax.servlet.http.Cookie(abcv0,123==); response.addCookie(c); then it doesn't. if we encode it, (which we did at our first attempt for v0 cookies) we actually don't pass the TCK. only v1 cookies should be double quoted, in previous versions of tomcat, I believe everything got double quoted, regardless of version on the cookie. v0 cookies, the spec says /NAME/=/VALUE/ This string is a sequence of characters excluding semi-colon, comma and white space. If there is a need to place such data in the name or value, some encoding method such as URL style %XX encoding is recommended, though no encoding is defined or required. the problem was that encoding wasn't defined nor required. so when we followed the spec, and added %XX encoding, TCK tests failed. at this point I would say, we handle cookies correctly. if one needs == at the end of the cookie, then they need to use v1 cookies, according to spec I find the regressions caused by the new behavior problematic, and it will cause lots of problems with existing applications, since the default cookie version used is version 0. As I'm the only one complaining at the moment, I think I'll take my concerns elsewhere, no problem, I get the idea :) Obviously, when I say encoding, I am not talking about quoting the whole value (or name) as was done before. we did try the %XX encoding, browsers don't like it and don't behave properly. Filip Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cookies are broken in 6.0.16?
I guess we could throw a run time exception if the value contained any of those. other than that, I'm not sure how to behave I think this is the best case scenario for v0 cookies. Perhaps, if you really want to get fancy, you can add a flag to let legacy solutions roll back to the old/non-standard cookie handling methodology? - Jim Remy Maucherat wrote: On Sat, 2008-02-09 at 16:14 -0700, Filip Hanik - Dev Lists wrote: no regression, if you do this c = new javax.servlet.http.Cookie(abcv1,123==); c.setVersion(1); response.addCookie(c); then it works just fine. however, if you do c = new javax.servlet.http.Cookie(abcv0,123==); response.addCookie(c); then it doesn't. if we encode it, (which we did at our first attempt for v0 cookies) we actually don't pass the TCK. only v1 cookies should be double quoted, in previous versions of tomcat, I believe everything got double quoted, regardless of version on the cookie. v0 cookies, the spec says /NAME/=/VALUE/ This string is a sequence of characters excluding semi-colon, comma and white space. If there is a need to place such data in the name or value, some encoding method such as URL style %XX encoding is recommended, though no encoding is defined or required. the problem was that encoding wasn't defined nor required. so when we followed the spec, and added %XX encoding, TCK tests failed. at this point I would say, we handle cookies correctly. if one needs == at the end of the cookie, then they need to use v1 cookies, according to spec I find the regressions caused by the new behavior problematic, and it will cause lots of problems with existing applications, since the default cookie version used is version 0. As I'm the only one complaining at the moment, I think I'll take my concerns elsewhere, no problem, I get the idea :) Obviously, when I say encoding, I am not talking about quoting the whole value (or name) as was done before. as always, I'm open to suggestions. it'd be easier if you suggested something. here is the javadoc for the servlet spec setValue public void *setValue*(String http://java.sun.com/j2se/1.5/docs/api/java/lang/String.html newValue) Assigns a new value to a cookie after the cookie is created. If you use a binary value, you may want to use BASE64 encoding. With Version 0 cookies, values should not contain white space, brackets, parentheses, equals signs, commas, double quotes, slashes, question marks, at signs, colons, and semicolons. Empty values may not behave the same way on all browsers. *Parameters:* |newValue| - a |String| specifying the new value *See Also:* |getValue()| http://java.sun.com/javaee/5/docs/api/javax/servlet/http/Cookie.html#getValue%28%29, |Cookie| http://java.sun.com/javaee/5/docs/api/javax/servlet/http/Cookie.html I guess we could throw a run time exception if the value contained any of those. other than that, I'm not sure how to behave Filip Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cookies are broken in 6.0.16?
Jim Manico wrote: I guess we could throw a run time exception if the value contained any of those. other than that, I'm not sure how to behave I think this is the best case scenario for v0 cookies. Perhaps, if you really want to get fancy, you can add a flag to let legacy solutions roll back to the old/non-standard cookie handling methodology? no, we wont do that. we fixed the cookie behavior in this release due to security issues filed against the old parsing. Filip - Jim Remy Maucherat wrote: On Sat, 2008-02-09 at 16:14 -0700, Filip Hanik - Dev Lists wrote: no regression, if you do this c = new javax.servlet.http.Cookie(abcv1,123==); c.setVersion(1); response.addCookie(c); then it works just fine. however, if you do c = new javax.servlet.http.Cookie(abcv0,123==); response.addCookie(c); then it doesn't. if we encode it, (which we did at our first attempt for v0 cookies) we actually don't pass the TCK. only v1 cookies should be double quoted, in previous versions of tomcat, I believe everything got double quoted, regardless of version on the cookie. v0 cookies, the spec says /NAME/=/VALUE/ This string is a sequence of characters excluding semi-colon, comma and white space. If there is a need to place such data in the name or value, some encoding method such as URL style %XX encoding is recommended, though no encoding is defined or required. the problem was that encoding wasn't defined nor required. so when we followed the spec, and added %XX encoding, TCK tests failed. at this point I would say, we handle cookies correctly. if one needs == at the end of the cookie, then they need to use v1 cookies, according to spec I find the regressions caused by the new behavior problematic, and it will cause lots of problems with existing applications, since the default cookie version used is version 0. As I'm the only one complaining at the moment, I think I'll take my concerns elsewhere, no problem, I get the idea :) Obviously, when I say encoding, I am not talking about quoting the whole value (or name) as was done before. as always, I'm open to suggestions. it'd be easier if you suggested something. here is the javadoc for the servlet spec setValue public void *setValue*(String http://java.sun.com/j2se/1.5/docs/api/java/lang/String.html newValue) Assigns a new value to a cookie after the cookie is created. If you use a binary value, you may want to use BASE64 encoding. With Version 0 cookies, values should not contain white space, brackets, parentheses, equals signs, commas, double quotes, slashes, question marks, at signs, colons, and semicolons. Empty values may not behave the same way on all browsers. *Parameters:* |newValue| - a |String| specifying the new value *See Also:* |getValue()| http://java.sun.com/javaee/5/docs/api/javax/servlet/http/Cookie.html#getValue%28%29, |Cookie| http://java.sun.com/javaee/5/docs/api/javax/servlet/http/Cookie.html I guess we could throw a run time exception if the value contained any of those. other than that, I'm not sure how to behave Filip Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cookies are broken in 6.0.16?
we fixed the cookie behavior in this release due to security issues filed against the old parsing. Gotchya, Filip. Makes sense. What about the Runtime exception? That might at least allow legacy systems to debug this problem fast. Fail Quietly doesn't seem like a good solution. - Jim Jim Manico wrote: I guess we could throw a run time exception if the value contained any of those. other than that, I'm not sure how to behave I think this is the best case scenario for v0 cookies. Perhaps, if you really want to get fancy, you can add a flag to let legacy solutions roll back to the old/non-standard cookie handling methodology? no, we wont do that. we fixed the cookie behavior in this release due to security issues filed against the old parsing. Filip - Jim Remy Maucherat wrote: On Sat, 2008-02-09 at 16:14 -0700, Filip Hanik - Dev Lists wrote: no regression, if you do this c = new javax.servlet.http.Cookie(abcv1,123==); c.setVersion(1); response.addCookie(c); then it works just fine. however, if you do c = new javax.servlet.http.Cookie(abcv0,123==); response.addCookie(c); then it doesn't. if we encode it, (which we did at our first attempt for v0 cookies) we actually don't pass the TCK. only v1 cookies should be double quoted, in previous versions of tomcat, I believe everything got double quoted, regardless of version on the cookie. v0 cookies, the spec says /NAME/=/VALUE/ This string is a sequence of characters excluding semi-colon, comma and white space. If there is a need to place such data in the name or value, some encoding method such as URL style %XX encoding is recommended, though no encoding is defined or required. the problem was that encoding wasn't defined nor required. so when we followed the spec, and added %XX encoding, TCK tests failed. at this point I would say, we handle cookies correctly. if one needs == at the end of the cookie, then they need to use v1 cookies, according to spec I find the regressions caused by the new behavior problematic, and it will cause lots of problems with existing applications, since the default cookie version used is version 0. As I'm the only one complaining at the moment, I think I'll take my concerns elsewhere, no problem, I get the idea :) Obviously, when I say encoding, I am not talking about quoting the whole value (or name) as was done before. as always, I'm open to suggestions. it'd be easier if you suggested something. here is the javadoc for the servlet spec setValue public void *setValue*(String http://java.sun.com/j2se/1.5/docs/api/java/lang/String.html newValue) Assigns a new value to a cookie after the cookie is created. If you use a binary value, you may want to use BASE64 encoding. With Version 0 cookies, values should not contain white space, brackets, parentheses, equals signs, commas, double quotes, slashes, question marks, at signs, colons, and semicolons. Empty values may not behave the same way on all browsers. *Parameters:* |newValue| - a |String| specifying the new value *See Also:* |getValue()| http://java.sun.com/javaee/5/docs/api/javax/servlet/http/Cookie.html#getValue%28%29, |Cookie| http://java.sun.com/javaee/5/docs/api/javax/servlet/http/Cookie.html I guess we could throw a run time exception if the value contained any of those. other than that, I'm not sure how to behave Filip Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cookies are broken in 6.0.16?
Or log a really noisy, loud error so you know what's going on at least Jim Manico wrote: we fixed the cookie behavior in this release due to security issues filed against the old parsing. Gotchya, Filip. Makes sense. What about the Runtime exception? That might at least allow legacy systems to debug this problem fast. Fail Quietly doesn't seem like a good solution. - Jim Jim Manico wrote: I guess we could throw a run time exception if the value contained any of those. other than that, I'm not sure how to behave I think this is the best case scenario for v0 cookies. Perhaps, if you really want to get fancy, you can add a flag to let legacy solutions roll back to the old/non-standard cookie handling methodology? no, we wont do that. we fixed the cookie behavior in this release due to security issues filed against the old parsing. Filip - Jim Remy Maucherat wrote: On Sat, 2008-02-09 at 16:14 -0700, Filip Hanik - Dev Lists wrote: no regression, if you do this c = new javax.servlet.http.Cookie(abcv1,123==); c.setVersion(1); response.addCookie(c); then it works just fine. however, if you do c = new javax.servlet.http.Cookie(abcv0,123==); response.addCookie(c); then it doesn't. if we encode it, (which we did at our first attempt for v0 cookies) we actually don't pass the TCK. only v1 cookies should be double quoted, in previous versions of tomcat, I believe everything got double quoted, regardless of version on the cookie. v0 cookies, the spec says /NAME/=/VALUE/ This string is a sequence of characters excluding semi-colon, comma and white space. If there is a need to place such data in the name or value, some encoding method such as URL style %XX encoding is recommended, though no encoding is defined or required. the problem was that encoding wasn't defined nor required. so when we followed the spec, and added %XX encoding, TCK tests failed. at this point I would say, we handle cookies correctly. if one needs == at the end of the cookie, then they need to use v1 cookies, according to spec I find the regressions caused by the new behavior problematic, and it will cause lots of problems with existing applications, since the default cookie version used is version 0. As I'm the only one complaining at the moment, I think I'll take my concerns elsewhere, no problem, I get the idea :) Obviously, when I say encoding, I am not talking about quoting the whole value (or name) as was done before. as always, I'm open to suggestions. it'd be easier if you suggested something. here is the javadoc for the servlet spec setValue public void *setValue*(String http://java.sun.com/j2se/1.5/docs/api/java/lang/String.html newValue) Assigns a new value to a cookie after the cookie is created. If you use a binary value, you may want to use BASE64 encoding. With Version 0 cookies, values should not contain white space, brackets, parentheses, equals signs, commas, double quotes, slashes, question marks, at signs, colons, and semicolons. Empty values may not behave the same way on all browsers. *Parameters:* |newValue| - a |String| specifying the new value *See Also:* |getValue()| http://java.sun.com/javaee/5/docs/api/javax/servlet/http/Cookie.html#getValue%28%29, |Cookie| http://java.sun.com/javaee/5/docs/api/javax/servlet/http/Cookie.html I guess we could throw a run time exception if the value contained any of those. other than that, I'm not sure how to behave Filip Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Cookies are broken in 6.0.16?
Hi,
I've just encountered that Cookies seem to be a little bit broken in
6.0.16. If you want to read a cookie which ends on one or more
equals-sign (=), the equals-signs are removed by Tomcat when the
cookie is read.
If you run the following example, you'll see, that the test_cookies
are stored correctly on the browser, but when read out by the next
request, the equals-signs are missing in the cookie-value.
Is it a bug or a undocumented change?
Cheers, Maik
import javax.servlet.http.Cookie;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
public class SimpleServlet extends HttpServlet {
public void doGet(HttpServletRequest request, HttpServletResponse
response) {
for (Cookie cookie : request.getCookies()) {
System.out.println(cookie.getName() + : +
cookie.getValue());
}
response.addCookie(new Cookie(test_cookie1, 123=));
response.addCookie(new Cookie(test_cookie2, 123==));
response.addCookie(new Cookie(test_cookie3, 123===));
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
