This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: wsgiref's wsgi application sample code does not work
Type: Stage: resolved
Components: Documentation Versions: Python 3.2, Python 3.3
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: docs@python Nosy List: docs@python, eric.araujo, pje, python-dev, r.david.murray, shimizukawa, skrah, terry.reedy
Priority: normal Keywords:

Created on 2011-05-01 05:56 by shimizukawa, last changed 2022-04-11 14:57 by admin. This issue is now closed.

Messages (6)
msg134900 - (view) Author: Takayuki SHIMIZUKAWA (shimizukawa) Date: 2011-05-01 05:56
WSGI sapmle code at wsgiref document ( was broken.

- status = b'200 OK'
- headers = [(b'Content-type', b'text/plain; charset=utf-8')]
+ status = '200 OK'
+ headers = [('Content-type', 'text/plain; charset=utf-8')]
msg135325 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2011-05-06 16:53
Thanks for the report.  Can you tell more about the bug you perceive?  The doc and code for wsgiref were carefully updated to play well with Python 3 clean bytes/characters distinction, so I’m surprised by this bug report.  Maybe you mistakenly tried the example with a Python 2.x version?
msg135387 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2011-05-06 23:46
Takayuki is correct, the status and header strings should, it seems, be 'native strings', not bytes.

The experimental proof is to run the current example code (I did so from IDLE editor window on WinXP) and then enter http://localhost:8000/
in a browser. Several error messages appear back in the shell window, like
AssertionError: Header names/values must be of type str (got b'Content-type')
Hit ^C to stop. Delete the b prefixes from the code. Rerun. Reaccess.
And the environment dict appears as promised:
TMP: C:\DOCUME~1\Terry\LOCALS~1\Temp
WATCOM: C:\temp\WatconPermanent
wsgi.multiprocess: False
Takayuki, if you did the same thing, it would have been helpful if you had said so.

Neither version works in 3.1.3. No exception messages either. Firefox says unable to connect. I retried with 3.2.0 and patched example and it worked again.

Running this down in the docs was harder. In the example, function simple_app is a WSGI application object. The status and header objects are passed to the start_response function passed to simple_app after simple_app is passed to make_server. The manual (elsewhere) refers to PEP 3333 for the definition of WSGI app object. The 'start_response Callable' section says the status passed to start_response should be a string and that headers should be a list of tuples of header key and value, but it does not specify the type of the latter. The earlier 'Note on String Types says that headers are, for convenience, native-to-the-version strings while bodies are bytes. So the revised example that works matches the doc.

Phillip or David, can you verify that this is all as intended?
msg135486 - (view) Author: PJ Eby (pje) * (Python committer) Date: 2011-05-07 17:22
Yes, the 'b' is a docs error.

I previously removed this in: 

It appears to have been reverted during a merge, here:

My browser crashed trying to view that huge second revision, so I'm not sure if there were any other regressions therein.
msg135780 - (view) Author: Roundup Robot (python-dev) (Python triager) Date: 2011-05-11 14:27
New changeset e7c62e0981c7 by Senthil Kumaran in branch 'default':
Fix closed Issue #11968 - the start_response header values in wsgiref shoudl be
msg135781 - (view) Author: Roundup Robot (python-dev) (Python triager) Date: 2011-05-11 14:38
New changeset 5add0c01933f by Senthil Kumaran in branch '3.2':
Issue #11968 - the start_response header values in wsgiref shoudl be str not

New changeset 482f60d6a687 by Senthil Kumaran in branch 'default':
[Merge Branch] Issue #11968 - the start_response header values in wsgiref shoudl be
Date User Action Args
2022-04-11 14:57:16adminsetgithub: 56177
2011-05-11 14:38:04python-devsetmessages: + msg135781
2011-05-11 14:29:20orsenthilsetstatus: open -> closed
resolution: fixed
stage: needs patch -> resolved
2011-05-11 14:27:39python-devsetnosy: + python-dev
messages: + msg135780
2011-05-09 14:37:30eric.araujosetnosy: + skrah
2011-05-07 17:22:35pjesetmessages: + msg135486
2011-05-06 23:46:56terry.reedysetversions: + Python 3.3
nosy: + terry.reedy, r.david.murray, pje

messages: + msg135387

stage: needs patch
2011-05-06 16:53:21eric.araujosetnosy: + eric.araujo
messages: + msg135325
2011-05-01 05:56:22shimizukawacreate