wisp::WispRes when it writes out response headers, currently writes header values out verbatim - see line 210:

&headers.each |Str v, Str k| { sout.print(k).print(": ").print(v).print("\r\n") };

This causes problems if the value contains new line characters - as they can corrupt the response as each new line looks like a new header name / value pair. Or worse, an empty line denotes the start of the response.

Example, if the value was The quick brown fox \njumps over the lazy dog the header would be:

my-header: The quick brown fox 
jumps over the lazy dog         <-- invalid header

Header values may wrap multiple lines, they just need to be prefixed with some white space first. See rfc2616 sec4.2 and Multi-line HTTP Headers Confusion on StackOverflow.

It'd be nice if Wisp coped / played nice with such values.

In BedSheet I simply do this:

value = value.splitLines.join("\n ")

So that new line characters are preserved and encoded correctly, and any troublesome blank lines are discarded. The example then becomes:

my-header: The quick brown fox 
 jumps over the lazy dog

I think allowing newlines will probably just cause more issues than it solves, not all software is prepared to handle those cases elegantly. So my vote would to just add a check which raises an exception if you do that?

I think allowing newlines will probably just cause more issues than it solves

I don't see how, multiple line values are clearly part of the standard. If they're encoded properly, as per the one line fix, then everyone's happy and job done.

I sometimes use multi-line headers myself to pass error and stacktrace information behind the scenes along with normal error pages. It's quite useful and I've been doing it for some time.

Just because some unknown dodgy client X may not handle them, doesn't mean Fantom should disallow them. It then adds Fantom to that list of dodgy clients. It's like outlawing CSS3 because IE doesn't understand it...

I'm good with that philosophy. Why don't you send me a patch, but given that 99.9999% of requests don't have newlines I want to make sure its fast and doesn't create new objects unless a newline is actually present