Re: Cookies are broken in 6.0.16?

[Mark Thomas]

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:

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 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?

[Pid]

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:

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 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?

[Maik Jablonski]

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]

svn commit: r620157 - /tomcat/connectors/tags/other/TOMCAT_NATIVE_1_1_13/

[jfclere]

Author: jfclere
Date: Sat Feb  9 09:16:39 2008
New Revision: 620157

URL: http://svn.apache.org/viewvc?rev=620157&view=rev
Log:
tag 1.1.13 tc-native.

Added:
tomcat/connectors/tags/other/TOMCAT_NATIVE_1_1_13/
  - copied from r620156, tomcat/connectors/trunk/


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r620156 - /tomcat/connectors/trunk/jni/jnirelease.sh

[jfclere]

Author: jfclere
Date: Sat Feb  9 09:15:01 2008
New Revision: 620156

URL: http://svn.apache.org/viewvc?rev=620156&view=rev
Log:
Ready for tag ;-)

Modified:
tomcat/connectors/trunk/jni/jnirelease.sh

Modified: tomcat/connectors/trunk/jni/jnirelease.sh
URL: 
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jni/jnirelease.sh?rev=620156&r1=620155&r2=620156&view=diff
==
--- tomcat/connectors/trunk/jni/jnirelease.sh (original)
+++ tomcat/connectors/trunk/jni/jnirelease.sh Sat Feb  9 09:15:01 2008
@@ -50,10 +50,10 @@
 
 # Replace JKJNIEXT with branch/or tag
 # and JKJNIVER by the version like 1.1.0
-JKJNIEXT="trunk"
-JKJNIVER="current"
-# JKJNIEXT="tags/other/TOMCAT_NATIVE_1_1_10"
-# JKJNIVER="1.1.10"
+#JKJNIEXT="trunk"
+#JKJNIVER="current"
+JKJNIEXT="tags/other/TOMCAT_NATIVE_1_1_13"
+JKJNIVER="1.1.13"
 SVNBASE=https://svn.apache.org/repos/asf/tomcat/connectors/
 JKJNIDIST=tomcat-native-${JKJNIVER}-src
 rm -rf ${JKJNIDIST}



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

tomcat native documentation

[jean-frederic clere]

Hi,

I have prepared a doc for the tomcat native library.

http://people.apache.org/~jfclere/tc-native-docs/

The idea is to add it like http://tomcat.apache.org/tc-native-docs

Comments?

Cheers

Jean-Frederic

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[VOTE] Release tc-native 1.1.13

[jean-frederic clere]

The candidates binaries are available here:
http://people.apache.org/~jfclere/tcnative/v1.1.13/

According to the release process, the 1.1.13 tag is:
[ ] Broken
[ ] Alpha
[ ] Beta
[ ] Stable


Cheers

Jean-Frederic

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Release tc-native 1.1.13

[Filip Hanik - Dev Lists]

According to the release process, the 1.1.13 tag is:
[ ] Broken
[ ] Alpha
[ ] Beta
[X] Stable


Filip

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 44383] - Possible leak: tomcat does not release Jasper compilation contexts

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=44383


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID




--- Additional Comments From [EMAIL PROTECTED]  2008-02-09 10:09 ---
Lots of objects does not mean you have a memory leak. I have checked compilation
and execution for jsps and tags with and without re-loads and can't find any
memory leaks.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Cookies are broken in 6.0.16?

[Pid]

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:

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 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]

svn commit: r620173 - in /tomcat: container/branches/tc4.1.x/ container/branches/tc4.1.x/catalina/src/share/org/apache/catalina/core/ container/branches/tc4.1.x/catalina/src/share/org/apache/catalina/

[markt]

Author: markt
Date: Sat Feb  9 10:45:05 2008
New Revision: 620173

URL: http://svn.apache.org/viewvc?rev=620173&view=rev
Log:
Add support for system property replacement.

Modified:
tomcat/container/branches/tc4.1.x/RELEASE-NOTES-4.1.txt

tomcat/container/branches/tc4.1.x/catalina/src/share/org/apache/catalina/core/StandardHostDeployer.java

tomcat/container/branches/tc4.1.x/catalina/src/share/org/apache/catalina/startup/Catalina.java

tomcat/container/branches/tc4.1.x/catalina/src/share/org/apache/catalina/startup/HostConfig.java
tomcat/current/tc4.1.x/STATUS.txt

Modified: tomcat/container/branches/tc4.1.x/RELEASE-NOTES-4.1.txt
URL: 
http://svn.apache.org/viewvc/tomcat/container/branches/tc4.1.x/RELEASE-NOTES-4.1.txt?rev=620173&r1=620172&r2=620173&view=diff
==
--- tomcat/container/branches/tc4.1.x/RELEASE-NOTES-4.1.txt (original)
+++ tomcat/container/branches/tc4.1.x/RELEASE-NOTES-4.1.txt Sat Feb  9 10:45:05 
2008
@@ -302,6 +302,9 @@
  Startup scripts
  Provide greater control over redirection of stdout and stderr
 
+[4.1.37] Configuration files
+ Add support for system property replacement in configuration files
+
 
 ---
 Jasper New Features:

Modified: 
tomcat/container/branches/tc4.1.x/catalina/src/share/org/apache/catalina/core/StandardHostDeployer.java
URL: 
http://svn.apache.org/viewvc/tomcat/container/branches/tc4.1.x/catalina/src/share/org/apache/catalina/core/StandardHostDeployer.java?rev=620173&r1=620172&r2=620173&view=diff
==
--- 
tomcat/container/branches/tc4.1.x/catalina/src/share/org/apache/catalina/core/StandardHostDeployer.java
 (original)
+++ 
tomcat/container/branches/tc4.1.x/catalina/src/share/org/apache/catalina/core/StandardHostDeployer.java
 Sat Feb  9 10:45:05 2008
@@ -23,6 +23,7 @@
 import java.io.InputStream;
 import java.io.IOException;
 import java.net.URL;
+import java.util.Map;
 import org.apache.catalina.Container;
 import org.apache.catalina.Context;
 import org.apache.catalina.Deployer;
@@ -36,6 +37,9 @@
 import org.apache.catalina.startup.NamingRuleSet;
 import org.apache.catalina.util.StringManager;
 import org.apache.commons.digester.Digester;
+import org.apache.commons.digester.Substitutor;
+import org.apache.commons.digester.substitution.VariableSubstitutor;
+import org.apache.commons.digester.substitution.MultiVariableExpander;
 
 
 /**
@@ -680,6 +684,23 @@
 
 
 /**
+ * Adds a substitutor to interpolate system properties
+ *
+ * @param digester The digester to which we add the substitutor
+ */
+protected void enableDigesterSubstitutor(Digester digester)
+{
+Map systemProperties = System.getProperties();
+MultiVariableExpander expander = new MultiVariableExpander();
+expander.addSource("$", systemProperties);
+
+// allow expansion in both xml attributes and element text
+Substitutor substitutor = new VariableSubstitutor(expander);
+digester.setSubstitutor(substitutor);
+}
+
+
+/**
  * Create (if necessary) and return a Digester configured to process the
  * context configuration descriptor for an application.
  */
@@ -690,6 +711,8 @@
 if (host.getDebug() > 0)
 digester.setDebug(3);
 digester.setValidating(false);
+// Add a substitutor to resolve system properties
+enableDigesterSubstitutor(digester);
 contextRuleSet = new ContextRuleSet("");
 digester.addRuleSet(contextRuleSet);
 namingRuleSet = new NamingRuleSet("Context/");

Modified: 
tomcat/container/branches/tc4.1.x/catalina/src/share/org/apache/catalina/startup/Catalina.java
URL: 
http://svn.apache.org/viewvc/tomcat/container/branches/tc4.1.x/catalina/src/share/org/apache/catalina/startup/Catalina.java?rev=620173&r1=620172&r2=620173&view=diff
==
--- 
tomcat/container/branches/tc4.1.x/catalina/src/share/org/apache/catalina/startup/Catalina.java
 (original)
+++ 
tomcat/container/branches/tc4.1.x/catalina/src/share/org/apache/catalina/startup/Catalina.java
 Sat Feb  9 10:45:05 2008
@@ -25,6 +25,7 @@
 import java.io.OutputStream;
 import java.net.Socket;
 import java.security.Security;
+import java.util.Map;
 import org.apache.catalina.Container;
 import org.apache.catalina.Lifecycle;
 import org.apache.catalina.LifecycleException;
@@ -32,6 +33,9 @@
 import org.apache.catalina.core.StandardServer;
 import org.apache.commons.digester.Digester;
 import org.apache.commons.digester.Rule;
+import org.apache.commons.digester.Substitutor;
+import org.apache.commons.digester.substitution.VariableSubstitutor;
+import org.apache.commons.digester.substitution.MultiVariableExpander;
 import org.apache.tomcat.util.log.SystemLogHandler;
 import org.xml.sa

svn commit: r620171 - /tomcat/tc6.0.x/trunk/STATUS.txt

[markt]

Author: markt
Date: Sat Feb  9 10:35:15 2008
New Revision: 620171

URL: http://svn.apache.org/viewvc?rev=620171&view=rev
Log:
vote

Modified:
tomcat/tc6.0.x/trunk/STATUS.txt

Modified: tomcat/tc6.0.x/trunk/STATUS.txt
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/STATUS.txt?rev=620171&r1=620170&r2=620171&view=diff
==
--- tomcat/tc6.0.x/trunk/STATUS.txt (original)
+++ tomcat/tc6.0.x/trunk/STATUS.txt Sat Feb  9 10:35:15 2008
@@ -84,10 +84,10 @@
 
 * Handle case of NIO/SSL when transferring bytes to a disconnected socket
   http://svn.apache.org/viewvc?rev=618420&view=rev
-  +1: fhanik
+  +1: fhanik, markt
   -1: 
   
 * Use a single lock for synchronized session manipulation
   http://svn.apache.org/viewvc?rev=618823&view=rev
-  +1: fhanik
+  +1: fhanik, markt
   -1: 



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: tomcat native documentation

[Henri Gomez]

Good.

Just a point :

INFO: Loaded APR based Apache Tomcat Native library 1.1.12.

==>

INFO: Loaded APR based Apache Tomcat Native library 1.1.13.

:-)

2008/2/9, jean-frederic clere <[EMAIL PROTECTED]>:
> Hi,
>
> I have prepared a doc for the tomcat native library.
>
> http://people.apache.org/~jfclere/tc-native-docs/
>
> The idea is to add it like http://tomcat.apache.org/tc-native-docs
>
> Comments?
>
> Cheers
>
> Jean-Frederic
>
> -
> 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]

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:
> 
> 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 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?

[Jim Manico]

>   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:

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 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?

[Filip Hanik - Dev Lists]

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:

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 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?

[Jim Manico]

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:

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 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?

[Filip Hanik - Dev Lists]

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:

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 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?

[Remy Maucherat]

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?

[Jim Manico]

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?

[Filip Hanik - Dev Lists]

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 
 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()|
   
,
   |Cookie|
   


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?

[Filip Hanik - Dev Lists]

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?

[Jim Manico]

> 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 
 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()|
   
, 


   |Cookie|
   




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]

DO NOT REPLY [Bug 44383] - Possible leak: tomcat does not release Jasper compilation contexts

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=44383





--- Additional Comments From [EMAIL PROTECTED]  2008-02-09 18:46 ---
Maybe it is not a leak in the sense of unlimited growth because they are -maybe-
unreferenced -and substituted- in the next compilation of the JSP (I don't
know). Let's say it could be a big bunch of unneeded objects.

Do you mean that you have not found the class of objects I mention? If not, I
understand that I must provide a verifiable test case. But if you have found
those objects, do you think it is ok, provided they are only needed to compile
JSPs??

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
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]

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 
 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()|
   
, 


   |Cookie|
   




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?

[Jim Manico]

> 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 
 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()|
   
, 


   |Cookie|
   




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?

[Jess Holle]

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 
 
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()|
   
, 


   |Cookie|
   




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]