Changeset 1163 for draft-ietf-httpbis/latest
- Timestamp:
- 11/03/11 06:45:30 (11 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 7 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.xml
r1161 r1163 31 31 <!ENTITY header-warning "<xref target='Part6' x:rel='#header.warning' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 32 32 <!ENTITY idempotent-methods "<xref target='Part2' x:rel='#idempotent.methods' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 33 <!ENTITY request-header-fields "<xref target='Part2' x:rel='#request.header.fields' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">34 <!ENTITY response-header-fields "<xref target='Part2' x:rel='#response.header.fields' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">35 33 <!ENTITY status-codes "<xref target='Part2' x:rel='#status.codes' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 36 34 <!ENTITY status-100 "<xref target='Part2' x:rel='#status.100' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> … … 517 515 </section> 518 516 519 <section title="ABNF Rules defined in other Parts of the Specification" anchor="abnf.dependencies">520 <x:anchor-alias value="request-header"/>521 <x:anchor-alias value="response-header"/>522 <x:anchor-alias value="Cache-Control"/>523 <x:anchor-alias value="Pragma"/>524 <x:anchor-alias value="Warning"/>525 <x:anchor-alias value="MIME-Version"/>526 <t>527 The ABNF rules below are defined in other parts:528 </t>529 <figure><!-- Part2--><artwork type="abnf2616">530 <x:ref>request-header</x:ref> = <request-header, defined in &request-header-fields;>531 <x:ref>response-header</x:ref> = <response-header, defined in &response-header-fields;>532 </artwork></figure>533 <figure><!-- Part3--><artwork type="abnf2616">534 <x:ref>MIME-Version</x:ref> = <MIME-Version, defined in &header-mime-version;>535 </artwork></figure>536 <figure><!-- Part6--><artwork type="abnf2616">537 <x:ref>Cache-Control</x:ref> = <Cache-Control, defined in &header-pragma;>538 <x:ref>Pragma</x:ref> = <Pragma, defined in &header-pragma;>539 <x:ref>Warning</x:ref> = <Warning, defined in &header-warning;>540 </artwork></figure>541 </section>542 543 517 </section> 544 518 </section> … … 1095 1069 are never "public" and thus are ineligible for shared caching. 1096 1070 Their default is "private" and might be further constrained via use 1097 of the Cache-Control header field .1071 of the Cache-Control header field (&header-cache-control;). 1098 1072 </t> 1099 1073 <t> … … 1556 1530 <c>Connection</c> <c><xref target="header.connection"/></c> 1557 1531 <c>Date</c> <c><xref target="header.date"/></c> 1558 <c>Pragma</c> <c>&header-pragma;</c>1559 1532 <c>Trailer</c> <c><xref target="header.trailer"/></c> 1560 1533 <c>Transfer-Encoding</c> <c><xref target="header.transfer-encoding"/></c> 1561 1534 <c>Upgrade</c> <c><xref target="header.upgrade"/></c> 1562 1535 <c>Via</c> <c><xref target="header.via"/></c> 1563 <c>Warning</c> <c>&header-warning;</c>1564 <c>MIME-Version</c> <c>&header-mime-version;</c>1565 1536 </texttable> 1566 <t>1567 General-header field names can be extended reliably only in1568 combination with a change in the protocol version. However, new or1569 experimental header fields might be given the semantics of general1570 header fields if all parties in the communication recognize them to1571 be general-header fields.1572 </t>1573 1537 </section> 1574 1538 </section> … … 2773 2737 <t> 2774 2738 If a client will wait for a 100 (Continue) response before 2775 sending the request body, it &MUST; send an Expect request-header2739 sending the request body, it &MUST; send an Expect header 2776 2740 field (&header-expect;) with the "100-continue" expectation. 2777 2741 </t> 2778 2742 <t> 2779 A client &MUST-NOT; send an Expect request-header field (&header-expect;)2743 A client &MUST-NOT; send an Expect header field (&header-expect;) 2780 2744 with the "100-continue" expectation if it does not intend 2781 2745 to send a request body. … … 2795 2759 Requirements for HTTP/1.1 origin servers: 2796 2760 <list style="symbols"> 2797 <t> Upon receiving a request which includes an Expect request-header2761 <t> Upon receiving a request which includes an Expect header 2798 2762 field with the "100-continue" expectation, an origin server &MUST; 2799 2763 either respond with 100 (Continue) status code and continue to read … … 2806 2770 </t> 2807 2771 <t> An origin server &SHOULD-NOT; send a 100 (Continue) response if 2808 the request message does not include an Expect request-header2772 the request message does not include an Expect header 2809 2773 field with the "100-continue" expectation, and &MUST-NOT; send a 2810 2774 100 (Continue) response if such a request comes from an HTTP/1.0 … … 2812 2776 compatibility with <xref target="RFC2068"/>, a server &MAY; send a 100 (Continue) 2813 2777 status code in response to an HTTP/1.1 PUT or POST request that does 2814 not include an Expect request-header field with the "100-continue"2778 not include an Expect header field with the "100-continue" 2815 2779 expectation. This exception, the purpose of which is 2816 2780 to minimize any client processing delays associated with an … … 2829 2793 </t> 2830 2794 <t> If an origin server receives a request that does not include an 2831 Expect request-header field with the "100-continue" expectation,2795 Expect header field with the "100-continue" expectation, 2832 2796 the request includes a request body, and the server responds 2833 2797 with a final status code before reading the entire request body … … 2845 2809 Requirements for HTTP/1.1 proxies: 2846 2810 <list style="symbols"> 2847 <t> If a proxy receives a request that includes an Expect request-header2811 <t> If a proxy receives a request that includes an Expect header 2848 2812 field with the "100-continue" expectation, and the proxy 2849 2813 either knows that the next-hop server complies with HTTP/1.1 or … … 2861 2825 <t> A proxy &MUST-NOT; forward a 100 (Continue) response if the 2862 2826 request message was received from an HTTP/1.0 (or earlier) 2863 client and did not include an Expect request-header field with2827 client and did not include an Expect header field with 2864 2828 the "100-continue" expectation. This requirement overrides the 2865 2829 general rule for forwarding of 1xx responses (see &status-1xx;). … … 2872 2836 <t> 2873 2837 If an HTTP/1.1 client sends a request which includes a request body, 2874 but which does not include an Expect request-header field with the2838 but which does not include an Expect header field with the 2875 2839 "100-continue" expectation, and if the client is not directly 2876 2840 connected to an HTTP/1.1 origin server, and if the client sees the … … 2884 2848 </t> 2885 2849 <t> 2886 Transmit the request-header fields 2850 Transmit the request-line, header fields, and the CRLF that 2851 indicates the end of header fields. 2887 2852 </t> 2888 2853 <t> … … 2972 2937 <x:anchor-alias value="Connection-v"/> 2973 2938 <t> 2974 The "Connection" general-header field allows the sender to specify2939 The "Connection" header field allows the sender to specify 2975 2940 options that are desired for that particular connection and &MUST-NOT; 2976 2941 be communicated by proxies over further connections. … … 2996 2961 <t> 2997 2962 Message header fields listed in the Connection header field &MUST-NOT; include 2998 end-to-end header fields, such as Cache-Control .2963 end-to-end header fields, such as Cache-Control (&header-cache-control;). 2999 2964 </t> 3000 2965 <t> … … 3079 3044 <x:anchor-alias value="Date-v"/> 3080 3045 <t> 3081 The "Date" general-header field represents the date and time at which3046 The "Date" header field represents the date and time at which 3082 3047 the message was originated, having the same semantics as the Origination 3083 3048 Date Field (orig-date) defined in <xref target="RFC5322" x:fmt="of" x:sec="3.6.1"/>. … … 3155 3120 <x:anchor-alias value="Host-v"/> 3156 3121 <t> 3157 The "Host" request-header field specifies the Internet host and port3122 The "Host" header field specifies the Internet host and port 3158 3123 number of the resource being requested, allowing the origin server or 3159 3124 gateway to differentiate between internally-ambiguous URLs, such as the root … … 3207 3172 <x:anchor-alias value="te-ext"/> 3208 3173 <t> 3209 The "TE" request-header field indicates what extension transfer-codings3174 The "TE" header field indicates what extension transfer-codings 3210 3175 it is willing to accept in the response, and whether or not it is 3211 3176 willing to accept trailer fields in a chunked transfer-coding. … … 3288 3253 <x:anchor-alias value="Trailer-v"/> 3289 3254 <t> 3290 The "Trailer" general-header field indicates that the given set of3255 The "Trailer" header field indicates that the given set of 3291 3256 header fields is present in the trailer of a message encoded with 3292 3257 chunked transfer-coding. … … 3324 3289 <x:anchor-alias value="Transfer-Encoding-v"/> 3325 3290 <t> 3326 The "Transfer-Encoding" general-header field indicates what transfer-codings3291 The "Transfer-Encoding" header field indicates what transfer-codings 3327 3292 (if any) have been applied to the message body. It differs from 3328 3293 Content-Encoding (&content-codings;) in that transfer-codings are a property … … 3359 3324 <x:anchor-alias value="Upgrade-v"/> 3360 3325 <t> 3361 The "Upgrade" general-header field allows the client to specify what3326 The "Upgrade" header field allows the client to specify what 3362 3327 additional communication protocols it would like to use, if the server 3363 3328 chooses to switch protocols. Servers can use it to indicate what protocols … … 3471 3436 <x:anchor-alias value="Via-v"/> 3472 3437 <t> 3473 The "Via" general-header field &MUST; be used by gateways and proxies to3438 The "Via" header field &MUST; be used by gateways and proxies to 3474 3439 indicate the intermediate protocols and recipients between the user 3475 3440 agent and the server on requests, and between the origin server and … … 4922 4887 <section title="Changes to Simplify Multi-homed Web Servers and Conserve IP Addresses" anchor="changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses"> 4923 4888 <t> 4924 The requirements that clients and servers support the Host request-header4889 The requirements that clients and servers support the Host header 4925 4890 field (<xref target="header.host"/>), report an error if it is 4926 4891 missing from an HTTP/1.1 request, and accept absolute URIs (<xref target="request-target"/>) … … 4945 4910 requirements: 4946 4911 <list style="symbols"> 4947 <t>Both clients and servers &MUST; support the Host request-header field.</t>4912 <t>Both clients and servers &MUST; support the Host header field.</t> 4948 4913 4949 4914 <t>A client that sends an HTTP/1.1 request &MUST; send a Host header field.</t> 4950 4915 4951 4916 <t>Servers &MUST; report a 400 (Bad Request) error if an HTTP/1.1 4952 request does not include a Host request-header field.</t>4917 request does not include a Host header field.</t> 4953 4918 4954 4919 <t>Servers &MUST; accept absolute URIs.</t> … … 5054 5019 <x:ref>BWS</x:ref> = OWS 5055 5020 5056 <x:ref>Cache-Control</x:ref> = <Cache-Control, defined in [Part6], Section 3.4>5057 5021 <x:ref>Chunked-Body</x:ref> = *chunk last-chunk trailer-part CRLF 5058 5022 <x:ref>Connection</x:ref> = "Connection:" OWS Connection-v … … 5075 5039 <x:ref>Host-v</x:ref> = uri-host [ ":" port ] 5076 5040 5077 <x:ref>MIME-Version</x:ref> = <MIME-Version, defined in [Part3], Appendix A.1>5078 5041 <x:ref>Method</x:ref> = token 5079 5042 5080 5043 <x:ref>OWS</x:ref> = *( [ obs-fold ] WSP ) 5081 5082 <x:ref>Pragma</x:ref> = <Pragma, defined in [Part6], Section 3.4>5083 5044 5084 5045 <x:ref>RWS</x:ref> = 1*( [ obs-fold ] WSP ) … … 5107 5068 ] *( OWS "," [ OWS received-protocol RWS received-by [ RWS comment ] 5108 5069 ] ) 5109 5110 <x:ref>Warning</x:ref> = <Warning, defined in [Part6], Section 3.6>5111 5070 5112 5071 <x:ref>absolute-URI</x:ref> = <absolute-URI, defined in [RFC3986], Section 4.3> … … 5203 5162 <x:ref>received-protocol</x:ref> = [ protocol-name "/" ] protocol-version 5204 5163 <x:ref>relative-part</x:ref> = <relative-part, defined in [RFC3986], Section 4.2> 5205 <x:ref>request-header</x:ref> = <request-header, defined in [Part2], Section 3>5206 5164 <x:ref>request-target</x:ref> = "*" / absolute-URI / ( path-absolute [ "?" query ] ) 5207 5165 / authority 5208 <x:ref>response-header</x:ref> = <response-header, defined in [Part2], Section 5>5209 5166 <x:ref>rfc1123-date</x:ref> = day-name "," SP date1 SP time-of-day SP GMT 5210 5167 <x:ref>rfc850-date</x:ref> = day-name-l "," SP date2 SP time-of-day SP GMT … … 5238 5195 </figure> 5239 5196 <figure><preamble>ABNF diagnostics:</preamble><artwork type="inline"> 5240 ; Cache-Control defined but not used5241 5197 ; Chunked-Body defined but not used 5242 5198 ; Connection defined but not used … … 5245 5201 ; HTTP-message defined but not used 5246 5202 ; Host defined but not used 5247 ; MIME-Version defined but not used5248 ; Pragma defined but not used5249 5203 ; Request defined but not used 5250 5204 ; Response defined but not used … … 5255 5209 ; Upgrade defined but not used 5256 5210 ; Via defined but not used 5257 ; Warning defined but not used5258 5211 ; http-URI defined but not used 5259 5212 ; https-URI defined but not used 5260 5213 ; partial-URI defined but not used 5261 ; request-header defined but not used5262 ; response-header defined but not used5263 5214 ; special defined but not used 5264 5215 </artwork></figure></section> -
draft-ietf-httpbis/latest/p2-semantics.xml
r1161 r1163 246 246 that defines the protocol referred to as "HTTP/1.1" and, taken together, 247 247 obsoletes RFC 2616. Part 2 defines the semantics of HTTP messages 248 as expressed by request methods, request -header fields, response status codes,249 and response -header fields.248 as expressed by request methods, request header fields, response status codes, 249 and response header fields. 250 250 </t> 251 251 </abstract> … … 282 282 In particular, the sections will be ordered according to the typical 283 283 processing of an HTTP request message (after message parsing): resource 284 mapping, general header fields, methods, request modifiers, response285 status , and resource metadata. The current mess reflects how widely286 dispersed these topics and associated requirements had become in287 <xref target="RFC2616"/>.284 mapping, methods, request modifying header fields, response status, 285 status modifying header fields, and resource metadata. The current mess 286 reflects how widely dispersed these topics and associated requirements 287 had become in <xref target="RFC2616"/>. 288 288 </t> 289 289 … … 530 530 <x:anchor-alias value="request-header"/> 531 531 <t> 532 The request -header fields allow the client to pass additional532 The request header fields allow the client to pass additional 533 533 information about the request, and about the client itself, to the 534 534 server. These fields act as request modifiers, with semantics … … 560 560 <c>User-Agent</c> <c><xref target="header.user-agent"/></c> 561 561 </texttable> 562 <t>563 Request-header field names can be extended reliably only in564 combination with a change in the protocol version. However, new or565 experimental header fields &MAY; be given the semantics of request-header566 fields if all parties in the communication recognize them to567 be request-header fields.568 </t>569 562 </section> 570 563 … … 723 716 <x:anchor-alias value="response-header"/> 724 717 <t> 725 The response -header fields allow the server to pass additional718 The response header fields allow the server to pass additional 726 719 information about the response which cannot be placed in the Status-Line. 727 720 These header fields give information about the server and about … … 729 722 </t> 730 723 <texttable align="left"> 731 <ttcol> Method Name</ttcol><ttcol>Defined in...</ttcol>724 <ttcol>Header Field Name</ttcol><ttcol>Defined in...</ttcol> 732 725 733 726 <c>Accept-Ranges</c> <c>&header-accept-ranges;</c> … … 742 735 <c>WWW-Authenticate</c> <c>&header-www-authenticate;</c> 743 736 </texttable> 744 <t>745 Response-header field names can be extended reliably only in746 combination with a change in the protocol version. However, new or747 experimental header fields &MAY; be given the semantics of response-header748 fields if all parties in the communication recognize them to749 be response-header fields.750 </t>751 737 </section> 752 738 … … 911 897 </t> 912 898 <t> 913 The Max-Forwards request-header field &MAY; be used to target a899 The Max-Forwards header field &MAY; be used to target a 914 900 specific proxy in the request chain (see <xref target="header.max-forwards"/>). 915 901 If no Max-Forwards field is present in the request, then the forwarded … … 1967 1953 </rdf:Description> 1968 1954 <t> 1969 The precondition given in one or more of the request-header fields1955 The precondition given in one or more of the header fields 1970 1956 evaluated to false when it was tested on the server, as defined in 1971 1957 &status-412;. … … 2022 2008 </rdf:Description> 2023 2009 <t> 2024 The request included a Range request-header field (&header-range;) and none of2010 The request included a Range header field (&header-range;) and none of 2025 2011 the range-specifier values in this field overlap the current extent 2026 2012 of the selected resource. See &status-416;. … … 2032 2018 <iref primary="true" item="Status Codes" subitem="417 Expectation Failed" x:for-anchor=""/> 2033 2019 <t> 2034 The expectation given in an Expect request-header field (see <xref target="header.expect"/>)2020 The expectation given in an Expect header field (see <xref target="header.expect"/>) 2035 2021 could not be met by this server, or, if the server is a proxy, 2036 2022 the server has unambiguous evidence that the request could not be met … … 2171 2157 <x:anchor-alias value="Allow-v"/> 2172 2158 <t> 2173 The "Allow" response-header field lists the set of methods advertised as2159 The "Allow" header field lists the set of methods advertised as 2174 2160 supported by the target resource. The purpose of this field is strictly to 2175 2161 inform the recipient of valid request methods associated with the resource. … … 2205 2191 <x:anchor-alias value="expect-params"/> 2206 2192 <t> 2207 The "Expect" request-header field is used to indicate that particular2193 The "Expect" header field is used to indicate that particular 2208 2194 server behaviors are required by the client. 2209 2195 </t> … … 2240 2226 return a 417 (Expectation Failed) status code if it receives a request 2241 2227 with an expectation that it cannot meet. However, the Expect 2242 request-header field itself is end-to-end; it &MUST; be forwarded if the2228 header field itself is end-to-end; it &MUST; be forwarded if the 2243 2229 request is forwarded. 2244 2230 </t> … … 2259 2245 <x:anchor-alias value="mailbox"/> 2260 2246 <t> 2261 The "From" request-header field, if given, &SHOULD; contain an Internet2247 The "From" header field, if given, &SHOULD; contain an Internet 2262 2248 e-mail address for the human user who controls the requesting user 2263 2249 agent. The address &SHOULD; be machine-usable, as defined by "mailbox" … … 2307 2293 <x:anchor-alias value="Location-v"/> 2308 2294 <t> 2309 The "Location" response-header field is used to identify a newly created2295 The "Location" header field is used to identify a newly created 2310 2296 resource, or to redirect the recipient to a different location for 2311 2297 completion of the request. … … 2369 2355 <x:anchor-alias value="Max-Forwards-v"/> 2370 2356 <t> 2371 The "Max-Forwards" request-header field provides a mechanism with the2357 The "Max-Forwards" header field provides a mechanism with the 2372 2358 TRACE (<xref target="TRACE"/>) and OPTIONS (<xref target="OPTIONS"/>) 2373 2359 methods to limit the number of times that the request is forwarded by … … 2404 2390 <x:anchor-alias value="Referer-v"/> 2405 2391 <t> 2406 The "Referer" [sic] request-header field allows the client to specify the2392 The "Referer" [sic] header field allows the client to specify the 2407 2393 URI of the resource from which the effective request URI was obtained (the 2408 2394 "referrer", although the header field is misspelled.). … … 2445 2431 <x:anchor-alias value="Retry-After-v"/> 2446 2432 <t> 2447 The response-header "Retry-After" field can be used with a 503 (Service2433 The header "Retry-After" field can be used with a 503 (Service 2448 2434 Unavailable) response to indicate how long the service is expected to 2449 2435 be unavailable to the requesting client. This field &MAY; also be used … … 2485 2471 <x:anchor-alias value="Server-v"/> 2486 2472 <t> 2487 The "Server" response-header field contains information about the2473 The "Server" header field contains information about the 2488 2474 software used by the origin server to handle the request. 2489 2475 </t> … … 2507 2493 <t> 2508 2494 If the response is being forwarded through a proxy, the proxy 2509 application &MUST-NOT; modify the Server response-header field. Instead, it2495 application &MUST-NOT; modify the Server header field. Instead, it 2510 2496 &MUST; include a Via field (as described in &header-via;). 2511 2497 </t> … … 2527 2513 <x:anchor-alias value="User-Agent-v"/> 2528 2514 <t> 2529 The "User-Agent" request-header field contains information about the user2515 The "User-Agent" header field contains information about the user 2530 2516 agent originating the request. User agents &SHOULD; include this field with 2531 2517 requests. -
draft-ietf-httpbis/latest/p3-payload.xml
r1161 r1163 908 908 </t> 909 909 <t> 910 HTTP/1.1 includes the following request-header fields for enabling910 HTTP/1.1 includes the following header fields for enabling 911 911 server-driven negotiation through description of user agent 912 912 capabilities and user preferences: Accept (<xref target="header.accept"/>), Accept-Charset … … 914 914 (<xref target="header.accept-language"/>), and User-Agent (&header-user-agent;). 915 915 However, an origin server is not limited to these dimensions and &MAY; vary 916 the response based on any aspect of the request, including information917 o utside the request-header fields or within extension header fields918 not defined by this specification.916 the response based on any aspect of the request, including aspects 917 of the connection (e.g., IP address) or information within extension 918 header fields not defined by this specification. 919 919 </t> 920 920 <x:note> … … 983 983 <x:anchor-alias value="media-range"/> 984 984 <t> 985 The "Accept" request-header field can be used by user agents to specify985 The "Accept" header field can be used by user agents to specify 986 986 response media types that are acceptable. Accept header fields can be used to 987 987 indicate that the request is specifically limited to a small set of desired … … 1108 1108 <x:anchor-alias value="Accept-Charset-v"/> 1109 1109 <t> 1110 The "Accept-Charset" request-header field can be used by user agents to1110 The "Accept-Charset" header field can be used by user agents to 1111 1111 indicate what response character sets are acceptable. This field allows 1112 1112 clients capable of understanding more comprehensive or special-purpose … … 1153 1153 <x:anchor-alias value="codings"/> 1154 1154 <t> 1155 The "Accept-Encoding" request-header field can be used by user agents to1155 The "Accept-Encoding" header field can be used by user agents to 1156 1156 indicate what response content-codings (<xref target="content.codings"/>) 1157 1157 are acceptable in the response. … … 1243 1243 <x:anchor-alias value="language-range"/> 1244 1244 <t> 1245 The "Accept-Language" request-header field can be used by user agents to1245 The "Accept-Language" header field can be used by user agents to 1246 1246 indicate the set of natural languages that are preferred in the response. 1247 1247 Language tags are defined in <xref target="language.tags"/>. … … 1736 1736 <section title="Privacy Issues Connected to Accept Header Fields" anchor="privacy.issues.connected.to.accept.header.fields"> 1737 1737 <t> 1738 Accept request-headers fields can reveal information about the user to all1738 Accept headers fields can reveal information about the user to all 1739 1739 servers which are accessed. The Accept-Language header field in particular 1740 1740 can reveal information the user would consider to be of a private … … 1750 1750 to omit the sending of Accept-Language header fields by default, and to ask 1751 1751 the user whether or not to start sending Accept-Language header fields to a 1752 server if it detects, by looking for any Vary response-header fields1752 server if it detects, by looking for any Vary header fields 1753 1753 generated by the server, that such sending could improve the quality 1754 1754 of service. … … 2526 2526 <t> 2527 2527 HTTP is not a MIME-compliant protocol. However, HTTP/1.1 messages &MAY; 2528 include a single MIME-Version general-header field to indicate what2528 include a single MIME-Version header field to indicate what 2529 2529 version of the MIME protocol was used to construct the message. Use 2530 2530 of the MIME-Version header field indicates that the message is in -
draft-ietf-httpbis/latest/p4-conditional.xml
r1161 r1163 229 229 A future draft will reorganize the sections to better reflect the content. 230 230 In particular, the sections on resource metadata will be discussed first 231 and then followed by each conditional request -header field, concluding with a231 and then followed by each conditional request header field, concluding with a 232 232 definition of precedence and the expectation of ordering strong validator 233 233 checks before weak validator checks. It is likely that more content from … … 442 442 <iref primary="true" item="Status Codes" subitem="412 Precondition Failed" x:for-anchor=""/> 443 443 <t> 444 The precondition given in one or more of the request-header fields444 The precondition given in one or more of the header fields 445 445 evaluated to false when it was tested on the server. This response 446 446 code allows the client to place preconditions on the current resource … … 730 730 <x:anchor-alias value="ETag-v"/> 731 731 <t> 732 The "ETag" response-header field provides the current value of the732 The "ETag" header field provides the current value of the 733 733 entity-tag (see <xref target="entity.tags"/>) for one representation of 734 734 the target resource. An entity-tag … … 774 774 <x:anchor-alias value="If-Match-v"/> 775 775 <t> 776 The "If-Match" request-header field is used to make a request method776 The "If-Match" header field is used to make a request method 777 777 conditional. A client that has one or more representations previously 778 778 obtained from the resource can verify that one of those representations is … … 844 844 <x:anchor-alias value="If-Modified-Since-v"/> 845 845 <t> 846 The "If-Modified-Since" request-header field is used to make a request846 The "If-Modified-Since" header field is used to make a request 847 847 method conditional by date: if the representation that would have been 848 848 transferred in a 200 response to a GET request has not been modified since … … 885 885 information with a minimum amount of transaction overhead. 886 886 <list><t> 887 <x:h>Note:</x:h> The Range request-header field modifies the meaning of If-Modified-Since;887 <x:h>Note:</x:h> The Range header field modifies the meaning of If-Modified-Since; 888 888 see &header-range; for full details. 889 889 </t><t> … … 929 929 <x:anchor-alias value="If-None-Match-v"/> 930 930 <t> 931 The "If-None-Match" request-header field is used to make a request method931 The "If-None-Match" header field is used to make a request method 932 932 conditional. A client that has one or more representations previously 933 933 obtained from the resource can verify that none of those representations is … … 1008 1008 <x:anchor-alias value="If-Unmodified-Since-v"/> 1009 1009 <t> 1010 The "If-Unmodified-Since" request-header field is used to make a request1010 The "If-Unmodified-Since" header field is used to make a request 1011 1011 method conditional. If the representation that would have been transferred 1012 1012 in a 200 response to a GET request on the same resource has not been modified -
draft-ietf-httpbis/latest/p5-range.xml
r1145 r1163 417 417 <t> 418 418 A server &SHOULD; return a response with this status code if a request 419 included a Range request-header field (<xref target="header.range"/>), and none of419 included a Range header field (<xref target="header.range"/>), and none of 420 420 the ranges-specifier values in this field overlap the current extent 421 421 of the selected resource, and the request did not include an If-Range 422 request-header field (<xref target="header.if-range"/>). (For byte-ranges,422 header field (<xref target="header.if-range"/>). (For byte-ranges, 423 423 this means that the first-byte-pos of all of the byte-range-spec values were 424 424 greater than the current length of the selected resource.) … … 474 474 <x:anchor-alias value="acceptable-ranges"/> 475 475 <t> 476 The "Accept-Ranges" response-header field allows a resource to indicate476 The "Accept-Ranges" header field allows a resource to indicate 477 477 its acceptance of range requests. 478 478 </t> … … 643 643 <t> 644 644 If the server receives a request (other than one including an If-Range 645 request-header field) with an unsatisfiable Range request-header645 header field) with an unsatisfiable Range header 646 646 field (that is, all of whose byte-range-spec values have a 647 647 first-byte-pos value greater than the current length of the selected … … 653 653 <x:h>Note:</x:h> Clients cannot depend on servers to send a 416 (Requested 654 654 range not satisfiable) response instead of a 200 (OK) response for 655 an unsatisfiable Range request-header field, since not all servers656 implement this request-header field.655 an unsatisfiable Range header field, since not all servers 656 implement this header field. 657 657 </t> 658 658 </x:note> … … 667 667 If a client has a partial copy of a representation in its cache, and wishes 668 668 to have an up-to-date copy of the entire representation in its cache, it 669 could use the Range request-header field with a conditional GET (using669 could use the Range header field with a conditional GET (using 670 670 either or both of If-Unmodified-Since and If-Match.) However, if the 671 671 condition fails because the representation has been modified, the client … … 674 674 </t> 675 675 <t> 676 The "If-Range" request-header field allows a client to "short-circuit" the second676 The "If-Range" header field allows a client to "short-circuit" the second 677 677 request. Informally, its meaning is "if the representation is unchanged, send 678 678 me the part(s) that I am missing; otherwise, send me the entire new … … 826 826 <x:anchor-alias value="other-range-set"/> 827 827 <t> 828 The "Range" request-header field defines the GET method (conditional or828 The "Range" header field defines the GET method (conditional or 829 829 not) to request one or more sub-ranges of the response representation body, instead 830 830 of the entire representation body. -
draft-ietf-httpbis/latest/p6-cache.xml
r1145 r1163 522 522 <t>the request method associated with the stored response allows it to 523 523 be used for the presented request, and</t> 524 <t>selecting request-header fields nominated by the stored response (if any)524 <t>selecting header fields nominated by the stored response (if any) 525 525 match those presented (see <xref target="caching.negotiated.responses" 526 526 />), and</t> … … 690 690 <section anchor="age.calculations" title="Calculating Age"> 691 691 <t> 692 HTTP/1.1 uses the Age response-header field to convey the estimated age of the692 HTTP/1.1 uses the Age header field to convey the estimated age of the 693 693 response message when obtained from a cache. The Age field value is the 694 694 cache's estimate of the amount of time since the response was generated or … … 940 940 When a cache receives a request that can be satisfied by a stored response 941 941 that has a Vary header field (<xref target="header.vary"/>), it &MUST-NOT; 942 use that response unless all of the selecting request-header fields nominated by942 use that response unless all of the selecting header fields nominated by 943 943 the Vary header field match in both the original request (i.e., that associated 944 944 with the stored response), and the presented request. 945 945 </t> 946 946 <t> 947 The selecting request-header fields from two requests are defined to match if and947 The selecting header fields from two requests are defined to match if and 948 948 only if those in the first request can be transformed to those in the 949 949 second request by applying any of the following: … … 953 953 </t> 954 954 <t> 955 combining multiple message-header fields with the same field name955 combining multiple header fields with the same field name 956 956 (see &header-fields;) 957 957 </t> … … 975 975 </t> 976 976 <t> 977 The stored response with matching selecting request-header fields is known as the977 The stored response with matching selecting header fields is known as the 978 978 selected response. 979 979 </t> … … 1040 1040 <x:anchor-alias value="age-value"/> 1041 1041 <t> 1042 The "Age" response-header field conveys the sender's estimate of the amount1042 The "Age" header field conveys the sender's estimate of the amount 1043 1043 of time since the response was generated or successfully validated at the 1044 1044 origin server. Age values are calculated as specified in <xref … … 1081 1081 <x:anchor-alias value="cache-response-directive"/> 1082 1082 <t> 1083 The "Cache-Control" general-header field is used to specify directives for1083 The "Cache-Control" header field is used to specify directives for 1084 1084 caches along the request/response chain. Such cache directives are 1085 1085 unidirectional in that the presence of a directive in a request does not … … 1506 1506 <x:anchor-alias value="pragma-directive"/> 1507 1507 <t> 1508 The "Pragma" general-header field is used to include1508 The "Pragma" header field is used to include 1509 1509 implementation-specific directives that might apply to any recipient along 1510 1510 the request/response chain. All pragma directives specify optional behavior … … 1532 1532 <t> 1533 1533 <x:h>Note:</x:h> Because the meaning of "Pragma: no-cache" as a 1534 response-header field is not actually specified, it does not provide a1534 header field is not actually specified, it does not provide a 1535 1535 reliable replacement for "Cache-Control: no-cache" in a response. 1536 1536 </t> … … 1548 1548 <x:anchor-alias value="Vary-v"/> 1549 1549 <t> 1550 The "Vary" response-header field conveys the set of request-header fields1550 The "Vary" header field conveys the set of header fields 1551 1551 that were used to select the representation. 1552 1552 </t> … … 1569 1569 <t> 1570 1570 The set of header fields named by the Vary field value is known as the 1571 selecting request-header fields.1571 selecting header fields. 1572 1572 </t> 1573 1573 <t> … … 1583 1583 <t> 1584 1584 A Vary field value of "*" signals that unspecified parameters not limited 1585 to the request-header fields (e.g., the network address of the client), play a1585 to the header fields (e.g., the network address of the client), play a 1586 1586 role in the selection of the response representation; therefore, a cache 1587 1587 cannot determine whether this response is appropriate. A proxy &MUST-NOT; … … 1589 1589 </t> 1590 1590 <t> 1591 The field-names given are not limited to the set of standard request-header1591 The field-names given are not limited to the set of standard header 1592 1592 fields defined by this specification. Field names are case-insensitive. 1593 1593 </t> … … 1605 1605 <x:anchor-alias value="warn-text"/> 1606 1606 <t> 1607 The "Warning" general-header field is used to carry additional information1607 The "Warning" header field is used to carry additional information 1608 1608 about the status or transformation of a message that might not be reflected 1609 1609 in the message. This information is typically used to warn about possible -
draft-ietf-httpbis/latest/p7-auth.xml
r1145 r1163 469 469 <x:anchor-alias value="Authorization-v"/> 470 470 <t> 471 The "Authorization" request-header field allows a user agent to authenticate471 The "Authorization" header field allows a user agent to authenticate 472 472 itself with a server — usually, but not necessarily, after receiving a 401 473 473 (Unauthorized) response. Its value consists of credentials containing … … 499 499 subsequent request. But (if the specified maximum age has 500 500 passed) a proxy cache &MUST; first revalidate it with the origin 501 server, using the request-header fields from the new request to allow501 server, using the header fields from the new request to allow 502 502 the origin server to authenticate the new request. (This is the 503 503 defined behavior for s-maxage.) If the response includes "s-maxage=0", … … 509 509 subsequent request. But if the response is stale, all caches 510 510 &MUST; first revalidate it with the origin server, using the 511 request-header fields from the new request to allow the origin server511 header fields from the new request to allow the origin server 512 512 to authenticate the new request.</t> 513 513 … … 524 524 <x:anchor-alias value="Proxy-Authenticate-v"/> 525 525 <t> 526 The "Proxy-Authenticate" response-header field consists of a challenge that526 The "Proxy-Authenticate" header field consists of a challenge that 527 527 indicates the authentication scheme and parameters applicable to the proxy 528 528 for this effective request URI (&effective-request-uri;). It &MUST; be included as part … … 550 550 <x:anchor-alias value="Proxy-Authorization-v"/> 551 551 <t> 552 The "Proxy-Authorization" request-header field allows the client to552 The "Proxy-Authorization" header field allows the client to 553 553 identify itself (or its user) to a proxy which requires 554 554 authentication. Its value consists of … … 579 579 <x:anchor-alias value="WWW-Authenticate-v"/> 580 580 <t> 581 The "WWW-Authenticate" response-header field consists of at least one581 The "WWW-Authenticate" header field consists of at least one 582 582 challenge that indicates the authentication scheme(s) and parameters 583 583 applicable to the effective request URI (&effective-request-uri;). It &MUST; be included in 401
Note: See TracChangeset
for help on using the changeset viewer.