New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
wsgiref's wsgi application sample code does not work #56177
Comments
WSGI sapmle code at wsgiref document (http://docs.python.org/py3k/library/wsgiref.html#wsgiref.util.setup_testing_defaults) 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')] |
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? |
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/ 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? |
Yes, the 'b' is a docs error. I previously removed this in: http://hg.python.org/cpython-fullhistory/rev/2697326d4a77 It appears to have been reverted during a merge, here: http://hg.python.org/cpython-fullhistory/rev/88d04f0143c7 My browser crashed trying to view that huge second revision, so I'm not sure if there were any other regressions therein. |
New changeset e7c62e0981c7 by Senthil Kumaran in branch 'default': |
New changeset 5add0c01933f by Senthil Kumaran in branch '3.2': New changeset 482f60d6a687 by Senthil Kumaran in branch 'default': |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: