tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Hanik - Dev Lists <devli...@hanik.com>
Subject Re: Cookies are broken in 6.0.16?
Date Sun, 10 Feb 2008 03:29:26 GMT
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: dev-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>>
>>>
>>>
>>>   
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Mime
View raw message