You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Maik Jablonski <ma...@gmail.com> on 2008/02/09 07:43:09 UTC
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: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Cookies are broken in 6.0.16?
Posted by Pid <p...@pidster.com>.
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: 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
Re: Cookies are broken in 6.0.16?
Posted by Pid <p...@pidster.com>.
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: 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
Re: Cookies are broken in 6.0.16?
Posted by Jim Manico <ji...@manico.net>.
> 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 +0000, 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: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
Re: Cookies are broken in 6.0.16?
Posted by Sven Köhler <sk...@upb.de>.
> 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?
Re: Cookies are broken in 6.0.16?
Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
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: 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
Re: Cookies are broken in 6.0.16?
Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
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: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Cookies are broken in 6.0.16?
Posted by Jim Manico <ji...@manico.net>.
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: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
Re: Cookies are broken in 6.0.16?
Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
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: 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
Re: Cookies are broken in 6.0.16?
Posted by Jim Jagielski <ji...@jaguNET.com>.
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: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Cookies are broken in 6.0.16?
Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
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" <re...@apache.org> wrote in message
> news:1202687816.3338.16.camel@localhost.localdomain...
>
>> On Sun, 2008-02-10 at 23:29 +0000, 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: 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
Re: Cookies are broken in 6.0.16?
Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
Bill Barker wrote:
> "Remy Maucherat" <re...@apache.org> wrote in message
> news:1202687816.3338.16.camel@localhost.localdomain...
>
>> On Sun, 2008-02-10 at 23:29 +0000, 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: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Cookies are broken in 6.0.16?
Posted by Bill Barker <wb...@wilshire.com>.
"Remy Maucherat" <re...@apache.org> wrote in message
news:1202687816.3338.16.camel@localhost.localdomain...
> On Sun, 2008-02-10 at 23:29 +0000, 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: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Cookies are broken in 6.0.16?
Posted by Remy Maucherat <re...@apache.org>.
On Sun, 2008-02-10 at 23:29 +0000, 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: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Cookies are broken in 6.0.16?
Posted by Mark Thomas <ma...@apache.org>.
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: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Cookies are broken in 6.0.16?
Posted by David Jencks <da...@yahoo.com>.
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: 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
Re: Cookies are broken in 6.0.16?
Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
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: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Cookies are broken in 6.0.16?
Posted by Remy Maucherat <re...@apache.org>.
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: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Cookies are broken in 6.0.16?
Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
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: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Cookies are broken in 6.0.16?
Posted by Remy Maucherat <re...@apache.org>.
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: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Cookies are broken in 6.0.16?
Posted by Jim Manico <ji...@manico.net>.
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: 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
Re: Cookies are broken in 6.0.16?
Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
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: 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
Re: Cookies are broken in 6.0.16?
Posted by Mark Thomas <ma...@apache.org>.
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: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Cookies are broken in 6.0.16?
Posted by Jim Manico <ji...@manico.net>.
> 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: 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
Re: Cookies are broken in 6.0.16?
Posted by Remy Maucherat <re...@apache.org>.
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: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Cookies are broken in 6.0.16?
Posted by Jess Holle <je...@ptc.com>.
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: 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
>>
>
>
> ---------------------------------------------------------------------
> 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
Re: Cookies are broken in 6.0.16?
Posted by Jim Manico <ji...@manico.net>.
> 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: 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Cookies are broken in 6.0.16?
Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
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
Re: Cookies are broken in 6.0.16?
Posted by Jim Manico <ji...@manico.net>.
> 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: 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
Re: Cookies are broken in 6.0.16?
Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
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
Re: Cookies are broken in 6.0.16?
Posted by Jim Manico <ji...@manico.net>.
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: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
Re: Cookies are broken in 6.0.16?
Posted by Remy Maucherat <re...@apache.org>.
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: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Cookies are broken in 6.0.16?
Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
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 +0000, 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: 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
Re: Cookies are broken in 6.0.16?
Posted by Jim Manico <ji...@manico.net>.
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 +0000, 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: 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
Re: Cookies are broken in 6.0.16?
Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
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 +0000, 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: 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
Re: Cookies are broken in 6.0.16?
Posted by Remy Maucherat <re...@apache.org>.
On Sat, 2008-02-09 at 13:03 +0000, 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: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Cookies are broken in 6.0.16?
Posted by George Sexton <gs...@mhsoftware.com>.
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: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Cookies are broken in 6.0.16?
Posted by Sven Köhler <sk...@upb.de>.
>> 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 :)
Yes, right, you're 100% right - but this thread is not about v1 cookies.
It's about v0 cookies.
In the case of v0 cookies, we hit the "damn, the spec is messed up -
what should we do?"-case. And in this case, well - what do we do?
What would REALLY be best, is to throw exception upon setting a name or
a value containg the = sign, or spaces, or any illegal characters of
that kind.
Soon, after some future versions of Tomcat, the mailinglist may actually
experience, that people start using names containg the = character,
because chosing the last = character in the cookie for splitting permits
them to do so.
Well, simply make things REALLY safe (throwing exception and the like -
well, does the servlet spec allow to do so? oh my god - i can see it
coming: it doesn't.) Or rather try to immitate the old behaviour as good
as you can without violating the spec, or the TCK test, etc.
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.
So if satisfying users really matters to you, you developers really have
the choice, since the spec gives you that freedom, you really should ...
Re: Cookies are broken in 6.0.16?
Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
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: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Cookies are broken in 6.0.16?
Posted by Sven Köhler <sk...@upb.de>.
> 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.
Re: Cookies are broken in 6.0.16?
Posted by Maik Jablonski <ma...@gmail.com>.
On Feb 9, 2008 2:03 PM, Mark Thomas <ma...@apache.org> 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: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Cookies are broken in 6.0.16?
Posted by Mark Thomas <ma...@apache.org>.
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: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org