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: Cannot start wsgiref simple server in Py3k
Type: behavior Stage:
Components: Library (Lib) Versions: Python 3.0
Status: closed Resolution: duplicate
Dependencies: Superseder: wsgiref package totally broken
View: 4718
Assigned To: pje Nosy List: Walling, delimy, mgiuca, pitrou, pje
Priority: critical Keywords: patch

Created on 2008-07-12 16:19 by mgiuca, last changed 2022-04-11 14:56 by admin. This issue is now closed.

File name Uploaded Description Edit mgiuca, 2008-07-12 16:19 Patch for revision 64895; commit log in comments.
Messages (9)
msg69587 - (view) Author: Matt Giuca (mgiuca) Date: 2008-07-12 16:19
The wsgiref "simple server" module has a demo server, which fails to
start in Python 3.0 for a bunch of reasons.

To verify this, just go into the Lib/wsgiref directory, and run:
python3.0 ./
(which launches the demo server).

This opens your web browser and points it at the server, and you get the
following error:

ValueError: need more than 1 value to unpack

I fixed a number of issues which simply killed the server:

* In get_environ, it did not iterate over the headers mapping properly
at all (was expecting a sequence of strings, it actually is a mapping).
I think the email.message.Message class changed. Fixed.
* In demo_app, it calls sort on the output of dict.items() - a list in
Python 2, but an iterator in Python 3, so it fails. Fixed (using "sorted").

Unfortunately, the final issue is a bit harder to fix. It seems when I
run the demo server, it opens a binary stream, but sends
strings to be written, giving the error

TypeError: send() argument 1 must be bytes or read-only buffer, not str

However in the test case, it opens a text stream, so works fine.

The following *HACK* fixes it so the demo server works, but breaks the
test suite (it is NOT included in the attached patch):

--- Lib/wsgiref/	(revision 64895)
+++ Lib/wsgiref/	(working copy)
@@ -382,8 +382,8 @@
     def _write(self,data):
-        self.stdout.write(data)
-        self._write = self.stdout.write
+        self.stdout.write(data.encode('utf-8'))
+        #self._write = self.stdout.write
I can't figure out right away what to do about this, but the best
solution would be to get the demo server to open the socket in text mode.

In any case, the patch is attached for branch /branches/py3k, revision

Commit log:

* Lib/wsgiref/ Fixed two fatal errors which prevent the
demo server from running (broken due to Python 3.0).
Note: Demo server may still not run due to an issue between strings and
msg70149 - (view) Author: PJ Eby (pje) * (Python committer) Date: 2008-07-22 15:14
The encoding must be latin-1, not utf-8, and the stream must be binary
mode, not text.

I have no idea how to deal with the test suite, and don't have time at
the moment to investigate.
msg70150 - (view) Author: Matt Giuca (mgiuca) Date: 2008-07-22 15:20
Are you saying the stream passed to _write SHOULD always be a binary
stream, and hence the test case is wrong, because it opens a text stream?

(I'm not sure where the stream comes from, but we should guarantee it's
a binary stream).

Also, why Latin-1?
msg70152 - (view) Author: PJ Eby (pje) * (Python committer) Date: 2008-07-22 15:58
For the "why Latin-1", read the WSGI spec's explanation of how 
strings should be handled in Python implementations where 'str' is unicode.

I suppose that you *could* make it a text stream with Latin-1 
encoding; I'm just not clear on whether there are any other ramifications.
msg70153 - (view) Author: Matt Giuca (mgiuca) Date: 2008-07-22 16:12
Wow, I read the WSGI spec. That seems very strange that it says "HTTP
does not directly support Unicode, and neither does this interface."
Clearly HTTP *does* support Unicode, because it allows you to specify an

I assume then that the ISO-8859-1 characters the WSGI functions receive
will be treated as byte values. (That's rather silly; it's just dodging
the issue of Unicode rather than supporting it).

But in any event, the PEP has spoken, so we stick with Latin-1.

With respect to the text/binary stream, I think it would be best if it's
a binary stream, and we explicitly convert those str objects (which WSGI
says must only contain Latin-1 range characters) into bytes objects
(simply treating code points as bytes; in other words calling
.encode('latin-1')) and writing them to the binary stream. (Since the
WSGI spec is so adamant we deal in bytes).
msg70157 - (view) Author: PJ Eby (pje) * (Python committer) Date: 2008-07-22 17:24
HTTP is defined as a stream of bytes; the fact that you can specify 
encodings for headers and content is a different level of the 
spec.  WSGI wants to basically be as transparent a mapping as 
possible between HTTP and Python data structures, without imposing 
any *new* higher-level structures or conventions.
msg72705 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2008-09-06 21:34
Also reported in #3795.
PJE, are you willing to work on this some day?
msg72713 - (view) Author: PJ Eby (pje) * (Python committer) Date: 2008-09-06 22:14
Not any time soon; I don't currently use Py3K and can't even vouch for
the correctness of the posted patch within Py3K.  (i.e., what really
happened to the message class?)  Sorry; all I can really do here is
clarify WSGI-related questions.
msg78195 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2008-12-22 16:30
There's a proper patch in #4718, marking this one in duplicate.
Date User Action Args
2022-04-11 14:56:36adminsetgithub: 47598
2008-12-22 16:30:42pitrousetstatus: open -> closed
resolution: duplicate
superseder: wsgiref package totally broken
messages: + msg78195
2008-09-06 22:14:29pjesetmessages: + msg72713
2008-09-06 21:34:22pitrousetnosy: + Walling
messages: + msg72705
2008-07-24 15:35:04pitrousetnosy: + delimy
2008-07-24 15:34:15pitroulinkissue2566 superseder
2008-07-22 17:24:08pjesetmessages: + msg70157
2008-07-22 16:12:20mgiucasetmessages: + msg70153
2008-07-22 15:58:41pjesetmessages: + msg70152
2008-07-22 15:20:41mgiucasetmessages: + msg70150
2008-07-22 15:14:02pjesetmessages: + msg70149
2008-07-22 14:21:11benjamin.petersonsetpriority: high -> critical
assignee: pje
nosy: + pje
2008-07-22 13:47:29pitrousetpriority: high
nosy: + pitrou
2008-07-12 16:19:27mgiucacreate