slavapestov/factor — comment on commit 9442cb12ea47607c9fa27f823e59f2bac71b0ee3
File:  line 0
By mrjbq7:

I was trying to use netcat to debug factor's web server and it wasn't working because I was using `\n`.

Normally I'd suggest conforming to the spec, but...

1) I noticed google.com supports `\n` headers

```
$ nc google.com 80
GET / HTTP/1.0

HTTP/1.0 200 OK
Date: Thu, 13 Oct 2011 02:10:47 GMT
Expires: -1
Cache-Control: private, max-age=0
Content-Type: text/html; charset=ISO-8859-1
Set-Cookie: PREF=ID=f57aaaab6a43a417:FF=0:TM=1318471847:LM=1318471847:S=SnPcafaXVYBSWKrO; expires=Sat, 12-Oct-2013 02:10:47 GMT; path=/; domain=.google.com
Set-Cookie: NID=52=LQc0rzUjDkIertqVq3SgK5svMEIQNcb88B0UKlpDzQLDEUOWFRBt57Fvmyc0gIp6U3MAHzb6gN6e7HUPyxsECrpmMAX2rkvTWFNdOJ9vM-iJNzKcoFjXkTXoc1WAy-tl; expires=Fri, 13-Apr-2012 02:10:47 GMT; path=/; domain=.google.com; HttpOnly
Server: gws
X-XSS-Protection: 1; mode=block
X-Frame-Options: SAMEORIGIN

```

2) I looked at the python `http.client` and `http.server` which mentions:

> The specification specifies that lines are separated by CRLF but
> for compatibility with the widest range of clients recommends
> servers also handle LF.

3) And you can see that RFC 2616 is conflicted about it:

> Section 3.7.1
> http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.7.1
> a bare CR or LF MUST NOT be substituted for CRLF within
> any of the HTTP control structures (such as header fields and
> multipart boundaries).

> **Section 19.3**
> http://www.w3.org/Protocols/rfc2616/rfc2616-sec19.html#sec19.3
> The line terminator for message-header fields is the sequence CRLF.
> However, we recommend that applications, when parsing such
> headers, recognize a single LF as a line terminator and ignore the leading CR.

What do you think?