[Web-SIG] Newline values in WSGI response header values.
sh at defuze.org
Thu Jun 12 10:22:51 CEST 2008
> Can anyone confirm for me what the behaviour should be if someone
> includes a newline in the value of a WSGI response header?
> CGI specification would seem to disallow it and thus WSGI adapter
> should by rights possibly produce an error if user code does it.
> At the moment I know of no WSGI adapter implementation which validates
> whether a newline appears in the value of a WSGI response header. For
> many WSGI adapters this means that a header of:
> Key1: "Value1\r\nKey2: Value2"
> will actually translate into two separate headers being sent back to
> For a header of:
> Key3: "Value3a\r\nValue3b"
> in a WSGI adapter which simply passes things through, the client would
> get an invalid header line, which in general it would ignore. If
> however this was generated when hosted with a CGI-WSGI adapter, for
> Apache at least, Apache would generate a 500 error itself due to
> detected a header line of invalid format.
> Thus, is an embedded newline in value invalid? Would it be reasonable
> for a WSGI adapter to flag it as an error?
I might be reading the spec wrong but it doesn't seem to be forbidden by
Section 4.2 says:
> Any LWS that occurs between field-content MAY be replaced with a single
SP before interpreting the field value or forwarding the message
Then a look at the definition of separators shows us that SP is a valid
Since section 2.1 tells:
> Except where noted otherwise, linear white space (LWS) can be included
between any two adjacent words (token or quoted-string), and between
adjacent words and separators, without changing the interpretation of a
It sounds to me that this is a valid construct but a WSGI adapter might
consider converting those CRLF into simple SP as said in 2.1 again:
> A recipient MAY replace any linear white space with a single SP before
interpreting the field value or forwarding the message downstream.
More information about the Web-SIG