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