Changeset 2092 for draft-ietf-httpbis/latest/p2-semantics.xml
- Timestamp:
- 06/01/13 09:44:29 (10 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p2-semantics.xml
r2091 r2092 325 325 <c>Content-Language</c> <c><xref target="header.content-language"/></c> 326 326 <c>Content-Location</c> <c><xref target="header.content-location"/></c> 327 <c>Expires</c> <c>&header-expires;</c>328 327 </texttable> 329 328 … … 1265 1264 </t> 1266 1265 <t> 1266 The response to a GET request is cacheable; a cache &MAY; use it to satisfy 1267 subsequent GET and HEAD requests unless otherwise indicated by the 1268 Cache-Control header field (&header-cache-control;). 1269 </t> 1270 <t> 1267 1271 A payload within a GET request message has no defined semantics; 1268 1272 sending a payload body on a GET request might cause some existing 1269 1273 implementations to reject the request. 1270 </t>1271 <t>1272 The response to a GET request is cacheable and &MAY; be used to satisfy1273 subsequent GET and HEAD requests (see &caching;).1274 1274 </t> 1275 1275 </section> … … 1284 1284 The HEAD method is identical to GET except that the server &MUST-NOT; 1285 1285 send a message body in the response (i.e., the response terminates at the 1286 end of the header block). The metadata contained in the HTTP header fields 1287 in response to a HEAD request &SHOULD; be identical to the information sent 1288 in response to a GET request. This method can be used for obtaining 1289 metadata about the selected representation without transferring the 1290 representation data. This method is often used for testing hypertext links 1291 for validity, accessibility, and recent modification. 1292 </t> 1293 <t> 1294 The response to a HEAD request is cacheable and &MAY; be used to satisfy 1295 a subsequent HEAD request. It also has potential side effects on 1296 previously stored responses to GET; see &p6-head;. 1286 end of the header block). Aside from the payload header fields 1287 (<xref target="payload"/>), the server &SHOULD; send the same header fields 1288 in response to a HEAD request as it would have sent if the request had been 1289 a GET. This method can be used for obtaining metadata about the selected 1290 representation without transferring the representation data. This method is 1291 often used for testing hypertext links for validity, accessibility, and 1292 recent modification. 1293 </t> 1294 <t> 1295 The response to a HEAD request is cacheable; a cache &MAY; use it to 1296 satisfy subsequent HEAD requests unless otherwise indicated by the 1297 Cache-Control header field (&header-cache-control;). A HEAD response might 1298 also have an effect on previously cached responses to GET; see &p6-head;. 1297 1299 </t> 1298 1300 <t> … … 1734 1736 <ttcol>Defined in...</ttcol> 1735 1737 1738 <c>Cache-Control</c> <c>&header-cache-control;</c> 1739 <c>Expect</c> <c><xref target="header.expect"/></c> 1736 1740 <c>Host</c> <c>&header-host;</c> 1737 1741 <c>Max-Forwards</c> <c><xref target="header.max-forwards"/></c> 1738 <c> Expect</c> <c><xref target="header.expect"/></c>1742 <c>Pragma</c> <c>&header-pragma;</c> 1739 1743 <c>Range</c> <c>&header-range;</c> 1744 <c>TE</c> <c>&header-te;</c> 1740 1745 </texttable> 1741 1742 <section title="Max-Forwards" anchor="header.max-forwards">1743 <iref primary="true" item="Max-Forwards header field" x:for-anchor=""/>1744 <x:anchor-alias value="Max-Forwards"/>1745 <t>1746 The "Max-Forwards" header field provides a mechanism with the1747 TRACE (<xref target="TRACE"/>) and OPTIONS (<xref target="OPTIONS"/>)1748 methods to limit the number of times that the request is forwarded by1749 proxies. This can be useful when the client is attempting to1750 trace a request that appears to be failing or looping mid-chain.1751 </t>1752 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Max-Forwards"/>1753 <x:ref>Max-Forwards</x:ref> = 1*<x:ref>DIGIT</x:ref>1754 </artwork></figure>1755 <t>1756 The Max-Forwards value is a decimal integer indicating the remaining1757 number of times this request message can be forwarded.1758 </t>1759 <t>1760 Each recipient of a TRACE or OPTIONS request1761 containing a Max-Forwards header field &MUST; check and update its1762 value prior to forwarding the request. If the received value is zero1763 (0), the recipient &MUST-NOT; forward the request; instead, it &MUST;1764 respond as the final recipient. If the received Max-Forwards value is1765 greater than zero, then the forwarded message &MUST; contain an updated1766 Max-Forwards field with a value decremented by one (1).1767 </t>1768 <t>1769 The Max-Forwards header field &MAY; be ignored for all other request1770 methods.1771 </t>1772 </section>1773 1746 1774 1747 <section title="Expect" anchor="header.expect"> … … 1943 1916 </section> 1944 1917 </section> 1918 1919 <section title="Max-Forwards" anchor="header.max-forwards"> 1920 <iref primary="true" item="Max-Forwards header field" x:for-anchor=""/> 1921 <x:anchor-alias value="Max-Forwards"/> 1922 <t> 1923 The "Max-Forwards" header field provides a mechanism with the 1924 TRACE (<xref target="TRACE"/>) and OPTIONS (<xref target="OPTIONS"/>) 1925 methods to limit the number of times that the request is forwarded by 1926 proxies. This can be useful when the client is attempting to 1927 trace a request that appears to be failing or looping mid-chain. 1928 </t> 1929 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Max-Forwards"/> 1930 <x:ref>Max-Forwards</x:ref> = 1*<x:ref>DIGIT</x:ref> 1931 </artwork></figure> 1932 <t> 1933 The Max-Forwards value is a decimal integer indicating the remaining 1934 number of times this request message can be forwarded. 1935 </t> 1936 <t> 1937 Each recipient of a TRACE or OPTIONS request 1938 containing a Max-Forwards header field &MUST; check and update its 1939 value prior to forwarding the request. If the received value is zero 1940 (0), the recipient &MUST-NOT; forward the request; instead, it &MUST; 1941 respond as the final recipient. If the received Max-Forwards value is 1942 greater than zero, then the forwarded message &MUST; contain an updated 1943 Max-Forwards field with a value decremented by one (1). 1944 </t> 1945 <t> 1946 The Max-Forwards header field &MAY; be ignored for all other request 1947 methods. 1948 </t> 1949 </section> 1945 1950 </section> 1946 1951 … … 2335 2340 <c>From</c> <c><xref target="header.from"/></c> 2336 2341 <c>Referer</c> <c><xref target="header.referer"/></c> 2337 <c>TE</c> <c>&header-te;</c>2338 2342 <c>User-Agent</c> <c><xref target="header.user-agent"/></c> 2339 2343 </texttable> … … 3502 3506 <t> 3503 3507 Response header fields can supply control data that supplements the 3504 status code or instructs the client where to go next.3508 status code, directs caching, or instructs the client where to go next. 3505 3509 </t> 3506 3510 <texttable align="left"> … … 3508 3512 3509 3513 <c>Age</c> <c>&header-age;</c> 3514 <c>Cache-Control</c> <c>&header-cache-control;</c> 3515 <c>Expires</c> <c>&header-expires;</c> 3510 3516 <c>Date</c> <c><xref target="header.date"/></c> 3511 3517 <c>Location</c> <c><xref target="header.location"/></c> 3512 3518 <c>Retry-After</c> <c><xref target="header.retry-after"/></c> 3519 <c>Warning</c> <c>&header-warning;</c> 3513 3520 </texttable> 3514 3521 … … 3882 3889 header fields are not limited to those defined by this specification. 3883 3890 </t> 3891 <figure><preamble>For example, a response that contains</preamble><artwork type="example"> 3892 Vary: accept-encoding, accept-language 3893 </artwork><postamble>indicates that the origin server might have used the 3894 request's <x:ref>Accept-Encoding</x:ref> and <x:ref>Accept-Language</x:ref> 3895 fields (or lack thereof) as determining factors while choosing this 3896 <x:ref>selected representation</x:ref>. 3897 </postamble></figure> 3884 3898 <t> 3885 3899 An origin server might send Vary with a list of fields for two purposes: … … 3906 3920 </t> 3907 3921 <t> 3908 Unless it has been deliberately configured to prevent cache transparency, 3909 an origin server &SHOULD; send a Vary header field in a cacheable 3910 response that is subject to proactive negotiation. 3911 </t> 3912 <figure><preamble>For example, a response that contains</preamble><artwork type="example"> 3913 Vary: accept-encoding, accept-language 3914 </artwork><postamble>indicates that the origin server might have used the 3915 request's <x:ref>Accept-Encoding</x:ref> and <x:ref>Accept-Language</x:ref> 3916 fields (or lack thereof) as determining factors while choosing this 3917 <x:ref>selected representation</x:ref>.</postamble></figure> 3922 An origin server &SHOULD; send a Vary header field when its algorithm for 3923 selecting a representation varies based on aspects of the request message 3924 other than the method and request target, unless the variance cannot be 3925 crossed or the origin server has been deliberately configured to prevent 3926 cache transparency. For example, there is no need to send the 3927 Authorization field name (&header-authorization;) in Vary because 3928 reuse across users is constrained by the field definition. Likewise, 3929 Cache-Control directives (&header-cache-control;) might be used to supplant 3930 the need for Vary, particularly when the variance is considered less 3931 significant than the performance cost of Vary's impact on caching. 3932 </t> 3918 3933 </section> 3919 3934 </section>
Note: See TracChangeset
for help on using the changeset viewer.