[ https://jira.jboss.org/jira/browse/JBAS-7372?page=com.atlassian.jira.plug... ] Darryl Miles commented on JBAS-7372: ------------------------------------ http://svn.apache.org/repos/asf/tomcat/tc6.0.x/trunk/java/org/apache/tomc... looks like where the action happens in particular . In particular org.apache.tomcat.util.http.Cookies#processCookieHeader(byte bytes[], int off, int len) To the reporter, can you cite some ASP.NET cookie examples from both the ASP.NET end (the original) and what you see using Servlet Spec APIs cookie access function. Can you also generate many ASP.NET cookies and see if the character "/" is ever used in them, this is a standard base64 character set is: ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/ The "/" slash is considered illegal, so maybe ASP.NET substitutes it for another character ? It would be good to rule that issue out. The "=" character is the base64 end padding character. Not part of the character-set as such since it does not represent any data but merely used to pad and is usually present (if at all) at the end of the base64 string. I guess since the "/" is an illegal character for historic compatibility reasons that ASP.NET must be using a modified/non-standard base64 generator, which should not be called base64. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBAS-7372?page=com.atlassian.jira.plug... ] Darryl Miles commented on JBAS-7372: ------------------------------------ Thanks for the examples. Just to close the base64 slash character ("/") usage in the characer-set, the de-facto standard for cookie originated from the following documentation (originally from Netscape browser) : http://web.archive.org/web/*/http://wp.netscape.com/newsref/std/cookie_sp... http://web.archive.org/web/20080411033246/http://wp.netscape.com/newsref/... The implied encoding for the VALUE part of the cookie is "URL encoding", therefore certain characters have reserved/special meaning in URLs. ";" for attribute separator (per path element), "/" for path element separator, etc... Therefore use an unescaped "/" character is considered illegal (by some) for historical backward compatibility reasons. The escaping method cited in the specification was the %XX method, or ASP.NET could have just revised base64 to use "-" instead of "/". However the point is moot since it is not the topic of this bug report. The issue in the bug report is the removal of the "=" characters from the VALUE part of the cookie. This is a bug in Tomcat/JBoss due to the way it tokenized the incoming cookie string. The specification above specifically states that semi-colon, comma and white space may not be inside the value (since they have special meaning / special handling). So there is no ambiguity that those character would need encoding if they are present in the VALUE part of the cookie. So the use of the "=" character falls into the question of, "Does any HTTP Cookie specification update specifically prohibit the EQUALS ("=") character from appearing unencoded in the VALUE part of the cookie?" and to that question I shall try to find a reference to a specification update on the original Netscape de-facto specification (in the URL above) for an answer. My hunch is that I shall no find any such prohibition. This would be an opportunity for someone to cite such a claim here. To bear in mind for maximum compatibility, "be strict in what you emit and liberal in what you parse" has been a long standing mantra. I can't think of any argument for why "=" can not appear unencoded in the VALUE part of the cookie. Are you able to test your application with the stock tomcat and confirm the same issue, so that a bug report for TC6 can be opened and looked (and discussed) by the respective parties. This will eventually trickle down into JBAS. The fix in the TC6 tree looks straightforward, simply have a different tokenizer for handling the VALUE part of the cookie that only includes "semi-colon, comma and white space" as token delimiters (still working on the assumption there has been no superseding RFC update on this point). I guess the tokenizer in TC6 is broken and is returning empty strings a couple of times for the sequence "==" instead of allowing them to be included in the VALUE part of the cookie data. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBAS-7372?page=com.atlassian.jira.plug... ] Sangeetha Radhakrishnan commented on JBAS-7372: ----------------------------------------------- Hi Darryl, Thanks for the work-around. Using this work-around temporarly I have fixed the issue. I have done the following as work-around this issue: private String convertToValidBase64Encode(String cookieParam) { switch(cookieParam.length()%4) { case 3: cookieParam=cookieParam+"="; break; case 2: cookieParam=cookieParam+"=="; break; case 1: cookieParam=cookieParam+"==="; break; default: System.out.println("Default: the cookieParam value is--"+cookieParam); } return cookieParam; } I have tried to read the cookie from request object using the latest Tomcat Version 6.0.20 , it did not resolve my issue. The '=' in cookie value got truncated. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira