TypeError WSGI response header value u'...' is not of type str

[simevo]

The fix for #913 introduced new type checks on headers which causes failure when existing code like this:

#!/usr/bin/env python
# coding=utf-8
import bottle
@bottle.route('/', method='GET')
def test():
    return bottle.static_file('test.txt', root='.', mimetype=u'text/plain', download='test.txt')
bottle.BaseRequest.MEMFILE_MAX = 5 * 1024 * 1024
bottle.debug(True)
bottle.run(host='127.0.0.1', port=8080, reloader=True, server='cherrypy')

is run with python 2.7

This used to work, now it shows this error in chromium:

"The requested resource returned more bytes than the declared Content-Length."

The actual trace as shown in the console where the script runs is:

Critical error while processing request: /
Error:
TypeError("WSGI response header value u'text/plain' is not of type str.",)
Traceback:
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/bottle.py", line 960, in wsgi
    start_response(response._status_line, response.headerlist)
  File "/usr/lib/python2.7/dist-packages/cherrypy/wsgiserver/wsgiserver2.py", line 2309, in start_response
    "WSGI response header value %r is not of type str." % v)
TypeError: WSGI response header value u'text/plain' is not of type str.

The workaround is to pass a string not a unicode string as mimetype:

    return bottle.static_file('test.txt', root='.', mimetype='text/plain', download='test.txt')

At a minimum, it would be preferable to see the "Critical error while processing request" error not the "The requested resource returned more bytes than the declared Content-Length." one which is misleading.

For maximum backward compatibility, and if that does not cause side-effects, it would be nice if unicode strings would be OK as they used to be.

[defnull]

The strange chrome error comes from cherrypy not updating the content-type header after replacing the response content. Perhaps we should report that to cherrypy as well.

I'll release a fix for the bottle-side of this bug soon.

[simevo]

That was quick ! Thanks for your prompt action.
I have verified the fix for the test script as well as for the real thing here, and it does work for me.
Should I do something about cherrypy ?

[defnull]

I'm not sure this is really a cherrypy bug. It might be caused by the "last resort" error handling in bottle. On first glance I cannot find a bug. https://github.com/bottlepy/bottle/blob/release-0.12/bottle.py#L973 looks fine (no Content-Length header at all).

[simevo]

I guess to prove that we should reproduce it with a minimal test code as they did here: cherrypy/cherrypy#1530 ?
BTW I just noticed that being on Debian stable my cherrypy is quite outdated (2.3.0 vs. 8.7.0 (!))...