I've been using println to write a line of HTTP header either as server or client. I've been not thinking whether the HTTP standard requires \r\n or \n or \r to terminate each header line. Can someone point out which is right and what are tolerated? Thanks.
By the way, if I send POST request to a server, the data should not terminate with line breaks, right? The content-length should reflect the exact bytes unless I want the server to have a line break then I include an extra byte length in content-length, right? I've been using code without much thinking lately so hopefully I didn't violate the HTTP standards.
Not sure so I had a browse, seems '\r\n' is correct:
From wikipedia
The header fields are transmitted after the request or response line, which is the first line of a message. Header fields are colon-separated name-value pairs in clear-text string format, terminated by a carriage return (CR) and line feed (LF) character sequence. The end of the header fields is indicated by an empty field, resulting in the transmission of two consecutive CR-LF pairs. Long lines can be folded into multiple lines; continuation lines are indicated by the presence of a space (SP) or horizontal tab (HT) as the first character on the next line.[1]
Thanks pYro. I guess I was doing it right without knowing the right way. So now hopefully someone can help me with the POST question too.
No, don't add crlf after the message body.
4.1 Message Types
HTTP messages consist of requests from client to server and responses from server to client.
HTTP-message = Request | Response ; HTTP/1.1 messages
Request (section 5) and Response (section 6) messages use the generic message format of RFC 822 [9] for transferring entities (the payload of the message). Both types of message consist of a start-line, zero or more header fields (also known as "headers"), an empty line (i.e., a line with nothing preceding the CRLF) indicating the end of the header fields, and possibly a message-body.generic-message = start-line
*(message-header CRLF)
CRLF
[ message-body ]
start-line = Request-Line | Status-Line
In the interest of robustness, servers SHOULD ignore any empty line(s) received where a Request-Line is expected. In other words, if the server is reading the protocol stream at the beginning of a message and receives a CRLF first, it should ignore the CRLF.Certain buggy HTTP/1.0 client implementations generate extra CRLF's after a POST request. To restate what is explicitly forbidden by the BNF, an HTTP/1.1 client MUST NOT preface or follow a request with an extra CRLF.
Awesome! Thanks again pYro! I just added some code to remove a \n from my POST request. I'll have to disconnect my wifi router to give my project a test. It caches unsent data to sd card when wifi is down.
No worries, I didn't actually know the answers, but as I've just started coding my server I wish it to be correct too, so answering these types of questions will benefit me just as much, assuming too much always leads to some kind of bug/error down the track.
Here is the link I forgot to post (location of referenced text above)
http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html
And the main reference index:
Hypertext Transfer Protocol -- HTTP/1.1 << Worth browsing through on a rainy day.
Got it! RFC2616! In my dropbox for all my devices.
A bit dated but I still find this page one of the best resources for getting to grips with HTTP in practice.
Also worth keeping a bookmark to is RFC1945
Yes, I think I read through the practical guide but my mind is like a leaky bucket 
Now the RFC 1945 is also in my dropbox. So request for comments, that's what RFC mean?