Changeset 698 for draft-ietf-httpbis/latest/p1-messaging.xml
- Timestamp:
- 26/09/09 10:09:09 (13 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.xml
r697 r698 2554 2554 <t> 2555 2555 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 that2558 would have been senthad 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. 2559 2559 </t> 2560 2560 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Content-Length"/><iref primary="true" item="Grammar" subitem="Content-Length-v"/> … … 2674 2674 <t> 2675 2675 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"/>). 2683 2685 </t> 2684 2686 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Host"/><iref primary="true" item="Grammar" subitem="Host-v"/> … … 2724 2726 <t> 2725 2727 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 2729 2733 list of extension transfer-coding names with optional accept 2730 2734 parameters (as described in <xref target="transfer.codings"/>). … … 2838 2842 <x:anchor-alias value="Transfer-Encoding-v"/> 2839 2843 <t> 2840 The "Transfer-Encoding" general-header field indicates what (if any)2841 type of transformation has been applied to the message body in order2842 to safely transfer it between the sender and the recipient. This2843 differs from the content-coding in that the transfer-coding is a2844 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. 2845 2849 </t> 2846 2850 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Transfer-Encoding"/><iref primary="true" item="Grammar" subitem="Transfer-Encoding-v"/> … … 2874 2878 <t> 2875 2879 The "Upgrade" general-header field allows the client to specify what 2876 additional communication protocols it supports and would like to use2877 if the server finds it appropriate to switch protocols. The server2878 &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. 2880 2884 </t> 2881 2885 <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.