Ignore:
Timestamp:
26/09/09 10:09:09 (10 years ago)
Author:
julian.reschke@…
Message:

editorial: enhance readability of header introductions

File:
1 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/p1-messaging.xml

    r697 r698  
    25542554<t>
    25552555   The "Content-Length" entity-header field indicates the size of the
    2556    entity-body, in number of OCTETs, sent to the recipient or,
    2557    in the case of the HEAD method, the size of the entity-body that
    2558    would have been sent had the request been a GET.
     2556   entity-body, in number of OCTETs. In the case of responses to the HEAD
     2557   method, it indicates the size of the entity-body that would have been sent
     2558   had the request been a GET.
    25592559</t>
    25602560<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Content-Length"/><iref primary="true" item="Grammar" subitem="Content-Length-v"/>
     
    26742674<t>
    26752675   The "Host" request-header field specifies the Internet host and port
    2676    number of the resource being requested, as obtained from the original
    2677    URI given by the user or referring resource (generally an http URI,
    2678    as described in <xref target="http.uri"/>). The Host field value &MUST; represent
    2679    the naming authority of the origin server or gateway given by the
    2680    original URL. This allows the origin server or gateway to
    2681    differentiate between internally-ambiguous URLs, such as the root "/"
    2682    URL of a server for multiple host names on a single IP address.
     2676   number of the resource being requested, allowing the origin server or
     2677   gateway to differentiate between internally-ambiguous URLs, such as the root
     2678   "/" URL of a server for multiple host names on a single IP address.
     2679</t>
     2680<t>   
     2681   The Host field value &MUST; represent the naming authority of the origin
     2682   server or gateway given by the original URL obtained from the user or
     2683   referring resource (generally an http URI, as described in
     2684   <xref target="http.uri"/>).
    26832685</t>
    26842686<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Host"/><iref primary="true" item="Grammar" subitem="Host-v"/>
     
    27242726<t>
    27252727   The "TE" request-header field indicates what extension transfer-codings
    2726    it is willing to accept in the response and whether or not it is
    2727    willing to accept trailer fields in a chunked transfer-coding. Its
    2728    value may consist of the keyword "trailers" and/or a comma-separated
     2728   it is willing to accept in the response, and whether or not it is
     2729   willing to accept trailer fields in a chunked transfer-coding.
     2730</t>
     2731<t>
     2732   Its value may consist of the keyword "trailers" and/or a comma-separated
    27292733   list of extension transfer-coding names with optional accept
    27302734   parameters (as described in <xref target="transfer.codings"/>).
     
    28382842  <x:anchor-alias value="Transfer-Encoding-v"/>
    28392843<t>
    2840    The "Transfer-Encoding" general-header field indicates what (if any)
    2841    type of transformation has been applied to the message body in order
    2842    to safely transfer it between the sender and the recipient. This
    2843    differs from the content-coding in that the transfer-coding is a
    2844    property of the message, not of the entity.
     2844   The "Transfer-Encoding" general-header field indicates what transfer-codings
     2845   (if any) have been applied to the message body. It differs from
     2846   Content-Encoding (&content-codings;) in that transfer-codings are a property
     2847   of the message (and therefore are removed by intermediaries), whereas
     2848   content-codings are not.
    28452849</t>
    28462850<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Transfer-Encoding"/><iref primary="true" item="Grammar" subitem="Transfer-Encoding-v"/>
     
    28742878<t>
    28752879   The "Upgrade" general-header field allows the client to specify what
    2876    additional communication protocols it supports and would like to use
    2877    if the server finds it appropriate to switch protocols. The server
    2878    &MUST; use the Upgrade header field within a 101 (Switching Protocols)
    2879    response to indicate which protocol(s) are being switched.
     2880   additional communication protocols it would like to use, if the server
     2881   chooses to switch protocols. Additionally, the server &MUST; use the Upgrade
     2882   header field within a 101 (Switching Protocols) response to indicate which
     2883   protocol(s) are being switched to.
    28802884</t>
    28812885<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Upgrade"/><iref primary="true" item="Grammar" subitem="Upgrade-v"/>
Note: See TracChangeset for help on using the changeset viewer.