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

= ROOT|Technical|Proxy_Docs|rfc2068.txt =

page 18 of 91



   extended over multiple lines by preceding each extra line with at
   least one SP or HT.  Applications SHOULD follow "common form" when
   generating HTTP constructs, since there might exist some
   implementations that fail to accept anything beyond the common forms.

          message-header = field-name ":" [ field-value ] CRLF

          field-name     = token
          field-value    = *( field-content | LWS )

          field-content  = <the OCTETs making up the field-value
                           and consisting of either *TEXT or combinations
                           of token, tspecials, and quoted-string>

   The order in which header fields with differing field names are
   received is not significant. However, it is "good practice" to send
   general-header fields first, followed by request-header or response-
   header fields, and ending with the entity-header fields.

   Multiple message-header fields with the same field-name may be
   present in a message if and only if the entire field-value for that
   header field is defined as a comma-separated list [i.e., #(values)].
   It MUST be possible to combine the multiple header fields into one
   "field-name: field-value" pair, without changing the semantics of the
   message, by appending each subsequent field-value to the first, each
   separated by a comma. The order in which header fields with the same
   field-name are received is therefore significant to the
   interpretation of the combined field value, and thus a proxy MUST NOT
   change the order of these field values when a message is forwarded.









 
RFC 2068                        HTTP/1.1                    January 1997


4.3 Message Body

   The message-body (if any) of an HTTP message is used to carry the
   entity-body associated with the request or response. The message-body
   differs from the entity-body only when a transfer coding has been
   applied, as indicated by the Transfer-Encoding header field (section
   14.40).

          message-body = entity-body
                       | <entity-body encoded as per Transfer-Encoding>

   Transfer-Encoding MUST be used to indicate any transfer codings
   applied by an application to ensure safe and proper transfer of the
   message.  Transfer-Encoding is a property of the message, not of the
   entity, and thus can be added or removed by any application along the
   request/response chain.

   The rules for when a message-body is allowed in a message differ for
   requests and responses.

   The presence of a message-body in a request is signaled by the
   inclusion of a Content-Length or Transfer-Encoding header field in
   the request's message-headers. A message-body MAY be included in a
   request only when the request method (section 5.1.1) allows an
   entity-body.

   For response messages, whether or not a message-body is included with
   a message is dependent on both the request method and the response
   status code (section 6.1.1). All responses to the HEAD request method
   MUST NOT include a message-body, even though the presence of entity-
   header fields might lead one to believe they do. All 1xx
   (informational), 204 (no content), and 304 (not modified) responses
   MUST NOT include a message-body. All other responses do include a
   message-body, although it may be of zero length.

4.4 Message Length

   When a message-body is included with a message, the length of that
   body is determined by one of the following (in order of precedence):

   1. Any response message which MUST NOT include a message-body
     (such as the 1xx, 204, and 304 responses and any response to a HEAD
     request) is always terminated by the first empty line after the
     header fields, regardless of the entity-header fields present in the
     message.

   2. If a Transfer-Encoding header field (section 14.40) is present and
     indicates that the "chunked" transfer coding has been applied, then




 
RFC 2068                        HTTP/1.1                    January 1997


     the length is defined by the chunked encoding (section 3.6).

=18=

1.12|13|14|15|16|17| < PREV = PAGE 18 = NEXT > |19|20|21|22|23|24.91

UP TO ROOT | UP TO DIR | TO FIRST PAGE

Google
 


E-mail Facebook Google Digg del.icio.us BlinkList Fark Furl Ma.gnolia Netscape NewsVine Reddit Slashdot Spurl StumbleUpon Technorati YahooMyWeb LiveJournal Blogmarks TwitThis Live News2.ru BobrDobr.ru Memori.ru MoeMesto.ru

0.031595 wallclock secs ( 0.01 usr + 0.00 sys = 0.01 CPU)