PROXY  WHOIS  RQUOTE  TEXTS  SOFT  FOREX  BBOARD
 Radio  Music  Philosophy  Code  Literature  Russian

= ROOT|Technical|Proxy_Docs|rfc1945.txt =

page 31 of 34



   University of California
   Irvine, CA 92717-3425, U.S.A.

   Fax: +1 (714) 824-4056
   EMail: fielding@ics.uci.edu


   Henrik Frystyk Nielsen
   W3 Consortium
   MIT Laboratory for Computer Science
   545 Technology Square
   Cambridge, MA 02139, U.S.A.

   Fax: +1 (617) 258 8682
   EMail: frystyk@w3.org











 
RFC 1945                        HTTP/1.0                        May 1996


Appendices

   These appendices are provided for informational reasons only -- they
   do not form a part of the HTTP/1.0 specification.

A.  Internet Media Type message/http

   In addition to defining the HTTP/1.0 protocol, this document serves
   as the specification for the Internet media type "message/http". The
   following is to be registered with IANA [13].

       Media Type name:         message

       Media subtype name:      http

       Required parameters:     none

       Optional parameters:     version, msgtype

              version: The HTTP-Version number of the enclosed message
                       (e.g., "1.0"). If not present, the version can be
                       determined from the first line of the body.

              msgtype: The message type -- "request" or "response". If
                       not present, the type can be determined from the
                       first line of the body.

       Encoding considerations: only "7bit", "8bit", or "binary" are
                                permitted

       Security considerations: none

B.  Tolerant Applications

   Although this document specifies the requirements for the generation
   of HTTP/1.0 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 HTTP-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.




 
RFC 1945                        HTTP/1.0                        May 1996


C.  Relationship to MIME

   HTTP/1.0 uses many of the constructs defined for Internet Mail (RFC
   822 [7]) and the Multipurpose Internet Mail Extensions (MIME [5]) to
   allow entities to be transmitted in an open variety of
   representations and with extensible mechanisms. However, RFC 1521
   discusses mail, and HTTP has a few features that are different than
   those described in RFC 1521. 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.

   At the time of this writing, it is expected that RFC 1521 will be
=31=

1.25|26|27|28|29|30| < PREV = PAGE 31 = NEXT > |32|33|34

UP TO ROOT | UP TO DIR | TO FIRST PAGE

Google
 


E-mail Facebook VKontakte Google Digg del.icio.us BlinkList NewsVine Reddit YahooMyWeb LiveJournal Blogmarks TwitThis Live News2.ru BobrDobr.ru Memori.ru MoeMesto.ru

0.0262699 wallclock secs ( 0.01 usr + 0.01 sys = 0.02 CPU)