Tests failure with session enabled

[bochecha]

Enabling the cherrypy session breaks the tests. It can be easily reproduced with the following:

$ tg-admin quickstart # create 'dummy' project
$ cd dummy
$ nosetests

At this point, the tests will fail for a totally unrelated issue (reported as ticket #2485). Pretend the tests are succeeding and keep reading. :)

Add the session_filter.on = True option to your test.cfg file, then:

$ nosetests

Now, tests will fail with the following message:

======================================================================
FAIL: The index method should return a datetime.datetime called 'now'
----------------------------------------------------------------------
Traceback (most recent call last):
  File "X:\progs\dummy\dummy\tests\test_controllers.py", line 16, in test_method
    response = self.app.get('/')
  File "build\bdist.win32\egg\webtest\__init__.py", line 148, in get
  File "build\bdist.win32\egg\webtest\__init__.py", line 306, in do_request
  File "build\bdist.win32\egg\webob\__init__.py", line 1321, in get_response
  File "build\bdist.win32\egg\webob\__init__.py", line 1293, in call_application
  File "build\bdist.win32\egg\webtest\lint.py", line 170, in lint_app
    iterator = application(environ, start_response_wrapper)
  File "X:\progs\virt-sp\lib\site-packages\cherrypy-2.3.0-py2.5.egg\cherrypy\_cpwsgi.py", line 149, in wsgiApp
    start_response(s, h, exc)
  File "build\bdist.win32\egg\webtest\lint.py", line 160, in start_response_wrapper
    check_headers(headers)
  File "build\bdist.win32\egg\webtest\lint.py", line 399, in check_headers
    % (value, bad_header_value_re.search(value).group(0)))
AssertionError: Bad header value: 'session_id=4a68dcf113ffe6d8f26925766a851ef2071a9406; expires=Mon, 29 Mar 2010 17:33:10 GMT; Path=/\r' (bad char: '\r')
-------------------- >> begin captured logging << --------------------
turbogears.visit: INFO: Visit Tracking starting (timeout = 1200 sec).
turbogears.identity.savisit: INFO: Succesfully loaded "dummy.model.Visit"
turbogears.visit: INFO: Visit filter initialised
turbogears.identity: INFO: Identity starting
turbogears.identity.saprovider: INFO: Succesfully loaded "dummy.model.User".
turbogears.identity.saprovider: INFO: Succesfully loaded "dummy.model.Group".
turbogears.identity.saprovider: INFO: Succesfully loaded "dummy.model.Permission".
turbogears.identity.saprovider: INFO: Succesfully loaded "dummy.model.VisitIdentity".
turbogears.identity: INFO: Identity visit plugin initialised
turbogears.identity.saprovider: INFO: Succesfully loaded "dummy.model.User".
turbogears.identity.saprovider: INFO: Succesfully loaded "dummy.model.Group".
turbogears.identity.saprovider: INFO: Succesfully loaded "dummy.model.Permission".
turbogears.identity.saprovider: INFO: Succesfully loaded "dummy.model.VisitIdentity".
turbogears.visit: WARNING: Visit manager already running.
turbogears.identity: INFO: Identity starting
turbogears.identity.saprovider: INFO: Succesfully loaded "dummy.model.User".
turbogears.identity.saprovider: INFO: Succesfully loaded "dummy.model.Group".
turbogears.identity.saprovider: INFO: Succesfully loaded "dummy.model.Permission".
turbogears.identity.saprovider: INFO: Succesfully loaded "dummy.model.VisitIdentity".
turbogears.identity: INFO: Identity visit plugin initialised
turbogears.identity.saprovider: INFO: Succesfully loaded "dummy.model.User".
turbogears.identity.saprovider: INFO: Succesfully loaded "dummy.model.Group".
turbogears.identity.saprovider: INFO: Succesfully loaded "dummy.model.Permission".
turbogears.identity.saprovider: INFO: Succesfully loaded "dummy.model.VisitIdentity".
turbogears.access: INFO:  - - [29/Mar/2010:16:33:10 +0000] "GET / HTTP/1.0" 200 5220 "" ""
--------------------- >> end captured logging << ---------------------

Bug is 100% reproducible on Windows XP with both TurboGears 1.1b5 and 1.1.1.

I'll try to see if I can reproduce it on Linux as well, as the '\r' character seems pretty familiar.

[bochecha]

Like I thought, I can't reproduce the bug on a Linux (Fedora 12) box.

[bochecha]

Looking at the headers with the Live HTTP Headers Firefox extension, I could see that one of the headers (a Set-Cookie:) has an additional new line. Opening the file in Vim, there's the "^M" character, representing the Windows carriage return (aka "\r").

Looks like at some point, something (CherryPy?) adds this \r, but only to one of the headers.

[bochecha]

This is actually a duplicate of bug #2475.