Network Working Group R. Fielding Request for Comments: 2616 ...

RFC 2616 HTTP/1.1 June 1999HTTP/1.1 has been designed to allow implementations of applicationsthat do not depend on knowledge of ranges.4 HTTP Message4.1 Message TypesHTTP messages consist of requests from client to server and responsesfrom server to client.HTTP-message = Request | Response; HTTP/1.1 messagesRequest (section 5) and Response (section 6) messages use the genericmessage format of RFC 822 [9] for transferring entities (the payloadof the message). Both types of message consist of a start-line, zeroor more header fields (also known as "headers"), an empty line (i.e.,a line with nothing preceding the CRLF) indicating the end of theheader fields, and possibly a message-body.generic-message = start-line*(message-header CRLF)CRLF[ message-body ]start-line = Request-Line | Status-LineIn the interest of robustness, servers SHOULD ignore any emptyline(s) received where a Request-Line is expected. In other words, ifthe server is reading the protocol stream at the beginning of amessage and receives a CRLF first, it should ignore the CRLF.Certain buggy HTTP/1.0 client implementations generate extra CRLF'safter a POST request. To restate what is explicitly forbidden by theBNF, an HTTP/1.1 client MUST NOT preface or follow a request with anextra CRLF.4.2 Message HeadersHTTP header fields, which include general-header (section 4.5),request-header (section 5.3), response-header (section 6.2), andentity-header (section 7.1) fields, follow the same generic format asthat given in Section 3.1 of RFC 822 [9]. Each header field consistsof a name followed by a colon (":") and the field value. Field namesare case-insensitive. The field value MAY be preceded by any amountof LWS, though a single SP is preferred. Header fields can beextended over multiple lines by preceding each extra line with atleast one SP or HT. Applications ought to follow "common form", whereone is known or indicated, when generating HTTP constructs, since