RFC 2068                        HTTP/1.1                    January 1997


For example:

   HTTP/1.1 206 Partial content
   Date: Wed, 15 Nov 1995 06:25:24 GMT
   Last-modified: Wed, 15 Nov 1995 04:58:08 GMT
   Content-type: multipart/byteranges; boundary=THIS_STRING_SEPARATES

   --THIS_STRING_SEPARATES
   Content-type: application/pdf
   Content-range: bytes 500-999/8000

   ...the first range...
   --THIS_STRING_SEPARATES
   Content-type: application/pdf
   Content-range: bytes 7000-7999/8000

   ...the second range
   --THIS_STRING_SEPARATES--

19.3 Tolerant Applications

   Although this document specifies the requirements for the generation
   of HTTP/1.1 messages, not all applications will be correct in their
   implementation. We therefore recommend that operational applications
   be tolerant of deviations whenever those deviations can be
   interpreted unambiguously.

   Clients SHOULD be tolerant in parsing the Status-Line and servers
   tolerant when parsing the Request-Line. In particular, they SHOULD
   accept any amount of SP or HT characters between fields, even though
   only 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 lowest
   common denominator of the character codes used within that body, with
   the exception that no label is preferred over the labels US-ASCII or
   ISO-8859-1.

   Additional rules for requirements on parsing and encoding of dates
   and other potential problems with date encodings include:

  o  HTTP/1.1 clients and caches should assume that an RFC-850 date
     which appears to be more than 50 years in the future is in fact
     in the past (this helps solve the "year 2000" problem).





 
RFC 2068                        HTTP/1.1                    January 1997


  o  An HTTP/1.1 implementation may internally represent a parsed
     Expires date as earlier than the proper value, but MUST NOT
     internally represent a parsed Expires date as later than the
     proper value.

  o  All expiration-related calculations must be done in GMT. The
     local time zone MUST NOT influence the calculation or comparison
     of an age or expiration time.

  o  If an HTTP header incorrectly carries a date value with a time
     zone other than GMT, it must be converted into GMT using the most
     conservative possible conversion.

19.4 Differences Between HTTP Entities and MIME Entities

   HTTP/1.1 uses many of the constructs defined for Internet Mail (RFC
   822) and the Multipurpose Internet Mail Extensions (MIME ) to allow
   entities to be transmitted in an open variety of representations and
   with extensible mechanisms. However, MIME [7] discusses mail, and
   HTTP has a few features that are different from those described in
   MIME.  These differences were carefully chosen to optimize
   performance over binary connections, to allow greater freedom in the
   use of new media types, to make date comparisons easier, and to
   acknowledge the practice of some early HTTP servers and clients.

   This appendix describes specific areas where HTTP differs from MIME.
   Proxies and gateways to strict MIME environments SHOULD be aware of
   these differences and provide the appropriate conversions where
   necessary. Proxies and gateways from MIME environments to HTTP also
   need to be aware of the differences because some conversions may be
   required.

19.4.1 Conversion to Canonical Form

   MIME requires that an Internet mail entity be converted to canonical
   form prior to being transferred.  Section 3.7.1 of this document
   describes the forms allowed for subtypes of the "text" media type
   when transmitted over HTTP. MIME requires that content with a type of