Changeset 972
- Timestamp:
- 02/08/10 13:20:54 (12 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 12 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r971 r972 404 404 <meta name="dct.creator" content="Reschke, J. F."> 405 405 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p1-messaging-latest"> 406 <meta name="dct.issued" scheme="ISO8601" content="2010-08-0 1">406 <meta name="dct.issued" scheme="ISO8601" content="2010-08-02"> 407 407 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 408 408 <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 1 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 1 provides an overview of HTTP and its associated terminology, defines the "http" and "https" Uniform Resource Identifier (URI) schemes, defines the generic message syntax and parsing requirements for HTTP message frames, and describes general security concerns for implementations."> … … 435 435 </tr> 436 436 <tr> 437 <td class="left">Expires: February 2, 2011</td>437 <td class="left">Expires: February 3, 2011</td> 438 438 <td class="right">HP</td> 439 439 </tr> … … 488 488 <tr> 489 489 <td class="left"></td> 490 <td class="right">August 1, 2010</td>490 <td class="right">August 2, 2010</td> 491 491 </tr> 492 492 </tbody> … … 516 516 in progress”. 517 517 </p> 518 <p>This Internet-Draft will expire on February 2, 2011.</p>518 <p>This Internet-Draft will expire on February 3, 2011.</p> 519 519 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 520 520 <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 1434 1434 <li>the request-target obtained from the Request-Line, unless the request-target is just the asterisk "*".</li> 1435 1435 </ul> 1436 <p id="rfc.section.4.3.p.5">Otherwise, when request-target uses the authority form, the Effective Request URI is undefined.</p>1436 <p id="rfc.section.4.3.p.5">Otherwise, when request-target uses the authority form, the effective Request URI is undefined.</p> 1437 1437 <div id="rfc.figure.u.40"></div> 1438 1438 <p>Example 1: the effective request URI for the message</p> <pre class="text">GET /pub/WWW/TheProject.html HTTP/1.1 -
draft-ietf-httpbis/latest/p1-messaging.xml
r971 r972 1709 1709 </t> 1710 1710 <t> 1711 Otherwise, when request-target uses the authority form, the Effective1711 Otherwise, when request-target uses the authority form, the effective 1712 1712 Request URI is undefined. 1713 1713 </t> -
draft-ietf-httpbis/latest/p2-semantics.html
r971 r972 403 403 <meta name="dct.creator" content="Reschke, J. F."> 404 404 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest"> 405 <meta name="dct.issued" scheme="ISO8601" content="2010-08-0 1">405 <meta name="dct.issued" scheme="ISO8601" content="2010-08-02"> 406 406 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 407 407 <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 2 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 2 defines the semantics of HTTP messages as expressed by request methods, request-header fields, response status codes, and response-header fields."> … … 434 434 </tr> 435 435 <tr> 436 <td class="left">Expires: February 2, 2011</td>436 <td class="left">Expires: February 3, 2011</td> 437 437 <td class="right">HP</td> 438 438 </tr> … … 487 487 <tr> 488 488 <td class="left"></td> 489 <td class="right">August 1, 2010</td>489 <td class="right">August 2, 2010</td> 490 490 </tr> 491 491 </tbody> … … 514 514 in progress”. 515 515 </p> 516 <p>This Internet-Draft will expire on February 2, 2011.</p>516 <p>This Internet-Draft will expire on February 3, 2011.</p> 517 517 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 518 518 <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 753 753 <WWW-Authenticate, defined in <a href="#Part7" id="rfc.xref.Part7.4"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a>, <a href="p7-auth.html#header.www-authenticate" title="WWW-Authenticate">Section 3.4</a>> 754 754 </pre><h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a> <a id="method" href="#method">Method</a></h1> 755 <p id="rfc.section.2.p.1">The Method token indicates the method to be performed on the resource identified by the effective request URI(<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.17"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). The method is case-sensitive.755 <p id="rfc.section.2.p.1">The Method token indicates the method to be performed on the target resource (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.17"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). The method is case-sensitive. 756 756 </p> 757 757 <div id="rfc.figure.u.8"></div><pre class="inline"><span id="rfc.iref.g.1"></span><span id="rfc.iref.g.2"></span> <a href="#method" class="smpl">Method</a> = %x4F.50.54.49.4F.4E.53 ; "OPTIONS", <a href="#OPTIONS" id="rfc.xref.OPTIONS.1" title="OPTIONS">Section 7.2</a> … … 881 881 <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a> <a id="response.header.fields" href="#response.header.fields">Response Header Fields</a></h1> 882 882 <p id="rfc.section.5.p.1">The response-header fields allow the server to pass additional information about the response which cannot be placed in the 883 Status-Line. These header fields give information about the server and about further access to the resource identified by 884 the effective request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.20"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). 883 Status-Line. These header fields give information about the server and about further access to the target resource (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.20"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). 885 884 </p> 886 885 <div id="rfc.figure.u.11"></div><pre class="inline"><span id="rfc.iref.g.7"></span> <a href="#response.header.fields" class="smpl">response-header</a> = <a href="#abnf.dependencies" class="smpl">Accept-Ranges</a> ; <a href="#Part5" id="rfc.xref.Part5.9"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>, <a href="p5-range.html#header.accept-ranges" title="Accept-Ranges">Section 5.1</a> … … 909 908 <p id="rfc.section.6.1.p.1">It is sometimes necessary to determine an identifier for the resource associated with a representation.</p> 910 909 <p id="rfc.section.6.1.p.2">An HTTP request representation, when present, is always associated with an anonymous (i.e., unidentified) resource.</p> 911 <p id="rfc.section.6.1.p.3">In the common case, an HTTP response is a representation of the resource located at the effective request URI(see <a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.22"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). However, this is not always the case. To determine the URI of the resource a response is associated with, the following910 <p id="rfc.section.6.1.p.3">In the common case, an HTTP response is a representation of the target resource (see <a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.22"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). However, this is not always the case. To determine the URI of the resource a response is associated with, the following 912 911 rules are used (with the first applicable one being selected): 913 912 </p> 914 913 <ol> 915 914 <li>If the response status code is 200 or 203 and the request method was GET, the response payload is a representation of the 916 resource identified by the effective request URI.915 target resource. 917 916 </li> 918 917 <li>If the response status code is 204, 206, or 304 and the request method was GET or HEAD, the response payload is a partial 919 representation of the resource identified by the effective request URI(see <a href="p6-cache.html#combining.headers" title="Combining Responses">Section 2.8</a> of <a href="#Part6" id="rfc.xref.Part6.5"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>).918 representation of the target (see <a href="p6-cache.html#combining.headers" title="Combining Responses">Section 2.8</a> of <a href="#Part6" id="rfc.xref.Part6.5"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). 920 919 </li> 921 920 <li>If the response has a Content-Location header, and that URI is the same as the effective request URI, the response payload 922 is a representation of the resource identified by the effective request URI.921 is a representation of the target resource. 923 922 </li> 924 923 <li>If the response has a Content-Location header, and that URI is not the same as the effective request URI, then the response … … 984 983 <div id="rfc.iref.g.8"></div> 985 984 <div id="rfc.iref.m.2"></div> 986 <p id="rfc.section.7.3.p.1">The GET method means retrieve whatever information (in the form of a representation) currently corresponds to the resource 987 identified by the effective request URI. 988 </p> 989 <p id="rfc.section.7.3.p.2">If the effective request URI identifies a data-producing process, it is the produced data which shall be returned as the representation 985 <p id="rfc.section.7.3.p.1">The GET method means retrieve whatever information (in the form of a representation) currently corresponds to the target resource.</p> 986 <p id="rfc.section.7.3.p.2">If the target resource is a data-producing process, it is the produced data which shall be returned as the representation 990 987 in the response and not the source text of the process, unless that text happens to be the output of the process. 991 988 </p> … … 1019 1016 <h2 id="rfc.section.7.5"><a href="#rfc.section.7.5">7.5</a> <a id="POST" href="#POST">POST</a></h2> 1020 1017 <p id="rfc.section.7.5.p.1">The POST method is used to request that the origin server accept the representation enclosed in the request as data to be 1021 processed by the resource identified by the effective request URI. POST is designed to allow a uniform method to cover the 1022 following functions: 1018 processed by the target resource. POST is designed to allow a uniform method to cover the following functions: 1023 1019 </p> 1024 1020 <ul> … … 1038 1034 a Location header (see <a href="#header.location" id="rfc.xref.header.location.2" title="Location">Section 9.4</a>). 1039 1035 </p> 1040 <p id="rfc.section.7.5.p.5">Responses to POST requests are only cacheable when they include explicit freshness information (see <a href="p6-cache.html#calculating.freshness.lifetime" title="Calculating Freshness Lifetime">Section 2.3.1</a> of <a href="#Part6" id="rfc.xref.Part6.8"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). A cached POST response with a Content-Location header (see <a href="p3-payload.html#header.content-location" title="Content-Location">Section 6.7</a> of <a href="#Part3" id="rfc.xref.Part3.10"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) whose value is the Effective Request URI <em class="bcp14">MAY</em> be used to satisfy subsequent GET and HEAD requests.1036 <p id="rfc.section.7.5.p.5">Responses to POST requests are only cacheable when they include explicit freshness information (see <a href="p6-cache.html#calculating.freshness.lifetime" title="Calculating Freshness Lifetime">Section 2.3.1</a> of <a href="#Part6" id="rfc.xref.Part6.8"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). A cached POST response with a Content-Location header (see <a href="p3-payload.html#header.content-location" title="Content-Location">Section 6.7</a> of <a href="#Part3" id="rfc.xref.Part3.10"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) whose value is the effective Request URI <em class="bcp14">MAY</em> be used to satisfy subsequent GET and HEAD requests. 1041 1037 </p> 1042 1038 <p id="rfc.section.7.5.p.6">Note that POST caching is not widely implemented. However, the 303 (See Other) response can be used to direct the user agent … … 1054 1050 Content) response codes <em class="bcp14">SHOULD</em> be sent to indicate successful completion of the request. 1055 1051 </p> 1056 <p id="rfc.section.7.6.p.3">If the resource identified by the effective request URIcould not be created or modified, an appropriate error response <em class="bcp14">SHOULD</em> be given that reflects the nature of the problem. The recipient of the representation <em class="bcp14">MUST NOT</em> ignore any Content-* headers (headers starting with the prefix "Content-") that it does not understand or implement and <em class="bcp14">MUST</em> return a 501 (Not Implemented) response in such cases.1052 <p id="rfc.section.7.6.p.3">If the target resource could not be created or modified, an appropriate error response <em class="bcp14">SHOULD</em> be given that reflects the nature of the problem. The recipient of the representation <em class="bcp14">MUST NOT</em> ignore any Content-* headers (headers starting with the prefix "Content-") that it does not understand or implement and <em class="bcp14">MUST</em> return a 501 (Not Implemented) response in such cases. 1057 1053 </p> 1058 1054 <p id="rfc.section.7.6.p.4">If the request passes through a cache that has one or more stored responses for the effective request URI, those stored responses <em class="bcp14">SHOULD</em> be marked as stale if the response to the PUT request has a success status code. Responses to the PUT method are not cacheable. … … 1075 1071 <div id="rfc.iref.m.6"></div> 1076 1072 <h2 id="rfc.section.7.7"><a href="#rfc.section.7.7">7.7</a> <a id="DELETE" href="#DELETE">DELETE</a></h2> 1077 <p id="rfc.section.7.7.p.1">The DELETE method requests that the origin server delete the resource identified by the effective request URI. This method <em class="bcp14">MAY</em> be overridden by human intervention (or other means) on the origin server. The client cannot be guaranteed that the operation1073 <p id="rfc.section.7.7.p.1">The DELETE method requests that the origin server delete the target resource. This method <em class="bcp14">MAY</em> be overridden by human intervention (or other means) on the origin server. The client cannot be guaranteed that the operation 1078 1074 has been carried out, even if the status code returned from the origin server indicates that the action has been completed 1079 1075 successfully. However, the server <em class="bcp14">SHOULD NOT</em> indicate success unless, at the time the response is given, it intends to delete the resource or move it to an inaccessible … … 1145 1141 <dl> 1146 1142 <dt>GET</dt> 1147 <dd>a representation of the resource corresponding to the effective request URIis sent in the response;</dd>1143 <dd>a representation of the target resource is sent in the response;</dd> 1148 1144 <dt>HEAD</dt> 1149 1145 <dd>the same representation as GET, except without the message-body;</dd> -
draft-ietf-httpbis/latest/p2-semantics.xml
r971 r972 433 433 <x:anchor-alias value="extension-method"/> 434 434 <t> 435 The Method token indicates the method to be performed on the resource 436 identified by the effective request URI (&effective-request-uri;). The 437 method is case-sensitive. 435 The Method token indicates the method to be performed on the target 436 resource (&effective-request-uri;). The method is case-sensitive. 438 437 </t> 439 438 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Method"/><iref primary="true" item="Grammar" subitem="extension-method"/> … … 634 633 information about the response which cannot be placed in the Status-Line. 635 634 These header fields give information about the server and about 636 further access to the resource identified by the effective request URI 637 (&effective-request-uri;). 635 further access to the target resource (&effective-request-uri;). 638 636 </t> 639 637 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="response-header"/> … … 684 682 </t> 685 683 <t> 686 In the common case, an HTTP response is a representation of the resource 687 located at the effective request URI (see &effective-request-uri;). However, 688 this is not always the case. To determine the URI of the resource a 689 response is associated with, the following rules are used (with the first 690 applicable one being selected): 684 In the common case, an HTTP response is a representation of the target 685 resource (see &effective-request-uri;). However, this is not always the 686 case. To determine the URI of the resource a response is associated with, 687 the following rules are used (with the first applicable one being selected): 691 688 </t> 692 689 <t><list style="numbers"> 693 690 <t>If the response status code is 200 or 203 and the request method was GET, 694 the response payload is a representation of the resource identified by the effective request URI.</t>691 the response payload is a representation of the target resource.</t> 695 692 <t>If the response status code is 204, 206, or 304 and the request method was GET 696 or HEAD, the response payload is a partial representation of the resource identified697 by the effective request URI(see &caching-combining-headers;).</t>693 or HEAD, the response payload is a partial representation of the target 694 (see &caching-combining-headers;).</t> 698 695 <t>If the response has a Content-Location header, and that URI is the same 699 696 as the effective request URI, the response payload is a representation of the 700 resource identified by the effective request URI.</t>697 target resource.</t> 701 698 <t>If the response has a Content-Location header, and that URI is not the 702 699 same as the effective request URI, then the response asserts that its … … 833 830 <t> 834 831 The GET method means retrieve whatever information (in the form of a 835 representation) currently corresponds to the resource identified by the 836 effective request URI. 832 representation) currently corresponds to the target resource. 837 833 </t> 838 834 <t> 839 If the effective request URI identifies a data-producing process, it is the835 If the target resource is a data-producing process, it is the 840 836 produced data which shall be returned as the representation in the response and not 841 837 the source text of the process, unless that text happens to be the output of … … 901 897 <t> 902 898 The POST method is used to request that the origin server accept the 903 representation enclosed in the request as data to be processed by the resource904 identified by the effective request URI. POST is designed905 to allow a uniform method to cover thefollowing functions:899 representation enclosed in the request as data to be processed by the 900 target resource. POST is designed to allow a uniform method to cover the 901 following functions: 906 902 <list style="symbols"> 907 903 <t> … … 942 938 include explicit freshness information (see &p6-explicit;). A 943 939 cached POST response with a Content-Location header 944 (see &header-content-location;) whose value is the Effective940 (see &header-content-location;) whose value is the effective 945 941 Request URI &MAY; be used to satisfy subsequent GET and HEAD requests. 946 942 </t> … … 972 968 </t> 973 969 <t> 974 If the resource identified by the effective request URI could not be 975 created or modified, an appropriate error response &SHOULD; be given 976 that reflects the nature of the problem. 970 If the target resource could not be created or modified, an appropriate 971 error response &SHOULD; be given that reflects the nature of the problem. 977 972 The recipient of the representation &MUST-NOT; ignore any Content-* 978 973 headers (headers starting with the prefix "Content-") that it does … … 1024 1019 <iref primary="true" item="Methods" subitem="DELETE" x:for-anchor=""/> 1025 1020 <t> 1026 The DELETE method requests that the origin server delete the resource1027 identified by the effective request URI. This method &MAY; be overridden by1021 The DELETE method requests that the origin server delete the target 1022 resource. This method &MAY; be overridden by 1028 1023 human intervention (or other means) on the origin server. The client cannot 1029 1024 be guaranteed that the operation has been carried out, even if the … … 1171 1166 <list style="hanging"> 1172 1167 <t hangText="GET"> 1173 a representation of the resource corresponding to the effective 1174 request URI is sent in the response; 1168 a representation of the target resource is sent in the response; 1175 1169 </t> 1176 1170 <t hangText="HEAD"> -
draft-ietf-httpbis/latest/p3-payload.html
r971 r972 402 402 <meta name="dct.creator" content="Reschke, J. F."> 403 403 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p3-payload-latest"> 404 <meta name="dct.issued" scheme="ISO8601" content="2010-08-0 1">404 <meta name="dct.issued" scheme="ISO8601" content="2010-08-02"> 405 405 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 406 406 <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 3 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 3 defines HTTP message content, metadata, and content negotiation."> … … 428 428 </tr> 429 429 <tr> 430 <td class="left">Expires: February 2, 2011</td>430 <td class="left">Expires: February 3, 2011</td> 431 431 <td class="right">J. Mogul</td> 432 432 </tr> … … 485 485 <tr> 486 486 <td class="left"></td> 487 <td class="right">August 1, 2010</td>487 <td class="right">August 2, 2010</td> 488 488 </tr> 489 489 </tbody> … … 511 511 in progress”. 512 512 </p> 513 <p>This Internet-Draft will expire on February 2, 2011.</p>513 <p>This Internet-Draft will expire on February 3, 2011.</p> 514 514 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 515 515 <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 1271 1271 <a href="#header.content-location" class="smpl">Content-Location-v</a> = 1272 1272 <a href="#abnf.dependencies" class="smpl">absolute-URI</a> / <a href="#abnf.dependencies" class="smpl">partial-URI</a> 1273 </pre><p id="rfc.section.6.7.p.3">The Content-Location value is not a replacement for the Effective Request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.21"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). It is representation metadata. It has the same syntax and semantics as the header field of the same name defined for MIME1273 </pre><p id="rfc.section.6.7.p.3">The Content-Location value is not a replacement for the effective Request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.21"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). It is representation metadata. It has the same syntax and semantics as the header field of the same name defined for MIME 1274 1274 body parts in <a href="http://tools.ietf.org/html/rfc2557#section-4">Section 4</a> of <a href="#RFC2557" id="rfc.xref.RFC2557.1"><cite title="MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)">[RFC2557]</cite></a>. However, its appearance in an HTTP message has some special implications for HTTP recipients. 1275 1275 </p> -
draft-ietf-httpbis/latest/p3-payload.xml
r971 r972 1431 1431 </artwork></figure> 1432 1432 <t> 1433 The Content-Location value is not a replacement for the Effective1433 The Content-Location value is not a replacement for the effective 1434 1434 Request URI (&effective-request-uri;). It is representation metadata. 1435 1435 It has the same syntax and semantics as the header field of the same name -
draft-ietf-httpbis/latest/p4-conditional.html
r971 r972 400 400 <meta name="dct.creator" content="Reschke, J. F."> 401 401 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p4-conditional-latest"> 402 <meta name="dct.issued" scheme="ISO8601" content="2010-08-0 1">402 <meta name="dct.issued" scheme="ISO8601" content="2010-08-02"> 403 403 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 404 404 <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 4 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 4 defines request header fields for indicating conditional requests and the rules for constructing responses to those requests."> … … 426 426 </tr> 427 427 <tr> 428 <td class="left">Expires: February 2, 2011</td>428 <td class="left">Expires: February 3, 2011</td> 429 429 <td class="right">J. Mogul</td> 430 430 </tr> … … 483 483 <tr> 484 484 <td class="left"></td> 485 <td class="right">August 1, 2010</td>485 <td class="right">August 2, 2010</td> 486 486 </tr> 487 487 </tbody> … … 509 509 in progress”. 510 510 </p> 511 <p>This Internet-Draft will expire on February 2, 2011.</p>511 <p>This Internet-Draft will expire on February 3, 2011.</p> 512 512 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 513 513 <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 896 896 <div id="rfc.iref.h.1"></div> 897 897 <h2 id="rfc.section.6.1"><a href="#rfc.section.6.1">6.1</a> <a id="header.etag" href="#header.etag">ETag</a></h2> 898 <p id="rfc.section.6.1.p.1">The "ETag" response-header field provides the current value of the entity-tag (see <a href="#entity.tags" title="Entity-Tags">Section 2</a>) for one representation of the resource identified by the effective request URI. An entity-tag is intended for use as a resource-local 899 identifier for differentiating between representations of the same resource that vary over time or via content negotiation 900 (see <a href="#weak.and.strong.validators" title="Weak and Strong Validators">Section 4</a>). 898 <p id="rfc.section.6.1.p.1">The "ETag" response-header field provides the current value of the entity-tag (see <a href="#entity.tags" title="Entity-Tags">Section 2</a>) for one representation of the target resource. An entity-tag is intended for use as a resource-local identifier for differentiating 899 between representations of the same resource that vary over time or via content negotiation (see <a href="#weak.and.strong.validators" title="Weak and Strong Validators">Section 4</a>). 901 900 </p> 902 901 <div id="rfc.figure.u.7"></div><pre class="inline"><span id="rfc.iref.g.4"></span><span id="rfc.iref.g.5"></span> <a href="#header.etag" class="smpl">ETag</a> = "ETag" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.etag" class="smpl">ETag-v</a> -
draft-ietf-httpbis/latest/p4-conditional.xml
r971 r972 734 734 The "ETag" response-header field provides the current value of the 735 735 entity-tag (see <xref target="entity.tags"/>) for one representation of 736 the resource identified by the effective request URI. An entity-tag736 the target resource. An entity-tag 737 737 is intended for use as a resource-local identifier for differentiating 738 738 between representations of the same resource that vary over time or via -
draft-ietf-httpbis/latest/p5-range.html
r971 r972 400 400 <meta name="dct.creator" content="Reschke, J. F."> 401 401 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p5-range-latest"> 402 <meta name="dct.issued" scheme="ISO8601" content="2010-08-0 1">402 <meta name="dct.issued" scheme="ISO8601" content="2010-08-02"> 403 403 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 404 404 <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 5 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 5 defines range-specific requests and the rules for constructing and combining responses to those requests."> … … 426 426 </tr> 427 427 <tr> 428 <td class="left">Expires: February 2, 2011</td>428 <td class="left">Expires: February 3, 2011</td> 429 429 <td class="right">J. Mogul</td> 430 430 </tr> … … 483 483 <tr> 484 484 <td class="left"></td> 485 <td class="right">August 1, 2010</td>485 <td class="right">August 2, 2010</td> 486 486 </tr> 487 487 </tbody> … … 509 509 in progress”. 510 510 </p> 511 <p>This Internet-Draft will expire on February 2, 2011.</p>511 <p>This Internet-Draft will expire on February 3, 2011.</p> 512 512 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 513 513 <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p> -
draft-ietf-httpbis/latest/p6-cache.html
r971 r972 402 402 <meta name="dct.creator" content="Reschke, J. F."> 403 403 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p6-cache-latest"> 404 <meta name="dct.issued" scheme="ISO8601" content="2010-08-0 1">404 <meta name="dct.issued" scheme="ISO8601" content="2010-08-02"> 405 405 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 406 406 <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. This document is Part 6 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 6 defines requirements on HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages."> … … 428 428 </tr> 429 429 <tr> 430 <td class="left">Expires: February 2, 2011</td>430 <td class="left">Expires: February 3, 2011</td> 431 431 <td class="right">J. Mogul</td> 432 432 </tr> … … 489 489 <tr> 490 490 <td class="left"></td> 491 <td class="right">August 1, 2010</td>491 <td class="right">August 2, 2010</td> 492 492 </tr> 493 493 </tbody> … … 515 515 in progress”. 516 516 </p> 517 <p>This Internet-Draft will expire on February 2, 2011.</p>517 <p>This Internet-Draft will expire on February 3, 2011.</p> 518 518 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 519 519 <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 938 938 <p id="rfc.section.2.5.p.1">Because unsafe methods (<a href="p2-semantics.html#safe.methods" title="Safe Methods">Section 7.1.1</a> of <a href="#Part2" id="rfc.xref.Part2.3"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) have the potential for changing state on the origin server, intervening caches can use them to keep their contents up-to-date. 939 939 </p> 940 <p id="rfc.section.2.5.p.2">The following HTTP methods <em class="bcp14">MUST</em> cause a cache to invalidate the Effective Request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.13"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) as well as the URI(s) in the Location and Content-Location headers (if present):940 <p id="rfc.section.2.5.p.2">The following HTTP methods <em class="bcp14">MUST</em> cause a cache to invalidate the effective Request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.13"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) as well as the URI(s) in the Location and Content-Location headers (if present): 941 941 </p> 942 942 <ul> -
draft-ietf-httpbis/latest/p6-cache.xml
r971 r972 854 854 </t> 855 855 <t> 856 The following HTTP methods &MUST; cause a cache to invalidate the Effective856 The following HTTP methods &MUST; cause a cache to invalidate the effective 857 857 Request URI (&effective-request-uri;) as well as the URI(s) in the Location 858 858 and Content-Location headers (if present): -
draft-ietf-httpbis/latest/p7-auth.html
r971 r972 393 393 <meta name="dct.creator" content="Reschke, J. F."> 394 394 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p7-auth-latest"> 395 <meta name="dct.issued" scheme="ISO8601" content="2010-08-0 1">395 <meta name="dct.issued" scheme="ISO8601" content="2010-08-02"> 396 396 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 397 397 <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 7 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 7 defines HTTP Authentication."> … … 424 424 </tr> 425 425 <tr> 426 <td class="left">Expires: February 2, 2011</td>426 <td class="left">Expires: February 3, 2011</td> 427 427 <td class="right">HP</td> 428 428 </tr> … … 477 477 <tr> 478 478 <td class="left"></td> 479 <td class="right">August 1, 2010</td>479 <td class="right">August 2, 2010</td> 480 480 </tr> 481 481 </tbody> … … 503 503 in progress”. 504 504 </p> 505 <p>This Internet-Draft will expire on February 2, 2011.</p>505 <p>This Internet-Draft will expire on February 3, 2011.</p> 506 506 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 507 507 <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
Note: See TracChangeset
for help on using the changeset viewer.