[ZCM] [ZC] 2153/ 3 Edit "Unquoted cookies with multiple spaces fail parsing"

[Collector: Zope Bugs, Features, and Patches ...]

Issue #2153 Update (Edit) "Unquoted cookies with multiple spaces fail parsing"
 Status Pending, Zope/bug+solution medium
To followup, visit:
  http://www.zope.org/Collectors/Zope/2153

==============================================================
= Edit - Entry #3 by ajung on Jul 19, 2006 2:10 pm

 Changes: submitter email, importance (critical => medium)
________________________________________
= Comment - Entry #2 by ajung on Jul 19, 2006 2:09 pm

This patch requires a unittest to document the intended behavior.
________________________________________
= Request - Entry #1 by dayne on Jul 19, 2006 1:57 pm


Uploaded:  "HTTPRequest.py.patch"
 - http://www.zope.org/Collectors/Zope/2153/HTTPRequest.py.patch/view
Cookie parsing fails if there is a unquoted cookie defined in the brower, such as a domain cookie, containing multiple spaces.  This was encountered when a Plone site was moved into a production environment where the corporate portal happened to set a pervasive unquoted cookie with multiple spaces.  

The symptom was that when a user authenticates on the site the were redirected to a page that implied they had successrully logged in but accessing any page on the site did not reflect the authentication.  Essentially, users could not log into the site.  Clearing the cookies, or even just the offending cookie, allowed users to log in.  Further investigation revealed the relationship with the multi-space cookies.

This bug was found on Zope/Plone running on SLES9, but I have reproduced it in Zope/Plone(versions 2.8.4/2.0.2) on Windows.  Create a Plone instance, define a unquoted domain cookie containing multiple spaces in your brower, log into the Plone site, attempt any page on the Plone site and not that the user is not logged in (the page does not display the user as loggin in in the user bar). Defining an unquoted cookie can be done by editing the Firefox cookies.txt file to contain the following cookie (Zope/Plone hosted on the localhost, in this case):

.localhost	TRUE	/	FALSE	3298378731	BadCookieForZope	cookie data with unquoted spaces

These entries will not see the bug:
.localhost	TRUE	/	FALSE	3298378731	BadCookieForZope	cookie data
.localhost	TRUE	/	FALSE	3298378731	BadCookieForZope	"cookie data with unquoted spaces"

It turns out that I really didn't care if the bad cookie got parsed correctly or not (at least at this time).  Resolution of issue 1498, so that parsing just skips bad cookies, would have solved my this problem.  However, the parser still needs to be able to handle this cookie.  I applied a fix to our local systems to work around this issue.  The fix makes the RE for parsing "evil MSIE cookies" more consistant with the "quoted correct cookie" case by including multiple spaces.  I did this by removing "\x00- " in the RE from exclusion of characters that could be part of the cookie value.  This seemed to be the most change that remained the most conistant with the rest of the regular expressions.  I have attached the patch file in this issue.
==============================================================