Changeset 1604
- Timestamp:
- 21/03/12 12:30:28 (10 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 10 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r1602 r1604 460 460 } 461 461 @bottom-center { 462 content: "Expires September 19, 2012";462 content: "Expires September 22, 2012"; 463 463 } 464 464 @bottom-right { … … 502 502 <meta name="dct.creator" content="Reschke, J. F."> 503 503 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p1-messaging-latest"> 504 <meta name="dct.issued" scheme="ISO8601" content="2012-03- 18">504 <meta name="dct.issued" scheme="ISO8601" content="2012-03-21"> 505 505 <meta name="dct.replaces" content="urn:ietf:rfc:2145"> 506 506 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> … … 534 534 </tr> 535 535 <tr> 536 <td class="left">Expires: September 19, 2012</td>536 <td class="left">Expires: September 22, 2012</td> 537 537 <td class="right">greenbytes</td> 538 538 </tr> 539 539 <tr> 540 540 <td class="left"></td> 541 <td class="right">March 18, 2012</td>541 <td class="right">March 21, 2012</td> 542 542 </tr> 543 543 </tbody> … … 572 572 in progress”. 573 573 </p> 574 <p>This Internet-Draft will expire on September 19, 2012.</p>574 <p>This Internet-Draft will expire on September 22, 2012.</p> 575 575 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 576 576 <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 1538 1538 received, provided that the header block was received intact. 1539 1539 </p> 1540 <p id="rfc.section.3.4.p.4">A user agent <em class="bcp14">MUST NOT</em> render an incomplete response message body as if it were complete (i.e., some indication must be given to the user that an1541 error occurred). Cache requirements for incomplete responses are defined in <a href="p6-cache.html#response.cacheability" title="Response Cacheability">Section 2.1</a> of <a href="#Part6" id="rfc.xref.Part6.4"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>.1540 <p id="rfc.section.3.4.p.4">A user agent <em class="bcp14">MUST NOT</em> render an incomplete response message body as if it were complete (i.e., some indication needs to be given to the user that 1541 an error occurred). Cache requirements for incomplete responses are defined in <a href="p6-cache.html#response.cacheability" title="Response Cacheability">Section 2.1</a> of <a href="#Part6" id="rfc.xref.Part6.4"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>. 1542 1542 </p> 1543 1543 <p id="rfc.section.3.4.p.5">A server <em class="bcp14">MUST</em> read the entire request message body or close the connection after sending its response, since otherwise the remaining data … … 3016 3016 </p> 3017 3017 <p id="rfc.section.A.2.p.13">Change ABNF productions for header fields to only define the field value.</p> 3018 <p id="rfc.section.A.2.p.14">Clarify exactly when close connection options mustbe sent. (<a href="#header.connection" id="rfc.xref.header.connection.11" title="Connection">Section 6.1</a>)3018 <p id="rfc.section.A.2.p.14">Clarify exactly when close connection options have to be sent. (<a href="#header.connection" id="rfc.xref.header.connection.11" title="Connection">Section 6.1</a>) 3019 3019 </p> 3020 3020 <p id="rfc.section.A.2.p.15">Define the semantics of the "Upgrade" header field in responses other than 101 (this was incorporated from <a href="#RFC2817" id="rfc.xref.RFC2817.3"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>). (<a href="#header.upgrade" id="rfc.xref.header.upgrade.2" title="Upgrade">Section 6.5</a>) -
draft-ietf-httpbis/latest/p1-messaging.xml
r1602 r1604 1780 1780 <t> 1781 1781 A user agent &MUST-NOT; render an incomplete response message body as if 1782 it were complete (i.e., some indication mustbe given to the user that an1782 it were complete (i.e., some indication needs to be given to the user that an 1783 1783 error occurred). Cache requirements for incomplete responses are defined 1784 1784 in &cache-incomplete;. … … 4894 4894 </t> 4895 4895 <t> 4896 Clarify exactly when close connection options mustbe sent.4896 Clarify exactly when close connection options have to be sent. 4897 4897 (<xref target="header.connection"/>) 4898 4898 </t> -
draft-ietf-httpbis/latest/p2-semantics.html
r1590 r1604 460 460 } 461 461 @bottom-center { 462 content: "Expires September 13, 2012";462 content: "Expires September 22, 2012"; 463 463 } 464 464 @bottom-right { … … 507 507 <meta name="dct.creator" content="Reschke, J. F."> 508 508 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest"> 509 <meta name="dct.issued" scheme="ISO8601" content="2012-03- 12">509 <meta name="dct.issued" scheme="ISO8601" content="2012-03-21"> 510 510 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 511 511 <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 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."> … … 538 538 </tr> 539 539 <tr> 540 <td class="left">Expires: September 13, 2012</td>540 <td class="left">Expires: September 22, 2012</td> 541 541 <td class="right">greenbytes</td> 542 542 </tr> 543 543 <tr> 544 544 <td class="left"></td> 545 <td class="right">March 12, 2012</td>545 <td class="right">March 21, 2012</td> 546 546 </tr> 547 547 </tbody> … … 573 573 in progress”. 574 574 </p> 575 <p>This Internet-Draft will expire on September 13, 2012.</p>575 <p>This Internet-Draft will expire on September 22, 2012.</p> 576 576 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 577 577 <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 1661 1661 <li>1xx: Informational - Request received, continuing process</li> 1662 1662 <li>2xx: Success - The action was successfully received, understood, and accepted</li> 1663 <li>3xx: Redirection - Further action mustbe taken in order to complete the request</li>1663 <li>3xx: Redirection - Further action needs to be taken in order to complete the request</li> 1664 1664 <li>4xx: Client Error - The request contains bad syntax or cannot be fulfilled</li> 1665 1665 <li>5xx: Server Error - The server failed to fulfill an apparently valid request</li> … … 2081 2081 </p> 2082 2082 <div class="note" id="rfc.section.7.5.4.p.3"> 2083 <p> <b>Note:</b> The existence of the 503 status code does not imply that a server mustuse it when becoming overloaded. Some servers might2083 <p> <b>Note:</b> The existence of the 503 status code does not imply that a server has to use it when becoming overloaded. Some servers might 2084 2084 wish to simply refuse the connection. 2085 2085 </p> … … 3005 3005 </p> 3006 3006 <p id="rfc.section.A.p.8">Deprecate 305 Use Proxy status code, because user agents did not implement it. It used to indicate that the target resource 3007 mustbe accessed through the proxy given by the Location field. The Location field gave the URI of the proxy. The recipient3007 needs to be accessed through the proxy given by the Location field. The Location field gave the URI of the proxy. The recipient 3008 3008 was expected to repeat this single request via the proxy. (<a href="#status.305" id="rfc.xref.status.305.3" title="305 Use Proxy">Section 7.3.5</a>) 3009 3009 </p> -
draft-ietf-httpbis/latest/p2-semantics.xml
r1590 r1604 1298 1298 </t> 1299 1299 <t> 1300 3xx: Redirection - Further action mustbe taken in order to1300 3xx: Redirection - Further action needs to be taken in order to 1301 1301 complete the request 1302 1302 </t> … … 2105 2105 <t> 2106 2106 <x:h>Note:</x:h> The existence of the 503 status code does not imply that a 2107 server mustuse it when becoming overloaded. Some servers might wish2107 server has to use it when becoming overloaded. Some servers might wish 2108 2108 to simply refuse the connection. 2109 2109 </t> … … 3703 3703 <t> 3704 3704 Deprecate 305 Use Proxy status code, because user agents did not implement it. 3705 It used to indicate that the target resource mustbe accessed through the3705 It used to indicate that the target resource needs to be accessed through the 3706 3706 proxy given by the Location field. The Location field gave the URI of the 3707 3707 proxy. The recipient was expected to repeat this single request via the proxy. -
draft-ietf-httpbis/latest/p3-payload.html
r1593 r1604 460 460 } 461 461 @bottom-center { 462 content: "Expires September 13, 2012";462 content: "Expires September 22, 2012"; 463 463 } 464 464 @bottom-right { … … 505 505 <meta name="dct.creator" content="Reschke, J. F."> 506 506 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p3-payload-latest"> 507 <meta name="dct.issued" scheme="ISO8601" content="2012-03- 12">507 <meta name="dct.issued" scheme="ISO8601" content="2012-03-21"> 508 508 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 509 509 <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 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."> … … 531 531 </tr> 532 532 <tr> 533 <td class="left">Expires: September 13, 2012</td>533 <td class="left">Expires: September 22, 2012</td> 534 534 <td class="right">J. Reschke, Editor</td> 535 535 </tr> … … 540 540 <tr> 541 541 <td class="left"></td> 542 <td class="right">March 12, 2012</td>542 <td class="right">March 21, 2012</td> 543 543 </tr> 544 544 </tbody> … … 568 568 in progress”. 569 569 </p> 570 <p>This Internet-Draft will expire on September 13, 2012.</p>570 <p>This Internet-Draft will expire on September 22, 2012.</p> 571 571 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 572 572 <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 1313 1313 <h2 id="rfc.section.6.5"><a href="#rfc.section.6.5">6.5</a> <a id="header.content-encoding" href="#header.content-encoding">Content-Encoding</a></h2> 1314 1314 <p id="rfc.section.6.5.p.1">The "Content-Encoding" header field indicates what content-codings have been applied to the representation beyond those inherent 1315 in the media type, and thus what decoding mechanisms must be applied in order to obtain the media-type referenced by the Content-Type1316 header field. Content-Encoding is primarily used to allow a representation to be compressed without losing the identity of1317 i ts underlying media type.1315 in the media type, and thus what decoding mechanisms have to be applied in order to obtain the media-type referenced by the 1316 Content-Type header field. Content-Encoding is primarily used to allow a representation to be compressed without losing the 1317 identity of its underlying media type. 1318 1318 </p> 1319 1319 <div id="rfc.figure.u.21"></div><pre class="inline"><span id="rfc.iref.g.20"></span> <a href="#header.content-encoding" class="smpl">Content-Encoding</a> = 1#<a href="#content.codings" class="smpl">content-coding</a> -
draft-ietf-httpbis/latest/p3-payload.xml
r1593 r1604 1192 1192 The "Content-Encoding" header field indicates what content-codings 1193 1193 have been applied to the representation beyond those inherent in the media 1194 type, and thus what decoding mechanisms mustbe applied in order to obtain1194 type, and thus what decoding mechanisms have to be applied in order to obtain 1195 1195 the media-type referenced by the Content-Type header field. 1196 1196 Content-Encoding is primarily used to allow a representation to be -
draft-ietf-httpbis/latest/p4-conditional.html
r1592 r1604 460 460 } 461 461 @bottom-center { 462 content: "Expires September 13, 2012";462 content: "Expires September 22, 2012"; 463 463 } 464 464 @bottom-right { … … 501 501 <meta name="dct.creator" content="Reschke, J. F."> 502 502 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p4-conditional-latest"> 503 <meta name="dct.issued" scheme="ISO8601" content="2012-03- 12">503 <meta name="dct.issued" scheme="ISO8601" content="2012-03-21"> 504 504 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 505 505 <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 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."> … … 527 527 </tr> 528 528 <tr> 529 <td class="left">Expires: September 13, 2012</td>529 <td class="left">Expires: September 22, 2012</td> 530 530 <td class="right">J. Reschke, Editor</td> 531 531 </tr> … … 536 536 <tr> 537 537 <td class="left"></td> 538 <td class="right">March 12, 2012</td>538 <td class="right">March 21, 2012</td> 539 539 </tr> 540 540 </tbody> … … 566 566 in progress”. 567 567 </p> 568 <p>This Internet-Draft will expire on September 13, 2012.</p>568 <p>This Internet-Draft will expire on September 22, 2012.</p> 569 569 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 570 570 <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 948 948 949 949 <em>...binary data...</em></pre><div class="note" id="rfc.section.2.3.3.p.7"> 950 <p> <b>Note:</b> Content codings are a property of the representation, so therefore an entity-tag of an encoded representation mustbe distinct950 <p> <b>Note:</b> Content codings are a property of the representation, so therefore an entity-tag of an encoded representation has to be distinct 951 951 from an unencoded representation to prevent conflicts during cache updates and range requests. In contrast, transfer codings 952 952 (<a href="p1-messaging.html#transfer.codings" title="Transfer Codings">Section 4</a> of <a href="#Part1" id="rfc.xref.Part1.6"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) apply only during message transfer and do not require distinct entity-tags. -
draft-ietf-httpbis/latest/p4-conditional.xml
r1592 r1604 637 637 <t> 638 638 <x:h>Note:</x:h> Content codings are a property of the representation, 639 so therefore an entity-tag of an encoded representation mustbe distinct639 so therefore an entity-tag of an encoded representation has to be distinct 640 640 from an unencoded representation to prevent conflicts during cache updates 641 641 and range requests. In contrast, transfer codings (&transfer-codings;) -
draft-ietf-httpbis/latest/p6-cache.html
r1592 r1604 463 463 } 464 464 @bottom-center { 465 content: "Expires September 13, 2012";465 content: "Expires September 22, 2012"; 466 466 } 467 467 @bottom-right { … … 505 505 <meta name="dct.creator" content="Reschke, J. F."> 506 506 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p6-cache-latest"> 507 <meta name="dct.issued" scheme="ISO8601" content="2012-03- 12">507 <meta name="dct.issued" scheme="ISO8601" content="2012-03-21"> 508 508 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 509 509 <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 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."> … … 531 531 </tr> 532 532 <tr> 533 <td class="left">Expires: September 13, 2012</td>533 <td class="left">Expires: September 22, 2012</td> 534 534 <td class="right">M. Nottingham, Editor</td> 535 535 </tr> … … 548 548 <tr> 549 549 <td class="left"></td> 550 <td class="right">March 12, 2012</td>550 <td class="right">March 21, 2012</td> 551 551 </tr> 552 552 </tbody> … … 578 578 in progress”. 579 579 </p> 580 <p>This Internet-Draft will expire on September 13, 2012.</p>580 <p>This Internet-Draft will expire on September 22, 2012.</p> 581 581 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 582 582 <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 924 924 <p id="rfc.section.2.2.p.3">When a stored response is used to satisfy a request without validation, a cache <em class="bcp14">MUST</em> include a single Age header field (<a href="#header.age" id="rfc.xref.header.age.1" title="Age">Section 3.1</a>) in the response with a value equal to the stored response's current_age; see <a href="#age.calculations" title="Calculating Age">Section 2.3.2</a>. 925 925 </p> 926 <p id="rfc.section.2.2.p.4">A cache <em class="bcp14">MUST</em> write through requests with methods that are unsafe (<a href="p2-semantics.html#safe.methods" title="Safe Methods">Section 6.1.1</a> of <a href="#Part2" id="rfc.xref.Part2.3"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) to the origin server; i.e., a cache must not generate a reply to such a request before having forwarded the request and927 having received a corresponding response.926 <p id="rfc.section.2.2.p.4">A cache <em class="bcp14">MUST</em> write through requests with methods that are unsafe (<a href="p2-semantics.html#safe.methods" title="Safe Methods">Section 6.1.1</a> of <a href="#Part2" id="rfc.xref.Part2.3"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) to the origin server; i.e., a cache is not allowed to generate a reply to such a request before having forwarded the request 927 and having received a corresponding response. 928 928 </p> 929 929 <p id="rfc.section.2.2.p.5">Also, note that unsafe requests might invalidate already stored responses; see <a href="#invalidation.after.updates.or.deletions" title="Request Methods that Invalidate">Section 2.6</a>. -
draft-ietf-httpbis/latest/p6-cache.xml
r1592 r1604 569 569 <t> 570 570 A cache &MUST; write through requests with methods that are unsafe 571 (&safe-methods;) to the origin server; i.e., a cache must notgenerate571 (&safe-methods;) to the origin server; i.e., a cache is not allowed to generate 572 572 a reply to such a request before having forwarded the request and having 573 573 received a corresponding response.
Note: See TracChangeset
for help on using the changeset viewer.