Changeset 2147 for draft-ietf-httpbis
- Timestamp:
- 21/01/13 07:43:33 (10 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 11 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p0-introduction.html
r2116 r2147 393 393 } 394 394 @bottom-center { 395 content: "Expires July 16, 2013";395 content: "Expires July 24, 2013"; 396 396 } 397 397 @bottom-right { … … 426 426 <meta name="dct.creator" content="Reschke, J. F."> 427 427 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p0-introduction-latest"> 428 <meta name="dct.issued" scheme="ISO8601" content="2013-01- 12">428 <meta name="dct.issued" scheme="ISO8601" content="2013-01-20"> 429 429 <meta name="dct.abstract" content="This document is the first in a series that, collectively, define the HyperText Transfer Protocol, version 1.1; otherwise known as HTTP/1.1."> 430 430 <meta name="description" content="This document is the first in a series that, collectively, define the HyperText Transfer Protocol, version 1.1; otherwise known as HTTP/1.1."> … … 446 446 </tr> 447 447 <tr> 448 <td class="left">Expires: July 16, 2013</td>448 <td class="left">Expires: July 24, 2013</td> 449 449 <td class="right">W3C</td> 450 450 </tr> … … 467 467 <tr> 468 468 <td class="left"></td> 469 <td class="right">January 12, 2013</td>469 <td class="right">January 20, 2013</td> 470 470 </tr> 471 471 </tbody> … … 490 490 in progress”. 491 491 </p> 492 <p>This Internet-Draft will expire on July 16, 2013.</p>492 <p>This Internet-Draft will expire on July 24, 2013.</p> 493 493 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 494 494 <p>Copyright © 2013 IETF Trust and the persons identified as the document authors. All rights reserved.</p> -
draft-ietf-httpbis/latest/p1-messaging.html
r2146 r2147 1372 1372 forming the message body. 1373 1373 </p> 1374 <p id="rfc.section.3.3.1.p.6">Unlike <a href="p2-semantics.html#header.content-encoding" class="smpl">Content-Encoding</a> (<a href="p2-semantics.html#content.codings" title="Content Codings">Section 3.1.2.1</a> of <a href="#Part2" id="rfc.xref.Part2.13"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>), Transfer-Encoding is a property of the message, not of the payload, and any recipient along the request/response chain <em class="bcp14">MAY</em> decode the received transfer coding(s) or apply additional transfer coding(s) to the message body, assuming that corresponding 1374 <p id="rfc.section.3.3.1.p.6">Unlike <a href="p2-semantics.html#header.content-encoding" class="smpl">Content-Encoding</a> (<a href="p2-semantics.html#content.codings" title="Content Codings">Section 3.1.2.1</a> of <a href="#Part2" id="rfc.xref.Part2.13"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>), Transfer-Encoding is a property of the message, not of the representation, and any recipient along the request/response 1375 chain <em class="bcp14">MAY</em> decode the received transfer coding(s) or apply additional transfer coding(s) to the message body, assuming that corresponding 1375 1376 changes are made to the Transfer-Encoding field-value. Additional information about the encoding parameters <em class="bcp14">MAY</em> be provided by other header fields not defined by this specification. 1376 1377 </p> … … 1414 1415 </p> 1415 1416 <p id="rfc.section.3.3.2.p.11">Any Content-Length field value greater than or equal to zero is valid. Since there is no predefined limit to the length of 1416 a n HTTPpayload, recipients <em class="bcp14">SHOULD</em> anticipate potentially large decimal numerals and prevent parsing errors due to integer conversion overflows (<a href="#attack.protocol.element.size.overflows" title="Buffer Overflows">Section 8.3</a>).1417 a payload, recipients <em class="bcp14">SHOULD</em> anticipate potentially large decimal numerals and prevent parsing errors due to integer conversion overflows (<a href="#attack.protocol.element.size.overflows" title="Buffer Overflows">Section 8.3</a>). 1417 1418 </p> 1418 1419 <p id="rfc.section.3.3.2.p.12">If a message is received that has multiple Content-Length header fields with field-values consisting of the same decimal value, -
draft-ietf-httpbis/latest/p1-messaging.xml
r2146 r2147 1535 1535 <t> 1536 1536 Unlike <x:ref>Content-Encoding</x:ref> (&content-codings;), 1537 Transfer-Encoding is a property of the message, not of the payload, and1537 Transfer-Encoding is a property of the message, not of the representation, and 1538 1538 any recipient along the request/response chain &MAY; decode the received 1539 1539 transfer coding(s) or apply additional transfer coding(s) to the message … … 1636 1636 <t> 1637 1637 Any Content-Length field value greater than or equal to zero is valid. 1638 Since there is no predefined limit to the length of a n HTTPpayload,1638 Since there is no predefined limit to the length of a payload, 1639 1639 recipients &SHOULD; anticipate potentially large decimal numerals and 1640 1640 prevent parsing errors due to integer conversion overflows -
draft-ietf-httpbis/latest/p2-semantics.html
r2132 r2147 449 449 } 450 450 @bottom-center { 451 content: "Expires July 2 3, 2013";451 content: "Expires July 24, 2013"; 452 452 } 453 453 @bottom-right { … … 494 494 <meta name="dct.creator" content="Reschke, J. F."> 495 495 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest"> 496 <meta name="dct.issued" scheme="ISO8601" content="2013-01- 19">496 <meta name="dct.issued" scheme="ISO8601" content="2013-01-20"> 497 497 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 498 498 <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages, as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation."> … … 522 522 <tr> 523 523 <td class="left">Intended status: Standards Track</td> 524 <td class="right">January 19, 2013</td>524 <td class="right">January 20, 2013</td> 525 525 </tr> 526 526 <tr> 527 <td class="left">Expires: July 2 3, 2013</td>527 <td class="left">Expires: July 24, 2013</td> 528 528 <td class="right"></td> 529 529 </tr> … … 553 553 in progress”. 554 554 </p> 555 <p>This Internet-Draft will expire on July 2 3, 2013.</p>555 <p>This Internet-Draft will expire on July 24, 2013.</p> 556 556 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 557 557 <p>Copyright © 2013 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 1011 1011 not be restated in Content-Encoding even if it happens to be the same algorithm as one of the content codings. Such a content 1012 1012 coding would only be listed if, for some bizarre reason, it is applied a second time to form the representation. Likewise, 1013 an origin server might choose to publish the same payload data as multiple representations that differ only in whether the1014 codingis defined as part of <a href="#header.content-type" class="smpl">Content-Type</a> or Content-Encoding, since some user agents will behave differently in their handling of each response (e.g., open a "Save1013 an origin server might choose to publish the same data as multiple representations that differ only in whether the coding 1014 is defined as part of <a href="#header.content-type" class="smpl">Content-Type</a> or Content-Encoding, since some user agents will behave differently in their handling of each response (e.g., open a "Save 1015 1015 as ..." dialog instead of automatic decompression and rendering of content). 1016 1016 </p> … … 1059 1059 or the recipient to determine, an identifier for a resource corresponding to that representation. 1060 1060 </p> 1061 <p id="rfc.section.3.1.4.1.p.2"> The following rules are used to determine such a URI for the payload ofa request message: </p>1061 <p id="rfc.section.3.1.4.1.p.2">For a request message: </p> 1062 1062 <ul> 1063 1063 <li>If the request has a <a href="#header.content-location" class="smpl">Content-Location</a> header field, then the sender asserts that the payload is a representation of the resource identified by the Content-Location … … 1067 1067 <li>Otherwise, the payload is unidentified.</li> 1068 1068 </ul> 1069 <p id="rfc.section.3.1.4.1.p.3">The following rules, to be applied in order until a match is found, are used to determine such a URI for the payload of a 1070 response message: 1071 </p> 1069 <p id="rfc.section.3.1.4.1.p.3">For a response message, the following rules are applied in order until a match is found: </p> 1072 1070 <ol> 1073 <li>If the request is GET or HEAD and the response status code is <a href="#status.200" class="smpl">200 (OK)</a>, <a href="#status.204" class="smpl">204 (No Content)</a>, <a href="p5-range.html#status.206" class="smpl">206 (Partial Content)</a>, or <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a>, the payload 's identifier isthe effective request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 5.5</a> of <a href="#Part1" id="rfc.xref.Part1.11"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>).1074 </li> 1075 <li>If the request is GET or HEAD and the response status code is <a href="#status.203" class="smpl">203 (Non-Authoritative Information)</a>, the payload is intended to be a representation of the <a href="#resources" class="smpl">target resource</a> that has been modified by an intermediary.1076 </li> 1077 <li>If the response has a <a href="#header.content-location" class="smpl">Content-Location</a> header field and its field-value is a reference to the same URI as the effective request URI, the payload 's identifier is1078 the effective request URI.1071 <li>If the request is GET or HEAD and the response status code is <a href="#status.200" class="smpl">200 (OK)</a>, <a href="#status.204" class="smpl">204 (No Content)</a>, <a href="p5-range.html#status.206" class="smpl">206 (Partial Content)</a>, or <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a>, the payload is a representation of the resource identified by the effective request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 5.5</a> of <a href="#Part1" id="rfc.xref.Part1.11"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>). 1072 </li> 1073 <li>If the request is GET or HEAD and the response status code is <a href="#status.203" class="smpl">203 (Non-Authoritative Information)</a>, the payload is a potentially modified or enhanced representation of the <a href="#resources" class="smpl">target resource</a> as provided by an intermediary. 1074 </li> 1075 <li>If the response has a <a href="#header.content-location" class="smpl">Content-Location</a> header field and its field-value is a reference to the same URI as the effective request URI, the payload is a representation 1076 of the resource identified by the effective request URI. 1079 1077 </li> 1080 1078 <li>If the response has a <a href="#header.content-location" class="smpl">Content-Location</a> header field and its field-value is a reference to a URI different from the effective request URI, then the sender asserts … … 1086 1084 <div id="rfc.iref.c.7"></div> 1087 1085 <h4 id="rfc.section.3.1.4.2"><a href="#rfc.section.3.1.4.2">3.1.4.2</a> <a id="header.content-location" href="#header.content-location">Content-Location</a></h4> 1088 <p id="rfc.section.3.1.4.2.p.1">The "Content-Location" header field references a URI that can be used as a specific identifier for the representation in this 1089 message payload. In other words, if one were to perform a GET on this URI at the time of this message's generation, then a <a href="#status.200" class="smpl">200 (OK)</a> response would contain the same representation that is enclosed as payload in this message. 1086 <p id="rfc.section.3.1.4.2.p.1">The "Content-Location" header field references a URI that can be used as an identifier for a specific resource corresponding 1087 to the representation in this message's payload. In other words, if one were to perform a GET request on this URI at the time 1088 of this message's generation, then a <a href="#status.200" class="smpl">200 (OK)</a> response would contain the same representation that is enclosed as payload in this message. 1090 1089 </p> 1091 1090 <div id="rfc.figure.u.15"></div><pre class="inline"><span id="rfc.iref.g.14"></span> <a href="#header.content-location" class="smpl">Content-Location</a> = <a href="#imported.abnf" class="smpl">absolute-URI</a> / <a href="#imported.abnf" class="smpl">partial-URI</a> … … 1101 1100 </p> 1102 1101 <p id="rfc.section.3.1.4.2.p.5">If Content-Location is included in a <a href="#status.2xx" class="smpl">2xx (Successful)</a> response message and its field-value refers to a URI that differs from the effective request URI, then the origin server claims 1103 that the field-value is an identifier for the representation enclosed as the payload. Such a claim can only be trusted if1104 b oth identifiers share the same resource owner, which cannot be programmatically determined via HTTP.1102 that the URI is an identifier for a different resource corresponding to the enclosed representation. Such a claim can only 1103 be trusted if both identifiers share the same resource owner, which cannot be programmatically determined via HTTP. 1105 1104 </p> 1106 1105 <ul> … … 1169 1168 <tr> 1170 1169 <td class="left">Content-Range</td> 1171 <td class="left"><a href="p5-range.html#header.content-range" title="Content-Range">Section 5.2</a> of <a href="#Part5" id="rfc.xref.Part5.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[Part5]</cite></a></td>1170 <td class="left"><a href="p5-range.html#header.content-range" title="Content-Range">Section 4.4</a> of <a href="#Part5" id="rfc.xref.Part5.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[Part5]</cite></a></td> 1172 1171 </tr> 1173 1172 <tr> … … 1390 1389 to be refreshed without requiring multiple requests or transferring data already held by the client. 1391 1390 </p> 1392 <p id="rfc.section.4.3.1.p.4">The semantics of the GET method change to a "partial GET" if the request message includes a <a href="p5-range.html# range.retrieval.requests" class="smpl">Range</a> header field (<a href="#Part5" id="rfc.xref.Part5.3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[Part5]</cite></a>). A partial GET requests that only part of the representation be transferred, as described in <a href="p5-range.html#header.range" title="Range">Section 5.4</a> of <a href="#Part5" id="rfc.xref.Part5.4"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[Part5]</cite></a>. The partial GET request is intended to reduce unnecessary network usage by allowing partially-retrieved representations1391 <p id="rfc.section.4.3.1.p.4">The semantics of the GET method change to a "partial GET" if the request message includes a <a href="p5-range.html#header.range" class="smpl">Range</a> header field (<a href="#Part5" id="rfc.xref.Part5.3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[Part5]</cite></a>). A partial GET requests that only part of the representation be transferred, as described in <a href="p5-range.html#header.range" title="Range">Section 3.1</a> of <a href="#Part5" id="rfc.xref.Part5.4"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[Part5]</cite></a>. The partial GET request is intended to reduce unnecessary network usage by allowing partially-retrieved representations 1393 1392 to be completed without transferring data already held by the client. 1394 1393 </p> … … 1496 1495 the related resources. 1497 1496 </p> 1498 <p id="rfc.section.4.3.4.p.11">An origin server <em class="bcp14">SHOULD</em> reject any PUT request that contains a <a href="p5-range.html#header.content-range" class="smpl">Content-Range</a> header field (<a href="p5-range.html#header.content-range" title="Content-Range">Section 5.2</a> of <a href="#Part5" id="rfc.xref.Part5.5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[Part5]</cite></a>), since it might be misinterpreted as partial content (or might be partial content that is being mistakenly PUT as a full1497 <p id="rfc.section.4.3.4.p.11">An origin server <em class="bcp14">SHOULD</em> reject any PUT request that contains a <a href="p5-range.html#header.content-range" class="smpl">Content-Range</a> header field (<a href="p5-range.html#header.content-range" title="Content-Range">Section 4.4</a> of <a href="#Part5" id="rfc.xref.Part5.5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[Part5]</cite></a>), since it might be misinterpreted as partial content (or might be partial content that is being mistakenly PUT as a full 1499 1498 representation). Partial content updates are possible by targeting a separately identified resource with state that overlaps 1500 1499 a portion of the larger resource, or by using a different method that has been specifically defined for partial updates (for … … 1648 1647 <tr> 1649 1648 <td class="left">Range</td> 1650 <td class="left"><a href="p5-range.html#header.range" title="Range">Section 5.4</a> of <a href="#Part5" id="rfc.xref.Part5.6"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[Part5]</cite></a></td>1649 <td class="left"><a href="p5-range.html#header.range" title="Range">Section 3.1</a> of <a href="#Part5" id="rfc.xref.Part5.6"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[Part5]</cite></a></td> 1651 1650 </tr> 1652 1651 <tr> … … 1775 1774 <tr> 1776 1775 <td class="left">If-Range</td> 1777 <td class="left"><a href="p5-range.html#header.if-range" title="If-Range">Section 5.3</a> of <a href="#Part5" id="rfc.xref.Part5.7"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[Part5]</cite></a></td>1776 <td class="left"><a href="p5-range.html#header.if-range" title="If-Range">Section 3.2</a> of <a href="#Part5" id="rfc.xref.Part5.7"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[Part5]</cite></a></td> 1778 1777 </tr> 1779 1778 </tbody> … … 2167 2166 </ul> 2168 2167 <h2 id="rfc.section.6.1"><a href="#rfc.section.6.1">6.1</a> <a id="overview.of.status.codes" href="#overview.of.status.codes">Overview of Status Codes</a></h2> 2169 <p id="rfc.section.6.1.p.1">The status codes listed below are defined in this specification, <a href="p4-conditional.html#status.code.definitions" title="Status Code Definitions">Section 4</a> of <a href="#Part4" id="rfc.xref.Part4.8"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a>, <a href="p5-range.html# status.code.definitions" title="Status Code Definitions">Section 3</a> of <a href="#Part5" id="rfc.xref.Part5.8"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[Part5]</cite></a>, and <a href="p7-auth.html#status.code.definitions" title="Status Code Definitions">Section 3</a> of <a href="#Part7" id="rfc.xref.Part7.5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Authentication">[Part7]</cite></a>. The reason phrases listed here are only recommendations — they can be replaced by local equivalents without affecting the2168 <p id="rfc.section.6.1.p.1">The status codes listed below are defined in this specification, <a href="p4-conditional.html#status.code.definitions" title="Status Code Definitions">Section 4</a> of <a href="#Part4" id="rfc.xref.Part4.8"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a>, <a href="p5-range.html#range.response" title="Responses to a Range Request">Section 4</a> of <a href="#Part5" id="rfc.xref.Part5.8"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[Part5]</cite></a>, and <a href="p7-auth.html#status.code.definitions" title="Status Code Definitions">Section 3</a> of <a href="#Part7" id="rfc.xref.Part7.5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Authentication">[Part7]</cite></a>. The reason phrases listed here are only recommendations — they can be replaced by local equivalents without affecting the 2170 2169 protocol. 2171 2170 </p> … … 2223 2222 <td class="left">206</td> 2224 2223 <td class="left">Partial Content</td> 2225 <td id="status.206" class="left"><a href="p5-range.html#status.206" title="206 Partial Content">Section 3.1</a> of <a href="#Part5" id="rfc.xref.Part5.9"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[Part5]</cite></a></td>2224 <td id="status.206" class="left"><a href="p5-range.html#status.206" title="206 Partial Content">Section 4.2</a> of <a href="#Part5" id="rfc.xref.Part5.9"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[Part5]</cite></a></td> 2226 2225 </tr> 2227 2226 <tr> … … 2343 2342 <td class="left">416</td> 2344 2343 <td class="left">Range Not Satisfiable</td> 2345 <td id="status.416" class="left"><a href="p5-range.html#status.416" title="416 Range Not Satisfiable">Section 3.2</a> of <a href="#Part5" id="rfc.xref.Part5.10"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[Part5]</cite></a></td>2344 <td id="status.416" class="left"><a href="p5-range.html#status.416" title="416 Range Not Satisfiable">Section 4.3</a> of <a href="#Part5" id="rfc.xref.Part5.10"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[Part5]</cite></a></td> 2346 2345 </tr> 2347 2346 <tr> … … 3118 3117 <tr> 3119 3118 <td class="left">Accept-Ranges</td> 3120 <td class="left"><a href="p5-range.html#header.accept-ranges" title="Accept-Ranges">Section 5.1</a> of <a href="#Part5" id="rfc.xref.Part5.11"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[Part5]</cite></a></td>3119 <td class="left"><a href="p5-range.html#header.accept-ranges" title="Accept-Ranges">Section 2.3</a> of <a href="#Part5" id="rfc.xref.Part5.11"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[Part5]</cite></a></td> 3121 3120 </tr> 3122 3121 <tr> … … 3545 3544 </p> 3546 3545 <p id="rfc.section.8.3.1.p.4">Because commas (",") are used as a generic delimiter between field-values, they need to be treated with care if they are allowed 3547 in the field-value 's payload. Typically, components that might contain a comma are protected with double-quotes using the3548 quoted-stringABNF production (<a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.6</a> of <a href="#Part1" id="rfc.xref.Part1.33"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>).3546 in the field-value. Typically, components that might contain a comma are protected with double-quotes using the quoted-string 3547 ABNF production (<a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.6</a> of <a href="#Part1" id="rfc.xref.Part1.33"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>). 3549 3548 </p> 3550 3549 <p id="rfc.section.8.3.1.p.5">For example, a textual date and a URI (either of which might contain a comma) could be safely carried in field-values like … … 4646 4645 </li> 4647 4646 <li><em>Part5</em> <a href="#rfc.xref.Part5.1">3.1.1.4</a>, <a href="#rfc.xref.Part5.2">3.3</a>, <a href="#rfc.xref.Part5.3">4.3.1</a>, <a href="#rfc.xref.Part5.4">4.3.1</a>, <a href="#rfc.xref.Part5.5">4.3.4</a>, <a href="#rfc.xref.Part5.6">5.1</a>, <a href="#rfc.xref.Part5.7">5.2</a>, <a href="#rfc.xref.Part5.8">6.1</a>, <a href="#rfc.xref.Part5.9">6.1</a>, <a href="#rfc.xref.Part5.10">6.1</a>, <a href="#rfc.xref.Part5.11">7.4</a>, <a href="#rfc.xref.Part5.12">8.1.2</a>, <a href="#Part5"><b>11.1</b></a>, <a href="#rfc.xref.Part5.13">A.6</a><ul> 4648 <li><em>Section 3</em> <a href="#rfc.xref.Part5.8">6.1</a></li>4649 <li><em>Section 3.1</em> <a href="#rfc.xref.Part5. 9">6.1</a></li>4650 <li><em>Section 3.2</em> <a href="#rfc.xref.Part5. 10">6.1</a></li>4651 <li><em>Section 5.1</em> <a href="#rfc.xref.Part5.11">7.4</a></li>4652 <li><em>Section 5.2</em> <a href="#rfc.xref.Part5.2">3.3</a>, <a href="#rfc.xref.Part5.5">4.3.4</a></li>4653 <li><em>Section 5.3</em> <a href="#rfc.xref.Part5.7">5.2</a></li>4654 <li><em>Section 5.4</em> <a href="#rfc.xref.Part5.4">4.3.1</a>, <a href="#rfc.xref.Part5.6">5.1</a></li>4647 <li><em>Section 2.3</em> <a href="#rfc.xref.Part5.11">7.4</a></li> 4648 <li><em>Section 3.1</em> <a href="#rfc.xref.Part5.4">4.3.1</a>, <a href="#rfc.xref.Part5.6">5.1</a></li> 4649 <li><em>Section 3.2</em> <a href="#rfc.xref.Part5.7">5.2</a></li> 4650 <li><em>Section 4</em> <a href="#rfc.xref.Part5.8">6.1</a></li> 4651 <li><em>Section 4.2</em> <a href="#rfc.xref.Part5.9">6.1</a></li> 4652 <li><em>Section 4.3</em> <a href="#rfc.xref.Part5.10">6.1</a></li> 4653 <li><em>Section 4.4</em> <a href="#rfc.xref.Part5.2">3.3</a>, <a href="#rfc.xref.Part5.5">4.3.4</a></li> 4655 4654 <li><em>Appendix A</em> <a href="#rfc.xref.Part5.13">A.6</a></li> 4656 4655 </ul> -
draft-ietf-httpbis/latest/p2-semantics.xml
r2132 r2147 83 83 <!ENTITY status-416 "<xref target='Part5' x:rel='#status.416' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 84 84 <!ENTITY p4-status-codes "<xref target='Part4' x:rel='#status.code.definitions' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 85 <!ENTITY p5-status-codes "<xref target='Part5' x:rel='# status.code.definitions' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">85 <!ENTITY p5-status-codes "<xref target='Part5' x:rel='#range.response' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 86 86 <!ENTITY p7-status-codes "<xref target='Part7' x:rel='#status.code.definitions' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 87 87 <!ENTITY p6-heuristic "<xref target='Part6' x:rel='#heuristic.freshness' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> … … 598 598 for some bizarre reason, it is applied a second time to form the 599 599 representation. Likewise, an origin server might choose to publish the 600 same payloaddata as multiple representations that differ only in whether600 same data as multiple representations that differ only in whether 601 601 the coding is defined as part of <x:ref>Content-Type</x:ref> or 602 602 Content-Encoding, since some user agents will behave differently in their … … 701 701 </t> 702 702 <t> 703 The following rules are used to determine such a URI for the payload of a 704 request message: 703 For a request message: 705 704 <list style="symbols"> 706 705 <t>If the request has a <x:ref>Content-Location</x:ref> header field, … … 714 713 </t> 715 714 <t> 716 The following rules, to be applied in order until a match is found, are717 used to determine such a URI for the payload of a response message:715 For a response message, the following rules are applied in order until a 716 match is found: 718 717 <list style="numbers"> 719 718 <t>If the request is GET or HEAD and the response status code is … … 722 721 <x:ref>206 (Partial Content)</x:ref>, or 723 722 <x:ref>304 (Not Modified)</x:ref>, 724 the payload 's identifier is the effective request URI725 (&effective-request-uri;).</t>723 the payload is a representation of the resource identified by the 724 effective request URI (&effective-request-uri;).</t> 726 725 <t>If the request is GET or HEAD and the response status code is 727 726 <x:ref>203 (Non-Authoritative Information)</x:ref>, the payload is 728 intended to be a representation of the <x:ref>target resource</x:ref>729 that has been modified by an intermediary.</t>727 a potentially modified or enhanced representation of the 728 <x:ref>target resource</x:ref> as provided by an intermediary.</t> 730 729 <t>If the response has a <x:ref>Content-Location</x:ref> header field 731 730 and its field-value is a reference to the same URI as the effective 732 request URI, the payload's identifier is the effective request URI.</t> 731 request URI, the payload is a representation of the resource 732 identified by the effective request URI.</t> 733 733 <t>If the response has a <x:ref>Content-Location</x:ref> header field 734 734 and its field-value is a reference to a URI different from the … … 747 747 <t> 748 748 The "Content-Location" header field references a URI that can be used 749 as a specific identifier for the representation in this message payload. 750 In other words, if one were to perform a GET on this URI at the time 749 as an identifier for a specific resource corresponding to the 750 representation in this message's payload. 751 In other words, if one were to perform a GET request on this URI at the time 751 752 of this message's generation, then a <x:ref>200 (OK)</x:ref> response would 752 753 contain the same representation that is enclosed as payload in this message. … … 780 781 If Content-Location is included in a <x:ref>2xx (Successful)</x:ref> 781 782 response message and its field-value refers to a URI that differs from the 782 effective request URI, then the origin server claims that the field-value 783 is an identifier for the representation enclosed as the payload. Such a 784 claim can only be trusted if both identifiers share the same resource 785 owner, which cannot be programmatically determined via HTTP. 783 effective request URI, then the origin server claims that the URI 784 is an identifier for a different resource corresponding to the enclosed 785 representation. Such a claim can only be trusted if both identifiers share 786 the same resource owner, which cannot be programmatically determined via 787 HTTP. 786 788 <list style="symbols"> 787 789 <t>For a response to a GET or HEAD request, this is an indication that the … … 4520 4522 <t> 4521 4523 Because commas (",") are used as a generic delimiter between field-values, 4522 they need to be treated with care if they are allowed in the field-value 's4523 payload.Typically, components that might contain a comma are protected with4524 double-quotes using the quoted-string ABNF production (&field-components;). 4524 they need to be treated with care if they are allowed in the field-value. 4525 Typically, components that might contain a comma are protected with 4526 double-quotes using the quoted-string ABNF production (&field-components;). 4525 4527 </t> 4526 4528 <t> -
draft-ietf-httpbis/latest/p4-conditional.html
r2137 r2147 672 672 is changed (e.g., <a href="p2-semantics.html#header.content-type" class="smpl">Content-Type</a>), but it is in the best interests of the origin server to only change the value when it is necessary to invalidate the stored 673 673 responses held by remote caches and authoring tools. A strong validator is unique across all representations of a given resource, 674 such that no two representations of that resource share the same validator unless their payload body would beidentical.674 such that no two representations of that resource can share the same validator unless their representation data is identical. 675 675 </p> 676 676 <p id="rfc.section.2.1.p.4">Cache entries might persist for arbitrarily long periods, regardless of expiration times. Thus, a cache might attempt to validate … … 707 707 </p> 708 708 <p id="rfc.section.2.1.p.9">A "use" of a validator occurs when either a client generates a request and includes the validator in a precondition or when 709 a server compares two validators. Weak validators are only usable in contexts that do not depend on exact equality of a representation's710 payload body. Strong validators are usable and preferred for all conditional requests, including cache validation, partial711 content ranges, and "lost update" avoidance.709 a server compares two validators. Weak validators are only usable in contexts that do not depend on exact equality of the 710 representation data. Strong validators are usable and preferred for all conditional requests, including cache validation, 711 partial content ranges, and "lost update" avoidance. 712 712 </p> 713 713 <div id="rfc.iref.l.1"></div> … … 999 999 </pre><p id="rfc.section.3.3.p.3">An example of the field is:</p> 1000 1000 <div id="rfc.figure.u.13"></div><pre class="text"> If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT 1001 </pre><p id="rfc.section.3.3.p.5">A GET method with an If-Modified-Since header field and no <a href="p5-range.html# range.retrieval.requests" class="smpl">Range</a> header field requests that the selected representation be transferred only if it has been modified since the date given by1001 </pre><p id="rfc.section.3.3.p.5">A GET method with an If-Modified-Since header field and no <a href="p5-range.html#header.range" class="smpl">Range</a> header field requests that the selected representation be transferred only if it has been modified since the date given by 1002 1002 the If-Modified-Since header field. The algorithm for determining this includes the following cases: 1003 1003 </p> … … 1041 1041 </p> 1042 1042 <h2 id="rfc.section.3.5"><a href="#rfc.section.3.5">3.5</a> <a id="header.if-range" href="#header.if-range">If-Range</a></h2> 1043 <p id="rfc.section.3.5.p.1">The "If-Range" header field provides a special conditional request mechanism that is similar to <a href="#header.if-match" class="smpl">If-Match</a> and <a href="#header.if-unmodified-since" class="smpl">If-Unmodified-Since</a> but specific to range requests. If-Range is defined in <a href="p5-range.html#header.if-range" title="If-Range">Section 5.3</a> of <a href="#Part5" id="rfc.xref.Part5.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[Part5]</cite></a>.1043 <p id="rfc.section.3.5.p.1">The "If-Range" header field provides a special conditional request mechanism that is similar to <a href="#header.if-match" class="smpl">If-Match</a> and <a href="#header.if-unmodified-since" class="smpl">If-Unmodified-Since</a> but specific to range requests. If-Range is defined in <a href="p5-range.html#header.if-range" title="If-Range">Section 3.2</a> of <a href="#Part5" id="rfc.xref.Part5.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[Part5]</cite></a>. 1044 1044 </p> 1045 1045 <h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a> <a id="status.code.definitions" href="#status.code.definitions">Status Code Definitions</a></h1> … … 1107 1107 </ul> 1108 1108 </li> 1109 <li>When the method is GET and both <a href="p5-range.html# range.retrieval.requests" class="smpl">Range</a> and <a href="p5-range.html#header.if-range" class="smpl">If-Range</a> are present, evaluate If-Range:1109 <li>When the method is GET and both <a href="p5-range.html#header.range" class="smpl">Range</a> and <a href="p5-range.html#header.if-range" class="smpl">If-Range</a> are present, evaluate If-Range: 1110 1110 <ul> 1111 1111 <li>if the validator matches and the Range specification is applicable to the selected representation, respond <a href="p5-range.html#status.206" class="smpl">206 (Partial Content)</a> <a href="#Part5" id="rfc.xref.Part5.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[Part5]</cite></a></li> … … 1451 1451 </li> 1452 1452 <li><em>Part5</em> <a href="#rfc.xref.Part5.1">3.5</a>, <a href="#rfc.xref.Part5.2">5</a>, <a href="#Part5"><b>9.1</b></a><ul> 1453 <li><em>Section 5.3</em> <a href="#rfc.xref.Part5.1">3.5</a></li>1453 <li><em>Section 3.2</em> <a href="#rfc.xref.Part5.1">3.5</a></li> 1454 1454 </ul> 1455 1455 </li> -
draft-ietf-httpbis/latest/p4-conditional.xml
r2137 r2147 220 220 the stored responses held by remote caches and authoring tools. A strong 221 221 validator is unique across all representations of a given resource, such 222 that no two representations of that resource share the same validator223 unless their payload body would beidentical.222 that no two representations of that resource can share the same validator 223 unless their representation data is identical. 224 224 </t> 225 225 <t> … … 289 289 compares two validators. 290 290 Weak validators are only usable in contexts that do not depend on exact 291 equality of a representation's payload body.291 equality of the representation data. 292 292 Strong validators are usable and preferred for all conditional requests, 293 293 including cache validation, partial content ranges, and "lost update" -
draft-ietf-httpbis/latest/p5-range.html
r2145 r2147 713 713 is satisfiable. Otherwise, the byte-range-set is unsatisfiable. If the byte-range-set is unsatisfiable, the server <em class="bcp14">SHOULD</em> send a response with a <a href="#status.416" class="smpl">416 (Range Not Satisfiable)</a> status code. Otherwise, the server <em class="bcp14">SHOULD</em> send a response with a <a href="#status.206" class="smpl">206 (Partial Content)</a> status code containing the satisfiable ranges of the representation. 714 714 </p> 715 <p id="rfc.section.2.1.p.13">In the byte range syntax, <a href="#rule.ranges-specifier" class="smpl">first-byte-pos</a>, <a href="#rule.ranges-specifier" class="smpl">last-byte-pos</a>, and <a href="#rule.ranges-specifier" class="smpl">suffix-length</a> are expressed as decimal number of octets. Since there is no predefined limit to the length of a n HTTPpayload, recipients <em class="bcp14">SHOULD</em> anticipate potentially large decimal numerals and prevent parsing errors due to integer conversion overflows.715 <p id="rfc.section.2.1.p.13">In the byte range syntax, <a href="#rule.ranges-specifier" class="smpl">first-byte-pos</a>, <a href="#rule.ranges-specifier" class="smpl">last-byte-pos</a>, and <a href="#rule.ranges-specifier" class="smpl">suffix-length</a> are expressed as decimal number of octets. Since there is no predefined limit to the length of a payload, recipients <em class="bcp14">SHOULD</em> anticipate potentially large decimal numerals and prevent parsing errors due to integer conversion overflows. 716 716 </p> 717 717 <h2 id="rfc.section.2.2"><a href="#rfc.section.2.2">2.2</a> <a id="range.units.other" href="#range.units.other">Other Range Units</a></h2> … … 834 834 <div id="rfc.iref.c.1"></div> 835 835 <h2 id="rfc.section.4.4"><a href="#rfc.section.4.4">4.4</a> <a id="header.content-range" href="#header.content-range">Content-Range</a></h2> 836 <p id="rfc.section.4.4.p.1">The "Content-Range" header field is sent with a partial representation to specify wh ere in the full representation the payload837 body is intended to be applied.836 <p id="rfc.section.4.4.p.1">The "Content-Range" header field is sent with a partial representation to specify what range of the full representation is 837 enclosed as payload. 838 838 </p> 839 839 <div id="rfc.figure.u.19"></div><pre class="inline"><span id="rfc.iref.g.18"></span><span id="rfc.iref.g.19"></span><span id="rfc.iref.g.20"></span><span id="rfc.iref.g.21"></span><span id="rfc.iref.g.22"></span><span id="rfc.iref.g.23"></span><span id="rfc.iref.g.24"></span><span id="rfc.iref.g.25"></span> <a href="#header.content-range" class="smpl">Content-Range</a> = <a href="#header.content-range" class="smpl">byte-content-range</a> -
draft-ietf-httpbis/latest/p5-range.xml
r2145 r2147 316 316 <x:ref>last-byte-pos</x:ref>, and <x:ref>suffix-length</x:ref> are 317 317 expressed as decimal number of octets. Since there is no predefined limit 318 to the length of a n HTTPpayload, recipients &SHOULD; anticipate318 to the length of a payload, recipients &SHOULD; anticipate 319 319 potentially large decimal numerals and prevent parsing errors due to integer 320 320 conversion overflows. … … 624 624 <t> 625 625 The "Content-Range" header field is sent with a partial representation to 626 specify where in the full representation the payload body is intended to be 627 applied. 626 specify what range of the full representation is enclosed as payload. 628 627 </t> 629 628 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Content-Range"/><iref primary="true" item="Grammar" subitem="byte-content-range"/><iref primary="true" item="Grammar" subitem="byte-range-resp"/><iref primary="true" item="Grammar" subitem="byte-range"/><iref primary="true" item="Grammar" subitem="unsatisfied-range"/><iref primary="true" item="Grammar" subitem="other-content-range"/><iref primary="true" item="Grammar" subitem="other-range-resp"/><iref primary="true" item="Grammar" subitem="complete-length"/> -
draft-ietf-httpbis/latest/p6-cache.html
r2116 r2147 452 452 } 453 453 @bottom-center { 454 content: "Expires July 16, 2013";454 content: "Expires July 24, 2013"; 455 455 } 456 456 @bottom-right { … … 498 498 <meta name="dct.creator" content="Reschke, J. F."> 499 499 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p6-cache-latest"> 500 <meta name="dct.issued" scheme="ISO8601" content="2013-01- 12">500 <meta name="dct.issued" scheme="ISO8601" content="2013-01-20"> 501 501 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 502 502 <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines requirements on HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages."> … … 524 524 </tr> 525 525 <tr> 526 <td class="left">Expires: July 16, 2013</td>526 <td class="left">Expires: July 24, 2013</td> 527 527 <td class="right">J. Reschke, Editor</td> 528 528 </tr> … … 533 533 <tr> 534 534 <td class="left"></td> 535 <td class="right">January 12, 2013</td>535 <td class="right">January 20, 2013</td> 536 536 </tr> 537 537 </tbody> … … 559 559 in progress”. 560 560 </p> 561 <p>This Internet-Draft will expire on July 16, 2013.</p>561 <p>This Internet-Draft will expire on July 24, 2013.</p> 562 562 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 563 563 <p>Copyright © 2013 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 841 841 <p id="rfc.section.3.1.p.1">A response message is considered complete when all of the octets indicated by the message framing (<a href="#Part1" id="rfc.xref.Part1.3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>) are received prior to the connection being closed. If the request is GET, the response status is <a href="p2-semantics.html#status.200" class="smpl">200 842 842 (OK)</a>, and the entire response header block has been received, a cache <em class="bcp14">MAY</em> store an incomplete response message body if the cache entry is recorded as incomplete. Likewise, a <a href="p5-range.html#status.206" class="smpl">206 (Partial Content)</a> response <em class="bcp14">MAY</em> be stored as if it were an incomplete <a href="p2-semantics.html#status.200" class="smpl">200 843 (OK)</a> cache entry. However, a cache <em class="bcp14">MUST NOT</em> store incomplete or partial content responses if it does not support the <a href="p5-range.html# range.retrieval.requests" class="smpl">Range</a> and <a href="p5-range.html#header.content-range" class="smpl">Content-Range</a> header fields or if it does not understand the range units used in those fields.843 (OK)</a> cache entry. However, a cache <em class="bcp14">MUST NOT</em> store incomplete or partial content responses if it does not support the <a href="p5-range.html#header.range" class="smpl">Range</a> and <a href="p5-range.html#header.content-range" class="smpl">Content-Range</a> header fields or if it does not understand the range units used in those fields. 844 844 </p> 845 845 <p id="rfc.section.3.1.p.2">A cache <em class="bcp14">MAY</em> complete a stored incomplete response by making a subsequent range request (<a href="#Part5" id="rfc.xref.Part5.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[Part5]</cite></a>) and combining the successful response with the stored entry, as defined in <a href="#combining.responses" title="Combining Partial Content">Section 4.4</a>. A cache <em class="bcp14">MUST NOT</em> use an incomplete response to answer requests unless the response has been made complete or the request is partial and specifies … … 1120 1120 <p id="rfc.section.4.4.p.1">A response might transfer only a partial representation if the connection closed prematurely or if the request used one or 1121 1121 more Range specifiers (<a href="#Part5" id="rfc.xref.Part5.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[Part5]</cite></a>). After several such transfers, a cache might have received several ranges of the same representation. A cache <em class="bcp14">MAY</em> combine these ranges into a single stored response, and reuse that response to satisfy later requests, if they all share the 1122 same strong validator and the cache complies with the client requirements in <a href="p5-range.html#combining.byte.ranges" title="Combining Ranges">Section 4. 2</a> of <a href="#Part5" id="rfc.xref.Part5.3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[Part5]</cite></a>.1122 same strong validator and the cache complies with the client requirements in <a href="p5-range.html#combining.byte.ranges" title="Combining Ranges">Section 4.5</a> of <a href="#Part5" id="rfc.xref.Part5.3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[Part5]</cite></a>. 1123 1123 </p> 1124 1124 <p id="rfc.section.4.4.p.2">When combining the new response with one or more stored responses, a cache <em class="bcp14">MUST</em>: … … 2156 2156 </li> 2157 2157 <li><em>Part5</em> <a href="#rfc.xref.Part5.1">3.1</a>, <a href="#rfc.xref.Part5.2">4.4</a>, <a href="#rfc.xref.Part5.3">4.4</a>, <a href="#Part5"><b>12.1</b></a><ul> 2158 <li><em>Section 4. 2</em> <a href="#rfc.xref.Part5.3">4.4</a></li>2158 <li><em>Section 4.5</em> <a href="#rfc.xref.Part5.3">4.4</a></li> 2159 2159 </ul> 2160 2160 </li> -
draft-ietf-httpbis/latest/p7-auth.html
r2116 r2147 449 449 } 450 450 @bottom-center { 451 content: "Expires July 16, 2013";451 content: "Expires July 24, 2013"; 452 452 } 453 453 @bottom-right { … … 489 489 <meta name="dct.creator" content="Reschke, J. F."> 490 490 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p7-auth-latest"> 491 <meta name="dct.issued" scheme="ISO8601" content="2013-01- 12">491 <meta name="dct.issued" scheme="ISO8601" content="2013-01-20"> 492 492 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 493 493 <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. This document defines the HTTP Authentication framework."> … … 517 517 <tr> 518 518 <td class="left">Intended status: Standards Track</td> 519 <td class="right">January 12, 2013</td>519 <td class="right">January 20, 2013</td> 520 520 </tr> 521 521 <tr> 522 <td class="left">Expires: July 16, 2013</td>522 <td class="left">Expires: July 24, 2013</td> 523 523 <td class="right"></td> 524 524 </tr> … … 546 546 in progress”. 547 547 </p> 548 <p>This Internet-Draft will expire on July 16, 2013.</p>548 <p>This Internet-Draft will expire on July 24, 2013.</p> 549 549 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 550 550 <p>Copyright © 2013 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
Note: See TracChangeset
for help on using the changeset viewer.