Skip to content

Cannot start wsgiref simple server in Py3k #47598

Closed
Closed
Cannot start wsgiref simple server in Py3k#47598
Assignees
pjeby
Labels
stdlibStandard Library Python modules in the Lib/ directorytype-bugAn unexpected behavior, bug, or error

Description

@mgiuca
mgiuca
mannequin
opened on Jul 12, 2008
BPO 3348
Nosy @pjeby, @pitrou
Superseder
  • bpo-4718: wsgiref package totally broken
    		•
    Files
  • simple_server.py.patch: Patch for revision 64895; commit log in comments.
    		•

    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:

    assignee = 'https://github.com/pjeby'
closed_at = <Date 2008-12-22.16:30:42.133>
created_at = <Date 2008-07-12.16:19:26.912>
labels = ['type-bug', 'library']
title = 'Cannot start wsgiref simple server in Py3k'
updated_at = <Date 2008-12-22.16:30:42.132>
user = 'https://bugs.python.org/mgiuca'

    bugs.python.org fields:

    activity = <Date 2008-12-22.16:30:42.132>
actor = 'pitrou'
assignee = 'pje'
closed = True
closed_date = <Date 2008-12-22.16:30:42.133>
closer = 'pitrou'
components = ['Library (Lib)']
creation = <Date 2008-07-12.16:19:26.912>
creator = 'mgiuca'
dependencies = []
files = ['10886']
hgrepos = []
issue_num = 3348
keywords = ['patch']
message_count = 9.0
messages = ['69587', '70149', '70150', '70152', '70153', '70157', '72705', '72713', '78195']
nosy_count = 5.0
nosy_names = ['pje', 'pitrou', 'delimy', 'mgiuca', 'Walling']
pr_nums = []
priority = 'critical'
resolution = 'duplicate'
stage = None
status = 'closed'
superseder = '4718'
type = 'behavior'
url = 'https://bugs.python.org/issue3348'
versions = ['Python 3.0']

    Activity

    1. mgiuca commented on Jul 12, 2008

      @mgiuca
      mgiucamannequin
      on Jul 12, 2008
      MannequinAuthor

      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 ./simple_server.py
      (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 handlers.py 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 handlers.py 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/handlers.py	(revision 64895)
+++ Lib/wsgiref/handlers.py	(working copy)
@@ -382,8 +382,8 @@
         self.environ.update(self.base_env)
 
     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
      64895.

      Commit log:

      • Lib/wsgiref/simple_server.py: 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
        bytes.
    2. mgiuca
      added
      stdlibStandard Library Python modules in the Lib/ directory
      type-bugAn unexpected behavior, bug, or error
      on Jul 12, 2008
    3. benjaminp
      assigned
      pjeby
      on Jul 22, 2008

    4. pjeby commented on Jul 22, 2008

      @pjeby
      pjebymannequin
      on Jul 22, 2008
      Mannequin

      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.

    5. mgiuca commented on Jul 22, 2008

      @mgiuca
      mgiucamannequin
      on Jul 22, 2008
      MannequinAuthor

      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?

    6. pjeby commented on Jul 22, 2008

      @pjeby
      pjebymannequin
      on Jul 22, 2008
      Mannequin

      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.

    7. mgiuca commented on Jul 22, 2008

      @mgiuca
      mgiucamannequin
      on Jul 22, 2008
      MannequinAuthor

      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
      encoding.

      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).

    8. pjeby commented on Jul 22, 2008

      @pjeby
      pjebymannequin
      on Jul 22, 2008
      Mannequin

      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.

    9. pitrou commented on Sep 6, 2008

      @pitrou
      pitrou
      on Sep 6, 2008
      Member

      Also reported in bpo-3795.
      PJE, are you willing to work on this some day?

    10. pjeby commented on Sep 6, 2008

      @pjeby
      pjebymannequin
      on Sep 6, 2008
      Mannequin

      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.

    11. pitrou commented on Dec 22, 2008

      @pitrou
      pitrou
      on Dec 22, 2008
      Member

      There's a proper patch in bpo-4718, marking this one in duplicate.

    12. pitrou
      closed this as completedon Dec 22, 2008
    13. ezio-melotti
      transferred this issue fromon Apr 10, 2022
    Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

    Metadata

    Metadata

    Assignees

    Labels

    stdlibStandard Library Python modules in the Lib/ directorytype-bugAn unexpected behavior, bug, or error

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions