Embedded newlines in response header names and values.

[GoogleCodeExporter]

An explicit Python exception should perhaps be raised when invalid
characters such as embedded newlines appear in response header names and
values.

At the moment, in daemon mode one would get a cryptic error:

[Tue Apr 29 21:51:40 2008] [error] [client 192.168.0.100] malformed
header from script. Bad header=; Path=/;: production.wsgi, referer:
http://example.com

This is because newline stuffs up CGI style response returned from daemon
process to Apache child process, with badly formatted header being picked
up when parsing those headers.

In embedded mode, the malformed headers get passed back to the browser
client, which could cause the client or any intermediate proxy to
misinterpret headers. If there multiple \r\n combinations, it could cause
headers to end up being seen as part of response content.

The problem with daemon mode could also be solved when protocol is changed
to packet based protocol and response headers will be sent as length
annotated names and values. This though just means that malformed headers
get silently sent back to browser client.

Need to investigate what can correctly be returned in header values at
least. Since WSGI is based on CGI, most likely dictated by what CGI says.

Original issue reported on code.google.com by Graham.Dumpleton@gmail.com on 30 Apr 2008 at 12:25

[GoogleCodeExporter]

Issue being pursued on Python WEB-SIG at:

 http://groups.google.com/group/python-web-sig/browse_frm/thread/28ccc9d60548e455?hl=en

Original comment by Graham.Dumpleton@gmail.com on 12 Jun 2008 at 11:58

[GoogleCodeExporter]

Example of this problem occurring in Paste documented in discussion:

  http://groups.google.com/group/modwsgi/browse_frm/thread/16043503d522d45d?hl=en

Original comment by Graham.Dumpleton@gmail.com on 17 Sep 2008 at 7:19

[GoogleCodeExporter]

CGI specification RFC3875 says:

  Note that each header field in
  a CGI-Response MUST be specified on a single line; CGI/1.1 does not
  support continuation lines.

Although it mentions continuation lines in second statement, which refers to 
leading whitespace (LWS) convention, quoted strings can 
also contain embedded newlines if escaped by backslash. This would seem to 
conflict with first statement that MUST be specified on a 
single line, so can only presume that escaped newline in quoted string also 
wouldn't be allowed.

The Apache code for scan headers returned from CGI script certainly doesn't do 
anything special about quoted strings and just takes 
everything up to first newline character as complete line.

Original comment by Graham.Dumpleton@gmail.com on 25 Sep 2008 at 10:47

[GoogleCodeExporter]

Has been pointed out that WSGI PEP actually says:

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

So, okay to add check to complain about it.

Original comment by Graham.Dumpleton@gmail.com on 25 Sep 2008 at 10:16

[GoogleCodeExporter]

Original comment by Graham.Dumpleton@gmail.com on 28 Sep 2008 at 6:25

• Added labels: Milestone-Release3.0

[GoogleCodeExporter]

Change committed in revision 1079 of subversion trunk for 3.0 to produce an 
error if response header name of 
value has embedded newline.

Original comment by Graham.Dumpleton@gmail.com on 28 Sep 2008 at 6:34

[GoogleCodeExporter]

Original comment by Graham.Dumpleton@gmail.com on 29 Oct 2008 at 11:16

• Changed state: Started

[GoogleCodeExporter]

Backported to 2.x branch for 2.4 are revision 1237.

Original comment by Graham.Dumpleton@gmail.com on 16 Mar 2009 at 9:46

• Added labels: Milestone-Release2.4
• Removed labels: Milestone-Release3.0

[GoogleCodeExporter]

Version 2.4 of mod_wsgi now released.

Original comment by Graham.Dumpleton@gmail.com on 11 Apr 2009 at 10:25

• Changed state: Fixed