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

Notes:1) Additional CRLFs may precede the first boundary string in theentity.Fielding, et al. Standards Track [Page 165]RFC 2616 HTTP/1.1 June 19992) Although RFC 2046 [40] permits the boundary string to bequoted, some existing implementations handle a quoted boundarystring incorrectly.3) A number of browsers and servers were coded to an early draftof the byteranges specification to use a media type ofmultipart/x-byteranges, which is almost, but not quitecompatible with the version documented in HTTP/1.1.19.3 Tolerant ApplicationsAlthough this document specifies the requirements for the generationof HTTP/1.1 messages, not all applications will be correct in theirimplementation. We therefore recommend that operational applicationsbe tolerant of deviations whenever those deviations can beinterpreted unambiguously.Clients SHOULD be tolerant in parsing the Status-Line and serverstolerant when parsing the Request-Line. In particular, they SHOULDaccept any amount of SP or HT characters between fields, even thoughonly a single SP is required.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.The character set of an entity-body SHOULD be labeled as the lowestcommon denominator of the character codes used within that body, withthe exception that not labeling the entity is preferred over labelingthe entity with the labels US-ASCII or ISO-8859-1. See section 3.7.1and 3.4.1.Additional rules for requirements on parsing and encoding of datesand other potential problems with date encodings include: