Changeset 859
- Timestamp:
- 21/07/10 14:16:15 (13 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 6 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r857 r859 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-07- 19">406 <meta name="dct.issued" scheme="ISO8601" content="2010-07-21"> 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: January 2 0, 2011</td>437 <td class="left">Expires: January 22, 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">July 19, 2010</td>490 <td class="right">July 21, 2010</td> 491 491 </tr> 492 492 </tbody> … … 516 516 in progress”. 517 517 </p> 518 <p>This Internet-Draft will expire in January 2 0, 2011.</p>518 <p>This Internet-Draft will expire in January 22, 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> … … 2956 2956 <p id="rfc.section.B.3.p.2">Transfer-coding and message lengths all interact in ways that required fixing exactly when chunked encoding is used (to allow 2957 2957 for transfer encoding that may not be self delimiting); it was important to straighten out exactly how message lengths are 2958 computed. (Sections <a href="#transfer.codings" title="Transfer Codings">6.2</a>, <a href="#message.body.length">3.3.p.7</a>, <a href="#header.content-length" id="rfc.xref.header.content-length.3" title="Content-Length">9.2</a>, see also <a href="#Part 3" id="rfc.xref.Part3.10"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="#Part5" id="rfc.xref.Part5.1"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a> and <a href="#Part6" id="rfc.xref.Part6.10"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>)2958 computed. (Sections <a href="#transfer.codings" title="Transfer Codings">6.2</a>, <a href="#message.body.length">3.3.p.7</a>, <a href="#header.content-length" id="rfc.xref.header.content-length.3" title="Content-Length">9.2</a>, see also <a href="#Part5" id="rfc.xref.Part5.1"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>) 2959 2959 </p> 2960 2960 <p id="rfc.section.B.3.p.3">The use and interpretation of HTTP version numbers has been clarified by <a href="#RFC2145" id="rfc.xref.RFC2145.3"><cite title="Use and Interpretation of HTTP Version Numbers">[RFC2145]</cite></a>. Require proxies to upgrade requests to highest protocol version they support to deal with problems discovered in HTTP/1.0 … … 3689 3689 </ul> 3690 3690 </li> 3691 <li class="indline1"><em>Part3</em> <a class="iref" href="#rfc.xref.Part3.1">1</a>, <a class="iref" href="#rfc.xref.Part3.2">1.2.3</a>, <a class="iref" href="#rfc.xref.Part3.3">4</a>, <a class="iref" href="#rfc.xref.Part3.4">5</a>, <a class="iref" href="#rfc.xref.Part3.5">6.2.3</a>, <a class="iref" href="#rfc.xref.Part3.6">6.4</a>, <a class="iref" href="#rfc.xref.Part3.7">7.1.3.2</a>, <a class="iref" href="#rfc.xref.Part3.8">9.7</a>, <a class="iref" href="#Part3"><b>13.1</b></a>, <a class="iref" href="#rfc.xref.Part3.9">A</a> , <a class="iref" href="#rfc.xref.Part3.10">B.3</a><ul class="ind">3691 <li class="indline1"><em>Part3</em> <a class="iref" href="#rfc.xref.Part3.1">1</a>, <a class="iref" href="#rfc.xref.Part3.2">1.2.3</a>, <a class="iref" href="#rfc.xref.Part3.3">4</a>, <a class="iref" href="#rfc.xref.Part3.4">5</a>, <a class="iref" href="#rfc.xref.Part3.5">6.2.3</a>, <a class="iref" href="#rfc.xref.Part3.6">6.4</a>, <a class="iref" href="#rfc.xref.Part3.7">7.1.3.2</a>, <a class="iref" href="#rfc.xref.Part3.8">9.7</a>, <a class="iref" href="#Part3"><b>13.1</b></a>, <a class="iref" href="#rfc.xref.Part3.9">A</a><ul class="ind"> 3692 3692 <li class="indline1"><em>Section 2.2</em> <a class="iref" href="#rfc.xref.Part3.5">6.2.3</a>, <a class="iref" href="#rfc.xref.Part3.8">9.7</a></li> 3693 3693 <li class="indline1"><em>Section 3.1</em> <a class="iref" href="#rfc.xref.Part3.2">1.2.3</a>, <a class="iref" href="#rfc.xref.Part3.3">4</a>, <a class="iref" href="#rfc.xref.Part3.4">5</a></li> … … 3697 3697 </li> 3698 3698 <li class="indline1"><em>Part5</em> <a class="iref" href="#Part5"><b>13.1</b></a>, <a class="iref" href="#rfc.xref.Part5.1">B.3</a></li> 3699 <li class="indline1"><em>Part6</em> <a class="iref" href="#rfc.xref.Part6.1">1.2.3</a>, <a class="iref" href="#rfc.xref.Part6.2">1.2.3</a>, <a class="iref" href="#rfc.xref.Part6.3">1.2.3</a>, <a class="iref" href="#rfc.xref.Part6.4">2.3</a>, <a class="iref" href="#rfc.xref.Part6.5">3.3</a>, <a class="iref" href="#rfc.xref.Part6.6">3.4</a>, <a class="iref" href="#rfc.xref.Part6.7">3.4</a>, <a class="iref" href="#rfc.xref.Part6.8">3.4</a>, <a class="iref" href="#rfc.xref.Part6.9">7.1.3.2</a>, <a class="iref" href="#Part6"><b>13.1</b></a> , <a class="iref" href="#rfc.xref.Part6.10">B.3</a><ul class="ind">3699 <li class="indline1"><em>Part6</em> <a class="iref" href="#rfc.xref.Part6.1">1.2.3</a>, <a class="iref" href="#rfc.xref.Part6.2">1.2.3</a>, <a class="iref" href="#rfc.xref.Part6.3">1.2.3</a>, <a class="iref" href="#rfc.xref.Part6.4">2.3</a>, <a class="iref" href="#rfc.xref.Part6.5">3.3</a>, <a class="iref" href="#rfc.xref.Part6.6">3.4</a>, <a class="iref" href="#rfc.xref.Part6.7">3.4</a>, <a class="iref" href="#rfc.xref.Part6.8">3.4</a>, <a class="iref" href="#rfc.xref.Part6.9">7.1.3.2</a>, <a class="iref" href="#Part6"><b>13.1</b></a><ul class="ind"> 3700 3700 <li class="indline1"><em>Section 2</em> <a class="iref" href="#rfc.xref.Part6.4">2.3</a></li> 3701 3701 <li class="indline1"><em>Section 2.1.1</em> <a class="iref" href="#rfc.xref.Part6.5">3.3</a></li> -
draft-ietf-httpbis/latest/p1-messaging.xml
r854 r859 4875 4875 <xref target="transfer.codings" format="counter"/>, <xref target="message.body.length" format="counter"/>, 4876 4876 <xref target="header.content-length" format="counter"/>, 4877 see also <xref target="Part 3"/>, <xref target="Part5"/> and <xref target="Part6"/>)4877 see also <xref target="Part5"/>) 4878 4878 </t> 4879 4879 <t> -
draft-ietf-httpbis/latest/p3-payload.html
r858 r859 401 401 <meta name="dct.creator" content="Reschke, J. F."> 402 402 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p3-payload-latest"> 403 <meta name="dct.issued" scheme="ISO8601" content="2010-07- 19">403 <meta name="dct.issued" scheme="ISO8601" content="2010-07-21"> 404 404 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 405 405 <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."> … … 427 427 </tr> 428 428 <tr> 429 <td class="left">Expires: January 2 0, 2011</td>429 <td class="left">Expires: January 22, 2011</td> 430 430 <td class="right">J. Mogul</td> 431 431 </tr> … … 484 484 <tr> 485 485 <td class="left"></td> 486 <td class="right">July 19, 2010</td>486 <td class="right">July 21, 2010</td> 487 487 </tr> 488 488 </tbody> … … 510 510 in progress”. 511 511 </p> 512 <p>This Internet-Draft will expire in January 2 0, 2011.</p>512 <p>This Internet-Draft will expire in January 22, 2011.</p> 513 513 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 514 514 <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 1810 1810 <h1 id="rfc.section.C"><a href="#rfc.section.C">C.</a> <a id="compatibility" href="#compatibility">Compatibility with Previous Versions</a></h1> 1811 1811 <h2 id="rfc.section.C.1"><a href="#rfc.section.C.1">C.1</a> <a id="changes.from.rfc.2068" href="#changes.from.rfc.2068">Changes from RFC 2068</a></h2> 1812 <p id="rfc.section.C.1.p.1">Transfer-coding and message lengths all interact in ways that required fixing exactly when chunked encoding is used (to allow 1813 for transfer encoding that may not be self delimiting); it was important to straighten out exactly how message lengths are 1814 computed. 1815 </p> 1816 <p id="rfc.section.C.1.p.2">Charset wildcarding is introduced to avoid explosion of character set names in accept headers. (<a href="#header.accept-charset" id="rfc.xref.header.accept-charset.3" title="Accept-Charset">Section 5.2</a>) 1817 </p> 1818 <p id="rfc.section.C.1.p.3">Content-Base was deleted from the specification: it was not implemented widely, and there is no simple, safe way to introduce 1812 <p id="rfc.section.C.1.p.1">Charset wildcarding is introduced to avoid explosion of character set names in accept headers. (<a href="#header.accept-charset" id="rfc.xref.header.accept-charset.3" title="Accept-Charset">Section 5.2</a>) 1813 </p> 1814 <p id="rfc.section.C.1.p.2">Content-Base was deleted from the specification: it was not implemented widely, and there is no simple, safe way to introduce 1819 1815 it without a robust extension mechanism. In addition, it is used in a similar, but not identical fashion in MHTML <a href="#RFC2557" id="rfc.xref.RFC2557.3"><cite title="MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)">[RFC2557]</cite></a>. 1820 1816 </p> 1821 <p id="rfc.section.C.1.p. 4">A content-coding of "identity" was introduced, to solve problems discovered in caching. (<a href="#content.codings" title="Content Codings">Section 2.2</a>)1822 </p> 1823 <p id="rfc.section.C.1.p. 5">The Alternates<span id="rfc.iref.a.5"></span><span id="rfc.iref.h.12"></span>, Content-Version<span id="rfc.iref.c.13"></span><span id="rfc.iref.h.13"></span>, Derived-From<span id="rfc.iref.d.2"></span><span id="rfc.iref.h.14"></span>, Link<span id="rfc.iref.l.1"></span><span id="rfc.iref.h.15"></span>, URI<span id="rfc.iref.u.1"></span><span id="rfc.iref.h.16"></span>, Public<span id="rfc.iref.p.2"></span><span id="rfc.iref.h.17"></span> and Content-Base<span id="rfc.iref.c.14"></span><span id="rfc.iref.h.18"></span> header fields were defined in previous versions of this specification, but not commonly implemented. See <a href="http://tools.ietf.org/html/rfc2068#section-19.6.2">Section 19.6.2</a> of <a href="#RFC2068" id="rfc.xref.RFC2068.5"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>.1817 <p id="rfc.section.C.1.p.3">A content-coding of "identity" was introduced, to solve problems discovered in caching. (<a href="#content.codings" title="Content Codings">Section 2.2</a>) 1818 </p> 1819 <p id="rfc.section.C.1.p.4">The Alternates<span id="rfc.iref.a.5"></span><span id="rfc.iref.h.12"></span>, Content-Version<span id="rfc.iref.c.13"></span><span id="rfc.iref.h.13"></span>, Derived-From<span id="rfc.iref.d.2"></span><span id="rfc.iref.h.14"></span>, Link<span id="rfc.iref.l.1"></span><span id="rfc.iref.h.15"></span>, URI<span id="rfc.iref.u.1"></span><span id="rfc.iref.h.16"></span>, Public<span id="rfc.iref.p.2"></span><span id="rfc.iref.h.17"></span> and Content-Base<span id="rfc.iref.c.14"></span><span id="rfc.iref.h.18"></span> header fields were defined in previous versions of this specification, but not commonly implemented. See <a href="http://tools.ietf.org/html/rfc2068#section-19.6.2">Section 19.6.2</a> of <a href="#RFC2068" id="rfc.xref.RFC2068.5"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>. 1824 1820 </p> 1825 1821 <h2 id="rfc.section.C.2"><a href="#rfc.section.C.2">C.2</a> <a id="changes.from.rfc.2616" href="#changes.from.rfc.2616">Changes from RFC 2616</a></h2> -
draft-ietf-httpbis/latest/p3-payload.xml
r858 r859 2745 2745 <section title="Changes from RFC 2068" anchor="changes.from.rfc.2068"> 2746 2746 <t> 2747 Transfer-coding and message lengths all interact in ways that2748 required fixing exactly when chunked encoding is used (to allow for2749 transfer encoding that may not be self delimiting); it was important2750 to straighten out exactly how message lengths are computed.2751 </t>2752 <t>2753 2747 Charset wildcarding is introduced to avoid explosion of character set 2754 2748 names in accept headers. (<xref target="header.accept-charset"/>) -
draft-ietf-httpbis/latest/p5-range.html
r857 r859 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-07- 19">402 <meta name="dct.issued" scheme="ISO8601" content="2010-07-21"> 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: January 2 0, 2011</td>428 <td class="left">Expires: January 22, 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">July 19, 2010</td>485 <td class="right">July 21, 2010</td> 486 486 </tr> 487 487 </tbody> … … 509 509 in progress”. 510 510 </p> 511 <p>This Internet-Draft will expire in January 2 0, 2011.</p>511 <p>This Internet-Draft will expire in January 22, 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> … … 1160 1160 <p id="rfc.section.B.1.p.1">Transfer-coding and message lengths all interact in ways that required fixing exactly when chunked encoding is used (to allow 1161 1161 for transfer encoding that may not be self delimiting); it was important to straighten out exactly how message lengths are 1162 computed. (<a href="#header.content-range" id="rfc.xref.header.content-range.5" title="Content-Range">Section 5.2</a>, see also <a href="#Part1" id="rfc.xref.Part1.7"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> , <a href="#Part3" id="rfc.xref.Part3.1"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a> and <a href="#Part6" id="rfc.xref.Part6.1"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>)1162 computed. (<a href="#header.content-range" id="rfc.xref.header.content-range.5" title="Content-Range">Section 5.2</a>, see also <a href="#Part1" id="rfc.xref.Part1.7"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) 1163 1163 </p> 1164 1164 <p id="rfc.section.B.1.p.2">There are situations where a server (especially a proxy) does not know the full length of a response but is capable of serving … … 1407 1407 </ul> 1408 1408 </li> 1409 <li class="indline1"><em>Part3</em> <a class="iref" href="#Part3"><b>9.1</b></a> , <a class="iref" href="#rfc.xref.Part3.1">B.1</a></li>1409 <li class="indline1"><em>Part3</em> <a class="iref" href="#Part3"><b>9.1</b></a></li> 1410 1410 <li class="indline1"><em>Part4</em> <a class="iref" href="#rfc.xref.Part4.1">1.2.2</a>, <a class="iref" href="#rfc.xref.Part4.2">4</a>, <a class="iref" href="#Part4"><b>9.1</b></a><ul class="ind"> 1411 1411 <li class="indline1"><em>Section 2</em> <a class="iref" href="#rfc.xref.Part4.1">1.2.2</a></li> … … 1413 1413 </ul> 1414 1414 </li> 1415 <li class="indline1"><em>Part6</em> <a class="iref" href="#Part6"><b>9.1</b></a> , <a class="iref" href="#rfc.xref.Part6.1">B.1</a></li>1415 <li class="indline1"><em>Part6</em> <a class="iref" href="#Part6"><b>9.1</b></a></li> 1416 1416 </ul> 1417 1417 </li> -
draft-ietf-httpbis/latest/p5-range.xml
r852 r859 1407 1407 to straighten out exactly how message lengths are computed. 1408 1408 (<xref target="header.content-range"/>, 1409 see also <xref target="Part1"/> , <xref target="Part3"/> and <xref target="Part6"/>)1409 see also <xref target="Part1"/>) 1410 1410 </t> 1411 1411 <t>
Note: See TracChangeset
for help on using the changeset viewer.