Pid wrote:
Mark Thomas wrote:
Maik Jablonski wrote:
Hi,

I've just encountered that Cookies seem to be a little bit broken in
6.0.16. If you want to read a cookie which ends on one or more
equals-sign (=), the equals-signs are removed by Tomcat when the
cookie is read.

Is it a bug or a "undocumented" change?

It is neither. The changes are documented in the change log. As a result of
a couple of minor security issues (see
http://tomcat.apache.org/security-6.html) the cookie handling code has been
tightened up to make it spec compliant.

By default the servlet spec uses version 0 cookies. The name value pairs
are defined as:
<spec-quote>
NAME=VALUE
This string is a sequence of characters excluding semi-colon, comma and
white space. If there is a need to place such data in the name or value,
some encoding method such as URL style %XX encoding is recommended, though
no encoding is defined or required.
</spec-quote>

The difficulty here is that although '=' is the delimiter between NAME and VALUE there is no need to encode it if it appears in the name or the value.
This causes some ambiguities when parsing a header of the form:
Set-Cookie: foo=bar=bartoo

Is the name 'foo' or 'foo=bar'? Is the value 'bar=bartoo' or 'bartoo'?

The changes to the cookie parsing mean the second '=' and any text beyond
it are now ignored.

If you set the cookie version to 1 then the quoting will be applied where
necessary and your example will work as you intend.

I have an installation that receives callbacks from 3DSecure enabled banking systems, ie Verified by Visa and Mastercard SecureCode.

The parameter values submitted in the callback to our system frequently have double equals symbols at the end of the parameter data '...s83jkd9=='.

Attempting to upgrade from 6.0.10 to 6.0.16 caused the servlet that receives the callback to see no parameters submitted.

I have not satisfied myself yet that there are no other problems, as it was my intention to do so in the coming week, but the above sounds like a reasonable explanation for the apparent fault.

Thoughts or comments?

In fact, please ignore, until requested otherwise.

p


p







Mark



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




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




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

Reply via email to