At wsgiref.simple_server:99, it uses the wrong field to get the headers from the request.  In rfc822.Message.readheaders it describes that the headers attribute is an uninterrupted list of the lines in the header.  The dict attribute of Message should contain the proper key/value map of the headers.

I've attached a patch of what I think the behavior should be.  This has incidentally been fixed in python 3+.

Could you provide tests?

I confirm this fixes a bug.
To reproduce it just add, e.g.

X-Multline-Header: foo
 bar

to your request.
 
It has been fixed in Python 3 with
https://github.com/python/cpython/commit/67dcb80f6e102622e4aa888930d3017fed9834de

Thank you Tom. This was made in issue4718. But tests are passed without them. So 3.x needs tests too.

This is actually more complicated than I initially thought.
According to https://www.python.org/dev/peps/pep-3333/#the-start-response-callable
"Each header_value must not include any control characters, including carriage returns or linefeeds, either embedded or at the end. (These requirements are to minimize the complexity of any parsing that must be performed by servers, gateways, and intermediate response processors that need to inspect or modify response headers.) "

There's a discussion at https://mail.python.org/pipermail/web-sig/2006-September/002244.html 

It think the spec should be changed as parsing multi-line headers is really simple and sometimes necessary (e.g., when passing the X.509 client certificate).

Anyway, attached you find a patch for Python 2.7.8 which includes a test and allows CR/LF in header values.

The fix for the server looks ok, but the validation and tests must not
be changed, since they void spec compatibility and aren't a bug fix
(and so must not be added to 2.7.)  Indeed, if the validation library
*doesn't* fail on CRLF, then *that* would be a bug, since it's
supposed to tell you about every verifiable spec violation.

Also, simple_server *should* unfold multiline headers, if it's not
already doing so.  (If it's not, it is a bug and can therefore be
fixed in 2.7.)

On Tue, Dec 9, 2014 at 10:58 AM, Tom Tanner <report@bugs.python.org> wrote:
>
> Tom Tanner added the comment:
>
> This is actually more complicated than I initially thought.
> According to https://www.python.org/dev/peps/pep-3333/#the-start-response-callable
> "Each header_value must not include any control characters, including carriage returns or linefeeds, either embedded or at the end. (These requirements are to minimize the complexity of any parsing that must be performed by servers, gateways, and intermediate response processors that need to inspect or modify response headers.) "
>
> There's a discussion at https://mail.python.org/pipermail/web-sig/2006-September/002244.html
>
> It think the spec should be changed as parsing multi-line headers is really simple and sometimes necessary (e.g., when passing the X.509 client certificate).
>
> Anyway, attached you find a patch for Python 2.7.8 which includes a test and allows CR/LF in header values.
>
> ----------
> Added file: http://bugs.python.org/file37401/wsgi.diff
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue21114>
> _______________________________________

attached is the updated patch, which unfolds multiline headers but not validate them (tests included).

ping

Any chance to get this into 2.7.10?

The patch is waiting for inclusion in 2.7.10 :/

This might have been fixed by https://bugs.python.org/issue22928

Have not tested.

Python 2-only issue.