[Web-SIG] Newline values in WSGI response header values.

Sylvain Hellegouarch 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
> client.
>
> 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
RFC 2616.

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

Then a look at the definition of separators shows us that SP is a valid
separator.

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

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.


- Sylvain

-- 
Sylvain Hellegouarch
http://www.defuze.org


More information about the Web-SIG mailing list