Changeset 115 for draft-ietf-httpbis
- Timestamp:
- 30/12/07 14:56:05 (15 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 14 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r113 r115 348 348 <link rel="Appendix" title="C Conversion of Date Formats" href="#rfc.section.C"> 349 349 <link rel="Appendix" title="D Compatibility with Previous Versions" href="#rfc.section.D"> 350 <link rel="Appendix" title="E Change Log (to be removed by RFC Editor before publication)" href="#rfc.section.E"> 350 351 <meta name="generator" content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.353, 2007/12/11 23:20:44, XSLT vendor: SAXON 8.9 from Saxonica http://www.saxonica.com/"> 351 352 <link rel="schema.DC" href="http://purl.org/dc/elements/1.1/"> … … 478 479 </p> 479 480 <h1 id="rfc.note.1"><a href="#rfc.note.1">Editorial Note (To be removed by RFC Editor)</a></h1> 480 <p>This version of the HTTP specification contains only minimal editorial changes from <a href="#RFC2616" id="rfc.xref.RFC2616.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a> (abstract, introductory paragraph, and authors' addresses). All other changes are due to partitioning the original into seven481 mostly independent parts. The intent is for readers of future drafts to able to use draft 00 as the basis for comparison when482 the WG makes later changes to the specification text. This draft will shortly be followed by draft 01 (containing the first483 round of changes that have already been agreed to on the mailing list). There is no point in reviewing this draft other than484 to verify that the partitioning has been done correctly. Roy T. Fielding, Yves Lafon, and Julian Reschke will be the editors485 after draft 00 is submitted.486 </p>487 481 <p>Discussion of this draft should take place on the HTTPBIS working group mailing list (ietf-http-wg@w3.org). The current issues 488 482 list is at <<a href="http://www.tools.ietf.org/wg/httpbis/trac/report/11">http://www.tools.ietf.org/wg/httpbis/trac/report/11</a>> and related documents (including fancy diffs) can be found at <<a href="http://www.tools.ietf.org/wg/httpbis/">http://www.tools.ietf.org/wg/httpbis/</a>>. … … 607 601 </ul> 608 602 </li> 603 <li class="tocline0">E. <a href="#rfc.section.E">Change Log (to be removed by RFC Editor before publication)</a><ul class="toc"> 604 <li class="tocline1">E.1 <a href="#rfc.section.E.1">Since RFC2616</a></li> 605 <li class="tocline1">E.2 <a href="#rfc.section.E.2">Since draft-ietf-httpbis-p1-messaging-00</a></li> 606 </ul> 607 </li> 609 608 <li class="tocline0"><a href="#rfc.ipr">Intellectual Property and Copyright Statements</a></li> 610 609 <li class="tocline0"><a href="#rfc.index">Index</a></li> … … 612 611 <h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a> <a id="introduction" href="#introduction">Introduction</a></h1> 613 612 <p id="rfc.section.1.p.1">This document will define aspects of HTTP related to overall network operation, message framing, interaction with transport 614 protocols, and URI schemes. Right now it only includes the extracted relevant sections of <a href="#RFC2616" id="rfc.xref.RFC2616. 2"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>.613 protocols, and URI schemes. Right now it only includes the extracted relevant sections of <a href="#RFC2616" id="rfc.xref.RFC2616.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>. 615 614 </p> 616 615 <h2 id="rfc.section.1.1"><a href="#rfc.section.1.1">1.1</a> <a id="intro.purpose" href="#intro.purpose">Purpose</a></h2> … … 927 926 <"> = <US-ASCII double-quote mark (34)> 928 927 </pre><p id="rfc.section.2.2.p.3">HTTP/1.1 defines the sequence CR LF as the end-of-line marker for all protocol elements except the entity-body (see <a href="#tolerant.applications" title="Tolerant Applications">Appendix B</a> for tolerant applications). The end-of-line marker within an entity-body is defined by its associated media type, as described 929 in <a href=" #Part3" id="rfc.xref.Part3.5"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>.928 in <a href="p3-payload.html#media.types" title="Media Types">Section 2.3</a> of <a href="#Part3" id="rfc.xref.Part3.5"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>. 930 929 </p> 931 930 <div id="rfc.figure.u.5"></div><pre class="inline"><span id="rfc.iref.g.13"></span> CRLF = CR LF … … 1100 1099 </p> 1101 1100 <p id="rfc.section.3.4.p.8">The Internet Assigned Numbers Authority (IANA) acts as a registry for transfer-coding value tokens. Initially, the registry 1102 contains the following tokens: "chunked" (<a href="#chunked.transfer.encoding" title="Chunked Transfer Coding">Section 3.4.1</a>), "gzip" (<a href="#Part3" id="rfc.xref.Part3.6"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>), "compress" (<a href="#Part3" id="rfc.xref.Part3.7"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>), and "deflate" (<a href="#Part3" id="rfc.xref.Part3.8"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>).1103 </p> 1104 <p id="rfc.section.3.4.p.9">New transfer-coding value tokens <em class="bcp14">SHOULD</em> be registered in the same way as new content-coding value tokens (<a href=" #Part3" id="rfc.xref.Part3.9"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>).1101 contains the following tokens: "chunked" (<a href="#chunked.transfer.encoding" title="Chunked Transfer Coding">Section 3.4.1</a>), "gzip", "compress", and "deflate" (<a href="p3-payload.html#content.codings" title="Content Codings">Section 2.2</a> of <a href="#Part3" id="rfc.xref.Part3.6"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>). 1102 </p> 1103 <p id="rfc.section.3.4.p.9">New transfer-coding value tokens <em class="bcp14">SHOULD</em> be registered in the same way as new content-coding value tokens (<a href="p3-payload.html#content.codings" title="Content Codings">Section 2.2</a> of <a href="#Part3" id="rfc.xref.Part3.7"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>). 1105 1104 </p> 1106 1105 <p id="rfc.section.3.4.p.10">A server which receives an entity-body with a transfer-coding it does not understand <em class="bcp14">SHOULD</em> return 501 (Unimplemented), and close the connection. A server <em class="bcp14">MUST NOT</em> send transfer-codings to an HTTP/1.0 client. … … 1185 1184 </p> 1186 1185 <h2 id="rfc.section.4.2"><a href="#rfc.section.4.2">4.2</a> <a id="message.headers" href="#message.headers">Message Headers</a></h2> 1187 <p id="rfc.section.4.2.p.1">HTTP header fields, which include general-header (<a href="#general.header.fields" title="General Header Fields">Section 4.5</a>), request-header (<a href="p2-semantics.html#request.header.fields" title="Request Header Fields">Section 4</a> of <a href="#Part2" id="rfc.xref.Part2.2"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>), response-header (<a href="p2-semantics.html#response.header.fields" title="Response Header Fields">Section 6</a> of <a href="#Part2" id="rfc.xref.Part2.3"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>), and entity-header (<a href="p3-payload.html#entity.header.fields" title="Entity Header Fields">Section 3.1</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>) fields, follow the same generic format as that given in <a href="http://tools.ietf.org/html/rfc822#section-3.1">Section 3.1</a> of <a href="#RFC822" id="rfc.xref.RFC822.5"><cite title="Standard for the format of ARPA Internet text messages">[RFC822]</cite></a>. Each header field consists of a name followed by a colon (":") and the field value. Field names are case-insensitive. The1186 <p id="rfc.section.4.2.p.1">HTTP header fields, which include general-header (<a href="#general.header.fields" title="General Header Fields">Section 4.5</a>), request-header (<a href="p2-semantics.html#request.header.fields" title="Request Header Fields">Section 4</a> of <a href="#Part2" id="rfc.xref.Part2.2"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>), response-header (<a href="p2-semantics.html#response.header.fields" title="Response Header Fields">Section 6</a> of <a href="#Part2" id="rfc.xref.Part2.3"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>), and entity-header (<a href="p3-payload.html#entity.header.fields" title="Entity Header Fields">Section 3.1</a> of <a href="#Part3" id="rfc.xref.Part3.8"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) fields, follow the same generic format as that given in <a href="http://tools.ietf.org/html/rfc822#section-3.1">Section 3.1</a> of <a href="#RFC822" id="rfc.xref.RFC822.5"><cite title="Standard for the format of ARPA Internet text messages">[RFC822]</cite></a>. Each header field consists of a name followed by a colon (":") and the field value. Field names are case-insensitive. The 1188 1187 field value <em class="bcp14">MAY</em> be preceded by any amount of LWS, though a single SP is preferred. Header fields can be extended over multiple lines by preceding 1189 1188 each extra line with at least one SP or HT. Applications ought to follow "common form", where one is known or indicated, when … … 1300 1299 *(( general-header ; <a href="#general.header.fields" title="General Header Fields">Section 4.5</a> 1301 1300 | request-header ; <a href="#Part2" id="rfc.xref.Part2.5"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>, <a href="p2-semantics.html#request.header.fields" title="Request Header Fields">Section 4</a> 1302 | entity-header ) CRLF) ; <a href="#Part3" id="rfc.xref.Part3. 11"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#entity.header.fields" title="Entity Header Fields">Section 3.1</a>1301 | entity-header ) CRLF) ; <a href="#Part3" id="rfc.xref.Part3.9"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#entity.header.fields" title="Entity Header Fields">Section 3.1</a> 1303 1302 CRLF 1304 1303 [ message-body ] ; <a href="#message.body" title="Message Body">Section 4.3</a> … … 1378 1377 *(( general-header ; <a href="#general.header.fields" title="General Header Fields">Section 4.5</a> 1379 1378 | response-header ; <a href="#Part2" id="rfc.xref.Part2.7"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>, <a href="p2-semantics.html#response.header.fields" title="Response Header Fields">Section 6</a> 1380 | entity-header ) CRLF) ; <a href="#Part3" id="rfc.xref.Part3.1 2"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#entity.header.fields" title="Entity Header Fields">Section 3.1</a>1379 | entity-header ) CRLF) ; <a href="#Part3" id="rfc.xref.Part3.10"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#entity.header.fields" title="Entity Header Fields">Section 3.1</a> 1381 1380 CRLF 1382 1381 [ message-body ] ; <a href="#message.body" title="Message Body">Section 4.3</a> … … 1719 1718 <li> 1720 1719 <p>If the transfer-coding being tested is one of the transfer-codings listed in the TE field, then it is acceptable unless it 1721 is accompanied by a qvalue of 0. (As defined in <a href="p3-payload.html#quality.values" title="Quality Values">Section 2.4</a> of <a href="#Part3" id="rfc.xref.Part3.1 3"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, a qvalue of 0 means "not acceptable.")1720 is accompanied by a qvalue of 0. (As defined in <a href="p3-payload.html#quality.values" title="Quality Values">Section 2.4</a> of <a href="#Part3" id="rfc.xref.Part3.11"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, a qvalue of 0 means "not acceptable.") 1722 1721 </p> 1723 1722 </li> … … 1927 1926 </p> 1928 1927 <p id="rfc.section.11.p.5">Thanks to the "cave men" of Palo Alto. You know who you are.</p> 1929 <p id="rfc.section.11.p.6">Jim Gettys (the current editor of this document) wishes particularly to thank Roy Fielding, the previous editor of this document, 1930 along with John Klensin, Jeff Mogul, Paul Leach, Dave Kristol, Koen Holtman, John Franks, Josh Cohen, Alex Hopmann, Scott 1928 <p id="rfc.section.11.p.6">Jim Gettys (the editor of <a href="#RFC2616" id="rfc.xref.RFC2616.2"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>) wishes particularly to thank Roy Fielding, the editor of <a href="#RFC2068" id="rfc.xref.RFC2068.5"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>, along with John Klensin, Jeff Mogul, Paul Leach, Dave Kristol, Koen Holtman, John Franks, Josh Cohen, Alex Hopmann, Scott 1931 1929 Lawrence, and Larry Masinter for their help. And thanks go particularly to Jeff Mogul and Scott Lawrence for performing the 1932 1930 "MUST/MAY/SHOULD" audit. … … 2189 2187 </p> 2190 2188 <p id="rfc.section.B.p.4">The character set of an entity-body <em class="bcp14">SHOULD</em> be labeled as the lowest common denominator of the character codes used within that body, with the exception that not labeling 2191 the entity is preferred over labeling the entity with the labels US-ASCII or ISO-8859-1. See <a href="#Part3" id="rfc.xref.Part3.1 4"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>.2189 the entity is preferred over labeling the entity with the labels US-ASCII or ISO-8859-1. See <a href="#Part3" id="rfc.xref.Part3.12"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>. 2192 2190 </p> 2193 2191 <p id="rfc.section.B.p.5">Additional rules for requirements on parsing and encoding of dates and other potential problems with date encodings include:</p> … … 2224 2222 <p id="rfc.section.D.p.3">For most implementations of HTTP/1.0, each connection is established by the client prior to the request and closed by the 2225 2223 server after sending the response. Some implementations implement the Keep-Alive version of persistent connections described 2226 in <a href="http://tools.ietf.org/html/rfc2068#section-19.7.1">Section 19.7.1</a> of <a href="#RFC2068" id="rfc.xref.RFC2068. 5"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>.2224 in <a href="http://tools.ietf.org/html/rfc2068#section-19.7.1">Section 19.7.1</a> of <a href="#RFC2068" id="rfc.xref.RFC2068.6"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>. 2227 2225 </p> 2228 2226 <h2 id="rfc.section.D.1"><a href="#rfc.section.D.1">D.1</a> <a id="changes.from.1.0" href="#changes.from.1.0">Changes from HTTP/1.0</a></h2> … … 2264 2262 a new keyword (Connection: close) for declaring non-persistence. See <a href="#header.connection" id="rfc.xref.header.connection.6" title="Connection">Section 8.1</a>. 2265 2263 </p> 2266 <p id="rfc.section.D.2.p.3">The original HTTP/1.0 form of persistent connections (the Connection: Keep-Alive and Keep-Alive header) is documented in <a href="#RFC2068" id="rfc.xref.RFC2068. 6"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>.2264 <p id="rfc.section.D.2.p.3">The original HTTP/1.0 form of persistent connections (the Connection: Keep-Alive and Keep-Alive header) is documented in <a href="#RFC2068" id="rfc.xref.RFC2068.7"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>. 2267 2265 </p> 2268 2266 <h2 id="rfc.section.D.3"><a href="#rfc.section.D.3">D.3</a> <a id="changes.from.rfc.2068" href="#changes.from.rfc.2068">Changes from RFC 2068</a></h2> … … 2295 2293 <p id="rfc.section.D.4.p.5">Clarify exactly when close connection options must be sent. (<a href="#header.connection" id="rfc.xref.header.connection.7" title="Connection">Section 8.1</a>) 2296 2294 </p> 2295 <h1 id="rfc.section.E"><a href="#rfc.section.E">E.</a> Change Log (to be removed by RFC Editor before publication) 2296 </h1> 2297 <h2 id="rfc.section.E.1"><a href="#rfc.section.E.1">E.1</a> Since RFC2616 2298 </h2> 2299 <p id="rfc.section.E.1.p.1">Extracted relevant partitions from <a href="#RFC2616" id="rfc.xref.RFC2616.3"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>. 2300 </p> 2301 <h2 id="rfc.section.E.2"><a href="#rfc.section.E.2">E.2</a> Since draft-ietf-httpbis-p1-messaging-00 2302 </h2> 2303 <p id="rfc.section.E.2.p.1">TBD.</p> 2297 2304 <h1><a id="rfc.copyright" href="#rfc.copyright">Full Copyright Statement</a></h1> 2298 2305 <p>Copyright © The IETF Trust (2007).</p> … … 2499 2506 </ul> 2500 2507 </li> 2501 <li class="indline1"><em>Part3</em> <a class="iref" href="#rfc.xref.Part3.1">1.3</a>, <a class="iref" href="#rfc.xref.Part3.2">1.3</a>, <a class="iref" href="#rfc.xref.Part3.3">1.3</a>, <a class="iref" href="#rfc.xref.Part3.4">1.4</a>, <a class="iref" href="#rfc.xref.Part3.5">2.2</a>, <a class="iref" href="#rfc.xref.Part3.6">3.4</a>, <a class="iref" href="#rfc.xref.Part3.7">3.4</a>, <a class="iref" href="#rfc.xref.Part3.8">3.4</a>, <a class="iref" href="#rfc.xref.Part3.9">3.4</a>, <a class="iref" href="#rfc.xref.Part3.10">4.2</a>, <a class="iref" href="#rfc.xref.Part3.11">5</a>, <a class="iref" href="#rfc.xref.Part3.12">6</a>, <a class="iref" href="#rfc.xref.Part3.13">8.5</a>, <a class="iref" href="#Part3"><b>12</b></a>, <a class="iref" href="#rfc.xref.Part3.14">B</a><ul class="ind"> 2502 <li class="indline1"><em>Section 2.4</em> <a class="iref" href="#rfc.xref.Part3.13">8.5</a></li> 2508 <li class="indline1"><em>Part3</em> <a class="iref" href="#rfc.xref.Part3.1">1.3</a>, <a class="iref" href="#rfc.xref.Part3.2">1.3</a>, <a class="iref" href="#rfc.xref.Part3.3">1.3</a>, <a class="iref" href="#rfc.xref.Part3.4">1.4</a>, <a class="iref" href="#rfc.xref.Part3.5">2.2</a>, <a class="iref" href="#rfc.xref.Part3.6">3.4</a>, <a class="iref" href="#rfc.xref.Part3.7">3.4</a>, <a class="iref" href="#rfc.xref.Part3.8">4.2</a>, <a class="iref" href="#rfc.xref.Part3.9">5</a>, <a class="iref" href="#rfc.xref.Part3.10">6</a>, <a class="iref" href="#rfc.xref.Part3.11">8.5</a>, <a class="iref" href="#Part3"><b>12</b></a>, <a class="iref" href="#rfc.xref.Part3.12">B</a><ul class="ind"> 2509 <li class="indline1"><em>Section 2.2</em> <a class="iref" href="#rfc.xref.Part3.6">3.4</a>, <a class="iref" href="#rfc.xref.Part3.7">3.4</a></li> 2510 <li class="indline1"><em>Section 2.3</em> <a class="iref" href="#rfc.xref.Part3.5">2.2</a></li> 2511 <li class="indline1"><em>Section 2.4</em> <a class="iref" href="#rfc.xref.Part3.11">8.5</a></li> 2503 2512 <li class="indline1"><em>Section 3</em> <a class="iref" href="#rfc.xref.Part3.1">1.3</a></li> 2504 <li class="indline1"><em>Section 3.1</em> <a class="iref" href="#rfc.xref.Part3. 10">4.2</a>, <a class="iref" href="#rfc.xref.Part3.11">5</a>, <a class="iref" href="#rfc.xref.Part3.12">6</a></li>2513 <li class="indline1"><em>Section 3.1</em> <a class="iref" href="#rfc.xref.Part3.8">4.2</a>, <a class="iref" href="#rfc.xref.Part3.9">5</a>, <a class="iref" href="#rfc.xref.Part3.10">6</a></li> 2505 2514 <li class="indline1"><em>Section 4</em> <a class="iref" href="#rfc.xref.Part3.2">1.3</a>, <a class="iref" href="#rfc.xref.Part3.3">1.3</a></li> 2506 2515 <li class="indline1"><em>Section A</em> <a class="iref" href="#rfc.xref.Part3.4">1.4</a></li> … … 2533 2542 <li class="indline1"><em>RFC2045</em> <a class="iref" href="#rfc.xref.RFC2045.1">1.1</a>, <a class="iref" href="#rfc.xref.RFC2045.2">3.4</a>, <a class="iref" href="#rfc.xref.RFC2045.3">11</a>, <a class="iref" href="#RFC2045"><b>12</b></a></li> 2534 2543 <li class="indline1"><em>RFC2047</em> <a class="iref" href="#rfc.xref.RFC2047.1">2.2</a>, <a class="iref" href="#RFC2047"><b>12</b></a></li> 2535 <li class="indline1"><em>RFC2068</em> <a class="iref" href="#rfc.xref.RFC2068.1">3.1</a>, <a class="iref" href="#rfc.xref.RFC2068.2">7.1.1</a>, <a class="iref" href="#rfc.xref.RFC2068.3">7.1.3</a>, <a class="iref" href="#rfc.xref.RFC2068.4">7.2.3</a>, <a class="iref" href="# RFC2068"><b>12</b></a>, <a class="iref" href="#rfc.xref.RFC2068.5">D</a>, <a class="iref" href="#rfc.xref.RFC2068.6">D.2</a><ul class="ind">2536 <li class="indline1"><em>Section 19.7.1</em> <a class="iref" href="#rfc.xref.RFC2068. 5">D</a></li>2544 <li class="indline1"><em>RFC2068</em> <a class="iref" href="#rfc.xref.RFC2068.1">3.1</a>, <a class="iref" href="#rfc.xref.RFC2068.2">7.1.1</a>, <a class="iref" href="#rfc.xref.RFC2068.3">7.1.3</a>, <a class="iref" href="#rfc.xref.RFC2068.4">7.2.3</a>, <a class="iref" href="#rfc.xref.RFC2068.5">11</a>, <a class="iref" href="#RFC2068"><b>12</b></a>, <a class="iref" href="#rfc.xref.RFC2068.6">D</a>, <a class="iref" href="#rfc.xref.RFC2068.7">D.2</a><ul class="ind"> 2545 <li class="indline1"><em>Section 19.7.1</em> <a class="iref" href="#rfc.xref.RFC2068.6">D</a></li> 2537 2546 </ul> 2538 2547 </li> … … 2544 2553 </ul> 2545 2554 </li> 2546 <li class="indline1"><em>RFC2616</em> <a class="iref" href="#rfc.xref.RFC2616.1"> §</a>, <a class="iref" href="#rfc.xref.RFC2616.2">1</a>, <a class="iref" href="#RFC2616"><b>12</b></a></li>2555 <li class="indline1"><em>RFC2616</em> <a class="iref" href="#rfc.xref.RFC2616.1">1</a>, <a class="iref" href="#rfc.xref.RFC2616.2">11</a>, <a class="iref" href="#RFC2616"><b>12</b></a>, <a class="iref" href="#rfc.xref.RFC2616.3">E.1</a></li> 2547 2556 <li class="indline1"><em>RFC3977</em> <a class="iref" href="#rfc.xref.RFC3977.1">1.1</a>, <a class="iref" href="#RFC3977"><b>12</b></a></li> 2548 2557 <li class="indline1"><em>RFC4288</em> <a class="iref" href="#RFC4288"><b>12</b></a>, <a class="iref" href="#rfc.xref.RFC4288.1">A</a></li> -
draft-ietf-httpbis/latest/p1-messaging.xml
r113 r115 17 17 <!ENTITY caching "<xref target='Part6' x:rel='#caching' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 18 18 <!ENTITY payload "<xref target='Part3' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 19 <!ENTITY media-types "<xref target='Part3' x:rel='#media.types' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 20 <!ENTITY content-codings "<xref target='Part3' x:rel='#content.codings' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 19 21 <!ENTITY CONNECT "<xref target='Part2' x:rel='#CONNECT' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 20 22 <!ENTITY content.negotiation "<xref target='Part3' x:rel='#content.negotiation' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> … … 208 210 <note title="Editorial Note (To be removed by RFC Editor)"> 209 211 <t> 210 This version of the HTTP specification contains only minimal editorial211 changes from <xref target="RFC2616"/> (abstract, introductory paragraph,212 and authors' addresses). All other changes are due to partitioning the213 original into seven mostly independent parts. The intent is for readers214 of future drafts to able to use draft 00 as the basis for comparison215 when the WG makes later changes to the specification text. This draft216 will shortly be followed by draft 01 (containing the first round of changes217 that have already been agreed to on the mailing list). There is no point in218 reviewing this draft other than to verify that the partitioning has been219 done correctly. Roy T. Fielding, Yves Lafon, and Julian Reschke220 will be the editors after draft 00 is submitted.221 </t>222 <t>223 212 Discussion of this draft should take place on the HTTPBIS working group 224 213 mailing list (ietf-http-wg@w3.org). The current issues list is … … 847 836 protocol elements except the entity-body (see <xref target="tolerant.applications"/> for 848 837 tolerant applications). The end-of-line marker within an entity-body 849 is defined by its associated media type, as described in & payload;.838 is defined by its associated media type, as described in &media-types;. 850 839 </t> 851 840 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="CRLF"/> … … 1208 1197 transfer-coding value tokens. Initially, the registry contains the 1209 1198 following tokens: "chunked" (<xref target="chunked.transfer.encoding"/>), 1210 "gzip" (&payload;), "compress" (&payload;), and "deflate" (&payload;).1199 "gzip", "compress", and "deflate" (&content-codings;). 1211 1200 </t> 1212 1201 <t> 1213 1202 New transfer-coding value tokens &SHOULD; be registered in the same way 1214 as new content-coding value tokens (& payload;).1203 as new content-coding value tokens (&content-codings;). 1215 1204 </t> 1216 1205 <t> … … 2902 2891 </t> 2903 2892 <t> 2904 Jim Gettys (the current editor of this document) wishes particularly2905 to thank Roy Fielding, the previous editor of this document, along2893 Jim Gettys (the editor of <xref target="RFC2616"/>) wishes particularly 2894 to thank Roy Fielding, the editor of <xref target="RFC2068"/>, along 2906 2895 with John Klensin, Jeff Mogul, Paul Leach, Dave Kristol, Koen 2907 2896 Holtman, John Franks, Josh Cohen, Alex Hopmann, Scott Lawrence, and … … 3984 3973 </t> 3985 3974 </section> 3986 3987 </section> 3975 </section> 3976 3977 <section title="Change Log (to be removed by RFC Editor before publication)"> 3978 3979 <section title="Since RFC2616"> 3980 <t> 3981 Extracted relevant partitions from <xref target="RFC2616"/>. 3982 </t> 3983 </section> 3984 3985 <section title="Since draft-ietf-httpbis-p1-messaging-00"> 3986 <t> 3987 TBD. 3988 </t> 3989 </section> 3990 3991 </section> 3992 3988 3993 </back> 3989 3994 </rfc> -
draft-ietf-httpbis/latest/p2-semantics.html
r114 r115 347 347 <link rel="Chapter" href="#rfc.section.14" title="14 References"> 348 348 <link rel="Appendix" title="A Compatibility with Previous Versions" href="#rfc.section.A"> 349 <link rel="Appendix" title="B Change Log (to be removed by RFC Editor before publication)" href="#rfc.section.B"> 349 350 <meta name="generator" content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.353, 2007/12/11 23:20:44, XSLT vendor: SAXON 8.9 from Saxonica http://www.saxonica.com/"> 350 351 <link rel="schema.DC" href="http://purl.org/dc/elements/1.1/"> … … 476 477 </p> 477 478 <h1 id="rfc.note.1"><a href="#rfc.note.1">Editorial Note (To be removed by RFC Editor)</a></h1> 478 <p>This version of the HTTP specification contains only minimal editorial changes from <a href="#RFC2616" id="rfc.xref.RFC2616.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a> (abstract, introductory paragraph, and authors' addresses). All other changes are due to partitioning the original into seven479 mostly independent parts. The intent is for readers of future drafts to able to use draft 00 as the basis for comparison when480 the WG makes later changes to the specification text. This draft will shortly be followed by draft 01 (containing the first481 round of changes that have already been agreed to on the mailing list). There is no point in reviewing this draft other than482 to verify that the partitioning has been done correctly. Roy T. Fielding, Yves Lafon, and Julian Reschke will be the editors483 after draft 00 is submitted.484 </p>485 479 <p>Discussion of this draft should take place on the HTTPBIS working group mailing list (ietf-http-wg@w3.org). The current issues 486 480 list is at <<a href="http://www.tools.ietf.org/wg/httpbis/trac/report/11">http://www.tools.ietf.org/wg/httpbis/trac/report/11</a>> and related documents (including fancy diffs) can be found at <<a href="http://www.tools.ietf.org/wg/httpbis/">http://www.tools.ietf.org/wg/httpbis/</a>>. … … 601 595 </ul> 602 596 </li> 597 <li class="tocline0">B. <a href="#rfc.section.B">Change Log (to be removed by RFC Editor before publication)</a><ul class="toc"> 598 <li class="tocline1">B.1 <a href="#rfc.section.B.1">Since RFC2616</a></li> 599 <li class="tocline1">B.2 <a href="#rfc.section.B.2">Since draft-ietf-httpbis-p2-semantics-00</a></li> 600 </ul> 601 </li> 603 602 <li class="tocline0"><a href="#rfc.ipr">Intellectual Property and Copyright Statements</a></li> 604 603 <li class="tocline0"><a href="#rfc.index">Index</a></li> … … 1678 1677 in the description of the Via header in <a href="p1-messaging.html#header.via" title="Via">Section 8.9</a> of <a href="#Part1" id="rfc.xref.Part1.12"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. (<a href="#header.server" id="rfc.xref.header.server.3" title="Server">Section 10.8</a>) 1679 1678 </p> 1679 <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a> Change Log (to be removed by RFC Editor before publication) 1680 </h1> 1681 <h2 id="rfc.section.B.1"><a href="#rfc.section.B.1">B.1</a> Since RFC2616 1682 </h2> 1683 <p id="rfc.section.B.1.p.1">Extracted relevant partitions from <a href="#RFC2616" id="rfc.xref.RFC2616.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>. 1684 </p> 1685 <h2 id="rfc.section.B.2"><a href="#rfc.section.B.2">B.2</a> Since draft-ietf-httpbis-p2-semantics-00 1686 </h2> 1687 <p id="rfc.section.B.2.p.1">TBD.</p> 1680 1688 <h1><a id="rfc.copyright" href="#rfc.copyright">Full Copyright Statement</a></h1> 1681 1689 <p>Copyright © The IETF Trust (2007).</p> … … 1920 1928 <li class="indline1"><em>RFC2068</em> <a class="iref" href="#rfc.xref.RFC2068.1">9.3.3</a>, <a class="iref" href="#rfc.xref.RFC2068.2">9.3.6</a>, <a class="iref" href="#RFC2068"><b>14</b></a>, <a class="iref" href="#rfc.xref.RFC2068.3">A.1</a></li> 1921 1929 <li class="indline1"><em>RFC2119</em> <a class="iref" href="#rfc.xref.RFC2119.1">1.1</a>, <a class="iref" href="#RFC2119"><b>14</b></a></li> 1922 <li class="indline1"><em>RFC2616</em> <a class="iref" href="# rfc.xref.RFC2616.1">§</a>, <a class="iref" href="#RFC2616"><b>14</b></a></li>1930 <li class="indline1"><em>RFC2616</em> <a class="iref" href="#RFC2616"><b>14</b></a>, <a class="iref" href="#rfc.xref.RFC2616.1">B.1</a></li> 1923 1931 <li class="indline1"><em>RFC822</em> <a class="iref" href="#rfc.xref.RFC822.1">10.3</a>, <a class="iref" href="#RFC822"><b>14</b></a></li> 1924 1932 </ul> -
draft-ietf-httpbis/latest/p2-semantics.xml
r114 r115 229 229 <note title="Editorial Note (To be removed by RFC Editor)"> 230 230 <t> 231 This version of the HTTP specification contains only minimal editorial232 changes from <xref target="RFC2616"/> (abstract, introductory paragraph,233 and authors' addresses). All other changes are due to partitioning the234 original into seven mostly independent parts. The intent is for readers235 of future drafts to able to use draft 00 as the basis for comparison236 when the WG makes later changes to the specification text. This draft237 will shortly be followed by draft 01 (containing the first round of changes238 that have already been agreed to on the mailing list). There is no point in239 reviewing this draft other than to verify that the partitioning has been240 done correctly. Roy T. Fielding, Yves Lafon, and Julian Reschke241 will be the editors after draft 00 is submitted.242 </t>243 <t>244 231 Discussion of this draft should take place on the HTTPBIS working group 245 232 mailing list (ietf-http-wg@w3.org). The current issues list is … … 2588 2575 </section> 2589 2576 2577 <section title="Change Log (to be removed by RFC Editor before publication)"> 2578 2579 <section title="Since RFC2616"> 2580 <t> 2581 Extracted relevant partitions from <xref target="RFC2616"/>. 2582 </t> 2583 </section> 2584 2585 <section title="Since draft-ietf-httpbis-p2-semantics-00"> 2586 <t> 2587 TBD. 2588 </t> 2589 </section> 2590 2591 </section> 2592 2590 2593 </back> 2591 2594 </rfc> -
draft-ietf-httpbis/latest/p3-payload.html
r113 r115 344 344 <link rel="Appendix" title="B Additional Features" href="#rfc.section.B"> 345 345 <link rel="Appendix" title="C Compatibility with Previous Versions" href="#rfc.section.C"> 346 <link rel="Appendix" title="D Change Log (to be removed by RFC Editor before publication)" href="#rfc.section.D"> 346 347 <meta name="generator" content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.353, 2007/12/11 23:20:44, XSLT vendor: SAXON 8.9 from Saxonica http://www.saxonica.com/"> 347 348 <link rel="schema.DC" href="http://purl.org/dc/elements/1.1/"> … … 472 473 </p> 473 474 <h1 id="rfc.note.1"><a href="#rfc.note.1">Editorial Note (To be removed by RFC Editor)</a></h1> 474 <p>This version of the HTTP specification contains only minimal editorial changes from <a href="#RFC2616" id="rfc.xref.RFC2616.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a> (abstract, introductory paragraph, and authors' addresses). All other changes are due to partitioning the original into seven475 mostly independent parts. The intent is for readers of future drafts to able to use draft 00 as the basis for comparison when476 the WG makes later changes to the specification text. This draft will shortly be followed by draft 01 (containing the first477 round of changes that have already been agreed to on the mailing list). There is no point in reviewing this draft other than478 to verify that the partitioning has been done correctly. Roy T. Fielding, Yves Lafon, and Julian Reschke will be the editors479 after draft 00 is submitted.480 </p>481 475 <p>Discussion of this draft should take place on the HTTPBIS working group mailing list (ietf-http-wg@w3.org). The current issues 482 476 list is at <<a href="http://www.tools.ietf.org/wg/httpbis/trac/report/11">http://www.tools.ietf.org/wg/httpbis/trac/report/11</a>> and related documents (including fancy diffs) can be found at <<a href="http://www.tools.ietf.org/wg/httpbis/">http://www.tools.ietf.org/wg/httpbis/</a>>. … … 558 552 </ul> 559 553 </li> 554 <li class="tocline0">D. <a href="#rfc.section.D">Change Log (to be removed by RFC Editor before publication)</a><ul class="toc"> 555 <li class="tocline1">D.1 <a href="#rfc.section.D.1">Since RFC2616</a></li> 556 <li class="tocline1">D.2 <a href="#rfc.section.D.2">Since draft-ietf-httpbis-p3-payload-00</a></li> 557 </ul> 558 </li> 560 559 <li class="tocline0"><a href="#rfc.ipr">Intellectual Property and Copyright Statements</a></li> 561 560 <li class="tocline0"><a href="#rfc.index">Index</a></li> … … 596 595 </p> 597 596 <p id="rfc.section.2.1.p.7">HTTP uses charset in two contexts: within an Accept-Charset request header (in which the charset value is an unquoted token) 598 and as the value of a parameter in a Content- type header (within a request or response), in which case the parameter value597 and as the value of a parameter in a Content-Type header (within a request or response), in which case the parameter value 599 598 of the charset parameter may be quoted. 600 599 </p> … … 674 673 </p> 675 674 <p id="rfc.section.2.3.p.7">Media-type values are registered with the Internet Assigned Number Authority (IANA). The media type registration process is 676 outlined in RFC 4288<a href="#RFC4288" id="rfc.xref.RFC4288.2"><cite title="Media Type Specifications and Registration Procedures">[RFC4288]</cite></a>. Use of non-registered media types is discouraged.675 outlined in <a href="#RFC4288" id="rfc.xref.RFC4288.2"><cite title="Media Type Specifications and Registration Procedures">[RFC4288]</cite></a>. Use of non-registered media types is discouraged. 677 676 </p> 678 677 <h3 id="rfc.section.2.3.1"><a href="#rfc.section.2.3.1">2.3.1</a> <a id="canonicalization.and.text.defaults" href="#canonicalization.and.text.defaults">Canonicalization and Text Defaults</a></h3> … … 832 831 header fields not defined by this specification. 833 832 </p> 834 <p id="rfc.section.4.1.p.5">The Vary header field <a href="#Part6" id="rfc.xref.Part6.2"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>can be used to express the parameters the server uses to select a representation that is subject to server-driven negotiation.833 <p id="rfc.section.4.1.p.5">The Vary header field (<a href="p6-cache.html#header.vary" title="Vary">Section 3.5</a> of <a href="#Part6" id="rfc.xref.Part6.2"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) can be used to express the parameters the server uses to select a representation that is subject to server-driven negotiation. 835 834 </p> 836 835 <h2 id="rfc.section.4.2"><a href="#rfc.section.4.2">4.2</a> <a id="agent-driven.negotiation" href="#agent-driven.negotiation">Agent-driven Negotiation</a></h2> … … 1110 1109 <p id="rfc.section.5.7.p.5">A cache cannot assume that an entity with a Content-Location different from the URI used to retrieve it can be used to respond 1111 1110 to later requests on that Content-Location URI. However, the Content-Location can be used to differentiate between multiple 1112 entities retrieved from a single requested resource, as described in <a href=" #Part6" id="rfc.xref.Part6.3"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>.1111 entities retrieved from a single requested resource, as described in <a href="p6-cache.html#caching.negotiated.responses" title="Caching Negotiated Responses">Section 2.6</a> of <a href="#Part6" id="rfc.xref.Part6.3"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>. 1113 1112 </p> 1114 1113 <p id="rfc.section.5.7.p.6">If the Content-Location is a relative URI, the relative URI is interpreted relative to the Request-URI.</p> … … 1122 1121 </p> 1123 1122 <div id="rfc.figure.u.30"></div><pre class="inline"><span id="rfc.iref.g.29"></span><span id="rfc.iref.g.30"></span> Content-MD5 = "Content-MD5" ":" md5-digest 1124 md5-digest = <base64 of 128 bit MD5 digest as per RFC 1864>1123 md5-digest = <base64 of 128 bit MD5 digest as per <a href="#RFC1864" id="rfc.xref.RFC1864.2"><cite title="The Content-MD5 Header Field">[RFC1864]</cite></a>> 1125 1124 </pre><p id="rfc.section.5.8.p.3">The Content-MD5 header field <em class="bcp14">MAY</em> be generated by an origin server or client to function as an integrity check of the entity-body. Only origin servers or clients <em class="bcp14">MAY</em> generate the Content-MD5 header field; proxies and gateways <em class="bcp14">MUST NOT</em> generate it, as this would defeat its value as an end-to-end integrity check. Any recipient of the entity-body, including 1126 1125 gateways and proxies, <em class="bcp14">MAY</em> check that the digest value in this header field matches that of the entity-body as received. … … 1357 1356 <p id="rfc.section.A.1.p.1">HTTP is not a MIME-compliant protocol. However, HTTP/1.1 messages <em class="bcp14">MAY</em> include a single MIME-Version general-header field to indicate what version of the MIME protocol was used to construct the 1358 1357 message. Use of the MIME-Version header field indicates that the message is in full compliance with the MIME protocol (as 1359 defined in RFC 2045<a href="#RFC2045" id="rfc.xref.RFC2045.2"><cite title="Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies">[RFC2045]</cite></a>). Proxies/gateways are responsible for ensuring full compliance (where possible) when exporting HTTP messages to strict MIME1358 defined in <a href="#RFC2045" id="rfc.xref.RFC2045.2"><cite title="Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies">[RFC2045]</cite></a>). Proxies/gateways are responsible for ensuring full compliance (where possible) when exporting HTTP messages to strict MIME 1360 1359 environments. 1361 1360 </p> … … 1365 1364 </p> 1366 1365 <h2 id="rfc.section.A.2"><a href="#rfc.section.A.2">A.2</a> <a id="conversion.to.canonical.form" href="#conversion.to.canonical.form">Conversion to Canonical Form</a></h2> 1367 <p id="rfc.section.A.2.p.1"> <a href="#RFC2045" id="rfc.xref.RFC2045.3"><cite title="Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies">[RFC2045]</cite></a> requires that an Internet mail entity be converted to canonical form prior to being transferred, as described in section<a href="http://tools.ietf.org/html/rfc2049#section-4">Section 4</a> of <a href="#RFC2049" id="rfc.xref.RFC2049.1"><cite title="Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples">[RFC2049]</cite></a>. <a href="#canonicalization.and.text.defaults" title="Canonicalization and Text Defaults">Section 2.3.1</a> of this document describes the forms allowed for subtypes of the "text" media type when transmitted over HTTP. <a href="#RFC2046" id="rfc.xref.RFC2046.2"><cite title="Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types">[RFC2046]</cite></a> requires that content with a type of "text" represent line breaks as CRLF and forbids the use of CR or LF outside of line1366 <p id="rfc.section.A.2.p.1"> <a href="#RFC2045" id="rfc.xref.RFC2045.3"><cite title="Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies">[RFC2045]</cite></a> requires that an Internet mail entity be converted to canonical form prior to being transferred, as described in <a href="http://tools.ietf.org/html/rfc2049#section-4">Section 4</a> of <a href="#RFC2049" id="rfc.xref.RFC2049.1"><cite title="Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples">[RFC2049]</cite></a>. <a href="#canonicalization.and.text.defaults" title="Canonicalization and Text Defaults">Section 2.3.1</a> of this document describes the forms allowed for subtypes of the "text" media type when transmitted over HTTP. <a href="#RFC2046" id="rfc.xref.RFC2046.2"><cite title="Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types">[RFC2046]</cite></a> requires that content with a type of "text" represent line breaks as CRLF and forbids the use of CR or LF outside of line 1368 1367 break sequences. HTTP allows CRLF, bare CR, and bare LF to indicate a line break within text content when a message is transmitted 1369 1368 over HTTP. … … 1449 1448 <p id="rfc.section.C.2.p.2">Remove reference to non-existant identity transfer-coding value tokens. (<a href="#no.content-transfer-encoding" title="No Content-Transfer-Encoding">Appendix A.4</a>) 1450 1449 </p> 1450 <h1 id="rfc.section.D"><a href="#rfc.section.D">D.</a> Change Log (to be removed by RFC Editor before publication) 1451 </h1> 1452 <h2 id="rfc.section.D.1"><a href="#rfc.section.D.1">D.1</a> Since RFC2616 1453 </h2> 1454 <p id="rfc.section.D.1.p.1">Extracted relevant partitions from <a href="#RFC2616" id="rfc.xref.RFC2616.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>. 1455 </p> 1456 <h2 id="rfc.section.D.2"><a href="#rfc.section.D.2">D.2</a> Since draft-ietf-httpbis-p3-payload-00 1457 </h2> 1458 <p id="rfc.section.D.2.p.1">TBD.</p> 1451 1459 <h1><a id="rfc.copyright" href="#rfc.copyright">Full Copyright Statement</a></h1> 1452 1460 <p>Copyright © The IETF Trust (2007).</p> … … 1606 1614 </li> 1607 1615 <li class="indline1"><em>Part6</em> <a class="iref" href="#rfc.xref.Part6.1">3.1</a>, <a class="iref" href="#rfc.xref.Part6.2">4.1</a>, <a class="iref" href="#rfc.xref.Part6.3">5.7</a>, <a class="iref" href="#Part6"><b>9</b></a><ul class="ind"> 1616 <li class="indline1"><em>Section 2.6</em> <a class="iref" href="#rfc.xref.Part6.3">5.7</a></li> 1608 1617 <li class="indline1"><em>Section 3.3</em> <a class="iref" href="#rfc.xref.Part6.1">3.1</a></li> 1618 <li class="indline1"><em>Section 3.5</em> <a class="iref" href="#rfc.xref.Part6.2">4.1</a></li> 1609 1619 </ul> 1610 1620 </li> … … 1615 1625 <li class="indline1"><em>RFC1766</em> <a class="iref" href="#rfc.xref.RFC1766.1">2.5</a>, <a class="iref" href="#RFC1766"><b>9</b></a></li> 1616 1626 <li class="indline1"><em>RFC1806</em> <a class="iref" href="#rfc.xref.RFC1806.1">7.2</a>, <a class="iref" href="#rfc.xref.RFC1806.2">7.2</a>, <a class="iref" href="#RFC1806"><b>9</b></a>, <a class="iref" href="#rfc.xref.RFC1806.3">B.1</a></li> 1617 <li class="indline1"><em>RFC1864</em> <a class="iref" href="#rfc.xref.RFC1864.1">5.8</a>, <a class="iref" href="# RFC1864"><b>9</b></a></li>1627 <li class="indline1"><em>RFC1864</em> <a class="iref" href="#rfc.xref.RFC1864.1">5.8</a>, <a class="iref" href="#rfc.xref.RFC1864.2">5.8</a>, <a class="iref" href="#RFC1864"><b>9</b></a></li> 1618 1628 <li class="indline1"><em>RFC1867</em> <a class="iref" href="#rfc.xref.RFC1867.1">2.3.2</a>, <a class="iref" href="#RFC1867"><b>9</b></a></li> 1619 1629 <li class="indline1"><em>RFC1945</em> <a class="iref" href="#RFC1945"><b>9</b></a>, <a class="iref" href="#rfc.xref.RFC1945.1">B</a></li> … … 1637 1647 <li class="indline1"><em>RFC2277</em> <a class="iref" href="#rfc.xref.RFC2277.1">2.1</a>, <a class="iref" href="#RFC2277"><b>9</b></a></li> 1638 1648 <li class="indline1"><em>RFC2279</em> <a class="iref" href="#rfc.xref.RFC2279.1">2.1</a>, <a class="iref" href="#RFC2279"><b>9</b></a></li> 1639 <li class="indline1"><em>RFC2616</em> <a class="iref" href="# rfc.xref.RFC2616.1">§</a>, <a class="iref" href="#RFC2616"><b>9</b></a></li>1649 <li class="indline1"><em>RFC2616</em> <a class="iref" href="#RFC2616"><b>9</b></a>, <a class="iref" href="#rfc.xref.RFC2616.1">D.1</a></li> 1640 1650 <li class="indline1"><em>RFC4288</em> <a class="iref" href="#rfc.xref.RFC4288.1">2.3</a>, <a class="iref" href="#rfc.xref.RFC4288.2">2.3</a>, <a class="iref" href="#RFC4288"><b>9</b></a></li> 1641 1651 <li class="indline1"><em>RFC822</em> <a class="iref" href="#RFC822"><b>9</b></a>, <a class="iref" href="#rfc.xref.RFC822.1">A</a></li> -
draft-ietf-httpbis/latest/p3-payload.xml
r113 r115 15 15 <!ENTITY ID-MONTH "December"> 16 16 <!ENTITY ID-YEAR "2007"> 17 <!ENTITY caching "<xref target='Part6' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">17 <!ENTITY caching-neg-resp "<xref target='Part6' x:rel='#caching.negotiated.responses' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 18 18 <!ENTITY header-transfer-encoding "<xref target='Part1' x:rel='#header.transfer-encoding' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 19 19 <!ENTITY header-allow "<xref target='Part2' x:rel='#header.allow' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> … … 23 23 <!ENTITY header-last-modified "<xref target='Part4' x:rel='#header.last-modified' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 24 24 <!ENTITY header-user-agent "<xref target='Part2' x:rel='#header.user-agent' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 25 <!ENTITY header-vary "<xref target='Part6' x:rel='#header.vary' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 25 26 <!ENTITY message-body "<xref target='Part1' x:rel='#message.body' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 26 27 <!ENTITY message-length "<xref target='Part1' x:rel='#message.length' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> … … 196 197 <note title="Editorial Note (To be removed by RFC Editor)"> 197 198 <t> 198 This version of the HTTP specification contains only minimal editorial199 changes from <xref target="RFC2616"/> (abstract, introductory paragraph,200 and authors' addresses). All other changes are due to partitioning the201 original into seven mostly independent parts. The intent is for readers202 of future drafts to able to use draft 00 as the basis for comparison203 when the WG makes later changes to the specification text. This draft204 will shortly be followed by draft 01 (containing the first round of changes205 that have already been agreed to on the mailing list). There is no point in206 reviewing this draft other than to verify that the partitioning has been207 done correctly. Roy T. Fielding, Yves Lafon, and Julian Reschke208 will be the editors after draft 00 is submitted.209 </t>210 <t>211 199 Discussion of this draft should take place on the HTTPBIS working group 212 200 mailing list (ietf-http-wg@w3.org). The current issues list is … … 290 278 HTTP uses charset in two contexts: within an Accept-Charset request 291 279 header (in which the charset value is an unquoted token) and as the 292 value of a parameter in a Content- type header (within a request or280 value of a parameter in a Content-Type header (within a request or 293 281 response), in which case the parameter value of the charset parameter 294 282 may be quoted. … … 432 420 Media-type values are registered with the Internet Assigned Number 433 421 Authority (IANA). The media type registration process is 434 outlined in RFC 4288<xref target="RFC4288"/>. Use of non-registered media types is422 outlined in <xref target="RFC4288"/>. Use of non-registered media types is 435 423 discouraged. 436 424 </t> … … 760 748 </t> 761 749 <t> 762 The Vary header field &caching;can be used to express the parameters the750 The Vary header field (&header-vary;) can be used to express the parameters the 763 751 server uses to select a representation that is subject to server-driven 764 752 negotiation. … … 1278 1266 later requests on that Content-Location URI. However, the Content-Location 1279 1267 can be used to differentiate between multiple entities 1280 retrieved from a single requested resource, as described in &caching ;.1268 retrieved from a single requested resource, as described in &caching-neg-resp;. 1281 1269 </t> 1282 1270 <t> … … 1302 1290 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Content-MD5"/><iref primary="true" item="Grammar" subitem="md5-digest"/> 1303 1291 Content-MD5 = "Content-MD5" ":" md5-digest 1304 md5-digest = <base64 of 128 bit MD5 digest as per RFC 1864>1292 md5-digest = <base64 of 128 bit MD5 digest as per <xref target="RFC1864"/>> 1305 1293 </artwork></figure> 1306 1294 <t> … … 2113 2101 version of the MIME protocol was used to construct the message. Use 2114 2102 of the MIME-Version header field indicates that the message is in 2115 full compliance with the MIME protocol (as defined in RFC 2045<xref target="RFC2045"/>).2103 full compliance with the MIME protocol (as defined in <xref target="RFC2045"/>). 2116 2104 Proxies/gateways are responsible for ensuring full compliance (where 2117 2105 possible) when exporting HTTP messages to strict MIME environments. … … 2130 2118 <t> 2131 2119 <xref target="RFC2045"/> requires that an Internet mail entity be converted to 2132 canonical form prior to being transferred, as described in section<xref target="RFC2049" x:fmt="of" x:sec="4"/>.2120 canonical form prior to being transferred, as described in <xref target="RFC2049" x:fmt="of" x:sec="4"/>. 2133 2121 <xref target="canonicalization.and.text.defaults"/> of this document describes the forms 2134 2122 allowed for subtypes of the "text" media type when transmitted over … … 2309 2297 </section> 2310 2298 2299 <section title="Change Log (to be removed by RFC Editor before publication)"> 2300 2301 <section title="Since RFC2616"> 2302 <t> 2303 Extracted relevant partitions from <xref target="RFC2616"/>. 2304 </t> 2305 </section> 2306 2307 <section title="Since draft-ietf-httpbis-p3-payload-00"> 2308 <t> 2309 TBD. 2310 </t> 2311 </section> 2312 2313 </section> 2314 2311 2315 </back> 2312 2316 </rfc> -
draft-ietf-httpbis/latest/p4-conditional.html
r113 r115 343 343 <link rel="Chapter" href="#rfc.section.10" title="10 References"> 344 344 <link rel="Appendix" title="A Compatibility with Previous Versions" href="#rfc.section.A"> 345 <link rel="Appendix" title="B Change Log (to be removed by RFC Editor before publication)" href="#rfc.section.B"> 345 346 <meta name="generator" content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.353, 2007/12/11 23:20:44, XSLT vendor: SAXON 8.9 from Saxonica http://www.saxonica.com/"> 346 347 <link rel="schema.DC" href="http://purl.org/dc/elements/1.1/"> … … 471 472 </p> 472 473 <h1 id="rfc.note.1"><a href="#rfc.note.1">Editorial Note (To be removed by RFC Editor)</a></h1> 473 <p>This version of the HTTP specification contains only minimal editorial changes from <a href="#RFC2616" id="rfc.xref.RFC2616.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a> (abstract, introductory paragraph, and authors' addresses). All other changes are due to partitioning the original into seven474 mostly independent parts. The intent is for readers of future drafts to able to use draft 00 as the basis for comparison when475 the WG makes later changes to the specification text. This draft will shortly be followed by draft 01 (containing the first476 round of changes that have already been agreed to on the mailing list). There is no point in reviewing this draft other than477 to verify that the partitioning has been done correctly. Roy T. Fielding, Yves Lafon, and Julian Reschke will be the editors478 after draft 00 is submitted.479 </p>480 474 <p>Discussion of this draft should take place on the HTTPBIS working group mailing list (ietf-http-wg@w3.org). The current issues 481 475 list is at <<a href="http://www.tools.ietf.org/wg/httpbis/trac/report/11">http://www.tools.ietf.org/wg/httpbis/trac/report/11</a>> and related documents (including fancy diffs) can be found at <<a href="http://www.tools.ietf.org/wg/httpbis/">http://www.tools.ietf.org/wg/httpbis/</a>>. … … 514 508 </ul> 515 509 </li> 510 <li class="tocline0">B. <a href="#rfc.section.B">Change Log (to be removed by RFC Editor before publication)</a><ul class="toc"> 511 <li class="tocline1">B.1 <a href="#rfc.section.B.1">Since RFC2616</a></li> 512 <li class="tocline1">B.2 <a href="#rfc.section.B.2">Since draft-ietf-httpbis-p4-conditional-00</a></li> 513 </ul> 514 </li> 516 515 <li class="tocline0"><a href="#rfc.ipr">Intellectual Property and Copyright Statements</a></li> 517 516 <li class="tocline0"><a href="#rfc.index">Index</a></li> … … 519 518 <h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a> <a id="introduction" href="#introduction">Introduction</a></h1> 520 519 <p id="rfc.section.1.p.1">This document will define aspects of HTTP related to conditional request messages based on time stamps and entity-tags. Right 521 now it only includes the extracted relevant sections of <a href="#RFC2616">RFC 2616</a> <cite title="Hypertext Transfer Protocol -- HTTP/1.1" id="rfc.xref.RFC2616. 2">[RFC2616]</cite> without edit.520 now it only includes the extracted relevant sections of <a href="#RFC2616">RFC 2616</a> <cite title="Hypertext Transfer Protocol -- HTTP/1.1" id="rfc.xref.RFC2616.1">[RFC2616]</cite> without edit. 522 521 </p> 523 522 <h2 id="rfc.section.1.1"><a href="#rfc.section.1.1">1.1</a> <a id="intro.requirements" href="#intro.requirements">Requirements</a></h2> … … 563 562 </li> 564 563 </ul> 565 <p id="rfc.section.3.1.p.4">If the conditional GET used a strong cache validator (see <a href="# Part6" id="rfc.xref.Part6.1"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>), the response <em class="bcp14">SHOULD NOT</em> include other entity-headers. Otherwise (i.e., the conditional GET used a weak validator), the response <em class="bcp14">MUST NOT</em> include other entity-headers; this prevents inconsistencies between cached entity-bodies and updated headers.564 <p id="rfc.section.3.1.p.4">If the conditional GET used a strong cache validator (see <a href="#weak.and.strong.validators" title="Weak and Strong Validators">Section 4</a>), the response <em class="bcp14">SHOULD NOT</em> include other entity-headers. Otherwise (i.e., the conditional GET used a weak validator), the response <em class="bcp14">MUST NOT</em> include other entity-headers; this prevents inconsistencies between cached entity-bodies and updated headers. 566 565 </p> 567 566 <p id="rfc.section.3.1.p.5">If a 304 response indicates an entity not currently cached, then the cache <em class="bcp14">MUST</em> disregard the response and repeat the request without the conditional. … … 723 722 <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> 724 723 <p id="rfc.section.6.1.p.1">The ETag response-header field provides the current value of the entity tag for the requested variant. The headers used with 725 entity tags are described in Sections <a href="#header.if-match" id="rfc.xref.header.if-match.2" title="If-Match">6.2</a> , <a href="#header.if-none-match" id="rfc.xref.header.if-none-match.2" title="If-None-Match">6.4</a> and<a href="p5-range.html#header.if-range" title="If-Range">Section 5.3</a> of <a href="#Part5" id="rfc.xref.Part5.2"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>. The entity tag <em class="bcp14">MAY</em> be used for comparison with other entities from the same resource (see <a href="#weak.and.strong.validators" title="Weak and Strong Validators">Section 4</a>).724 entity tags are described in Sections <a href="#header.if-match" id="rfc.xref.header.if-match.2" title="If-Match">6.2</a> and <a href="#header.if-none-match" id="rfc.xref.header.if-none-match.2" title="If-None-Match">6.4</a> of this document, and in <a href="p5-range.html#header.if-range" title="If-Range">Section 5.3</a> of <a href="#Part5" id="rfc.xref.Part5.2"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>. The entity tag <em class="bcp14">MAY</em> be used for comparison with other entities from the same resource (see <a href="#weak.and.strong.validators" title="Weak and Strong Validators">Section 4</a>). 726 725 </p> 727 726 <div id="rfc.figure.u.2"></div><pre class="inline"><span id="rfc.iref.g.4"></span> ETag = "ETag" ":" entity-tag … … 752 751 header <em class="bcp14">MUST</em> be ignored. 753 752 </p> 754 <p id="rfc.section.6.2.p.7">The meaning of "If-Match: *" is that the method <em class="bcp14">SHOULD</em> be performed if the representation selected by the origin server (or by a cache, possibly using the Vary mechanism, see <a href="p6-cache.html#header.vary" title="Vary">Section 3.5</a> of <a href="#Part6" id="rfc.xref.Part6. 2"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) exists, and <em class="bcp14">MUST NOT</em> be performed if the representation does not exist.753 <p id="rfc.section.6.2.p.7">The meaning of "If-Match: *" is that the method <em class="bcp14">SHOULD</em> be performed if the representation selected by the origin server (or by a cache, possibly using the Vary mechanism, see <a href="p6-cache.html#header.vary" title="Vary">Section 3.5</a> of <a href="#Part6" id="rfc.xref.Part6.1"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) exists, and <em class="bcp14">MUST NOT</em> be performed if the representation does not exist. 755 754 </p> 756 755 <p id="rfc.section.6.2.p.8">A request intended to update a resource (e.g., a PUT) <em class="bcp14">MAY</em> include an If-Match header field to signal that the request method <em class="bcp14">MUST NOT</em> be applied if the entity corresponding to the If-Match value (a single entity tag) is no longer a representation of that resource. … … 833 832 If-None-Match header <em class="bcp14">MUST</em> be ignored. (See <a href="#rules.for.when.to.use.entity.tags.and.last-modified.dates" title="Rules for When to Use Entity Tags and Last-Modified Dates">Section 5</a> for a discussion of server behavior when both If-Modified-Since and If-None-Match appear in the same request.) 834 833 </p> 835 <p id="rfc.section.6.4.p.8">The meaning of "If-None-Match: *" is that the method <em class="bcp14">MUST NOT</em> be performed if the representation selected by the origin server (or by a cache, possibly using the Vary mechanism, see <a href="p6-cache.html#header.vary" title="Vary">Section 3.5</a> of <a href="#Part6" id="rfc.xref.Part6. 3"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) exists, and <em class="bcp14">SHOULD</em> be performed if the representation does not exist. This feature is intended to be useful in preventing races between PUT operations.834 <p id="rfc.section.6.4.p.8">The meaning of "If-None-Match: *" is that the method <em class="bcp14">MUST NOT</em> be performed if the representation selected by the origin server (or by a cache, possibly using the Vary mechanism, see <a href="p6-cache.html#header.vary" title="Vary">Section 3.5</a> of <a href="#Part6" id="rfc.xref.Part6.2"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) exists, and <em class="bcp14">SHOULD</em> be performed if the representation does not exist. This feature is intended to be useful in preventing races between PUT operations. 836 835 </p> 837 836 <p id="rfc.section.6.4.p.9">Examples:</p> … … 943 942 <h1 id="rfc.section.A"><a href="#rfc.section.A">A.</a> <a id="compatibility" href="#compatibility">Compatibility with Previous Versions</a></h1> 944 943 <h2 id="rfc.section.A.1"><a href="#rfc.section.A.1">A.1</a> <a id="changes.from.rfc.2616" href="#changes.from.rfc.2616">Changes from RFC 2616</a></h2> 944 <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a> Change Log (to be removed by RFC Editor before publication) 945 </h1> 946 <h2 id="rfc.section.B.1"><a href="#rfc.section.B.1">B.1</a> Since RFC2616 947 </h2> 948 <p id="rfc.section.B.1.p.1">Extracted relevant partitions from <a href="#RFC2616" id="rfc.xref.RFC2616.2"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>. 949 </p> 950 <h2 id="rfc.section.B.2"><a href="#rfc.section.B.2">B.2</a> Since draft-ietf-httpbis-p4-conditional-00 951 </h2> 952 <p id="rfc.section.B.2.p.1">TBD.</p> 945 953 <h1><a id="rfc.copyright" href="#rfc.copyright">Full Copyright Statement</a></h1> 946 954 <p>Copyright © The IETF Trust (2007).</p> … … 1037 1045 </ul> 1038 1046 </li> 1039 <li class="indline1"><em>Part6</em> <a class="iref" href="#rfc.xref.Part6.1"> 3.1</a>, <a class="iref" href="#rfc.xref.Part6.2">6.2</a>, <a class="iref" href="#rfc.xref.Part6.3">6.4</a>, <a class="iref" href="#Part6"><b>10</b></a><ul class="ind">1040 <li class="indline1"><em>Section 3.5</em> <a class="iref" href="#rfc.xref.Part6. 2">6.2</a>, <a class="iref" href="#rfc.xref.Part6.3">6.4</a></li>1047 <li class="indline1"><em>Part6</em> <a class="iref" href="#rfc.xref.Part6.1">6.2</a>, <a class="iref" href="#rfc.xref.Part6.2">6.4</a>, <a class="iref" href="#Part6"><b>10</b></a><ul class="ind"> 1048 <li class="indline1"><em>Section 3.5</em> <a class="iref" href="#rfc.xref.Part6.1">6.2</a>, <a class="iref" href="#rfc.xref.Part6.2">6.4</a></li> 1041 1049 </ul> 1042 1050 </li> … … 1049 1057 </li> 1050 1058 <li class="indline1"><em>RFC2119</em> <a class="iref" href="#rfc.xref.RFC2119.1">1.1</a>, <a class="iref" href="#RFC2119"><b>10</b></a></li> 1051 <li class="indline1"><em>RFC2616</em> <a class="iref" href="#rfc.xref.RFC2616.1"> §</a>, <a class="iref" href="#rfc.xref.RFC2616.2">1</a>, <a class="iref" href="#RFC2616"><b>10</b></a></li>1059 <li class="indline1"><em>RFC2616</em> <a class="iref" href="#rfc.xref.RFC2616.1">1</a>, <a class="iref" href="#RFC2616"><b>10</b></a>, <a class="iref" href="#rfc.xref.RFC2616.2">B.1</a></li> 1052 1060 </ul> 1053 1061 </li> -
draft-ietf-httpbis/latest/p4-conditional.xml
r113 r115 16 16 <!ENTITY ID-YEAR "2007"> 17 17 <!ENTITY messaging "<xref target='Part1' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 18 <!ENTITY caching "<xref target='Part6' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">19 18 <!ENTITY header-if-range "<xref target='Part5' x:rel='#header.if-range' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 20 19 <!ENTITY header-range "<xref target='Part5' x:rel='#header.range' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> … … 192 191 <note title="Editorial Note (To be removed by RFC Editor)"> 193 192 <t> 194 This version of the HTTP specification contains only minimal editorial195 changes from <xref target="RFC2616"/> (abstract, introductory paragraph,196 and authors' addresses). All other changes are due to partitioning the197 original into seven mostly independent parts. The intent is for readers198 of future drafts to able to use draft 00 as the basis for comparison199 when the WG makes later changes to the specification text. This draft200 will shortly be followed by draft 01 (containing the first round of changes201 that have already been agreed to on the mailing list). There is no point in202 reviewing this draft other than to verify that the partitioning has been203 done correctly. Roy T. Fielding, Yves Lafon, and Julian Reschke204 will be the editors after draft 00 is submitted.205 </t>206 <t>207 193 Discussion of this draft should take place on the HTTPBIS working group 208 194 mailing list (ietf-http-wg@w3.org). The current issues list is … … 306 292 </t> 307 293 <t> 308 If the conditional GET used a strong cache validator (see &caching;),294 If the conditional GET used a strong cache validator (see <xref target="weak.and.strong.validators"/>), 309 295 the response &SHOULD-NOT; include other entity-headers. 310 296 Otherwise (i.e., the conditional GET used a weak validator), the … … 587 573 The ETag response-header field provides the current value of the 588 574 entity tag for the requested variant. The headers used with entity 589 tags are described in Sections <xref target="header.if-match" format="counter"/>, <xref target="header.if-none-match" format="counter"/> and &header-if-range;. The entity tag 575 tags are described in Sections <xref target="header.if-match" format="counter"/> 576 and <xref target="header.if-none-match" format="counter"/> of this document, 577 and in &header-if-range;. The entity tag 590 578 &MAY; be used for comparison with other entities from the same resource 591 579 (see <xref target="weak.and.strong.validators"/>). … … 1167 1155 </section> 1168 1156 1157 <section title="Change Log (to be removed by RFC Editor before publication)"> 1158 1159 <section title="Since RFC2616"> 1160 <t> 1161 Extracted relevant partitions from <xref target="RFC2616"/>. 1162 </t> 1163 </section> 1164 1165 <section title="Since draft-ietf-httpbis-p4-conditional-00"> 1166 <t> 1167 TBD. 1168 </t> 1169 </section> 1170 1171 </section> 1172 1169 1173 </back> 1170 1174 </rfc> -
draft-ietf-httpbis/latest/p5-range.html
r113 r115 343 343 <link rel="Appendix" title="A Internet Media Type multipart/byteranges" href="#rfc.section.A"> 344 344 <link rel="Appendix" title="B Compatibility with Previous Versions" href="#rfc.section.B"> 345 <link rel="Appendix" title="C Change Log (to be removed by RFC Editor before publication)" href="#rfc.section.C"> 345 346 <meta name="generator" content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.353, 2007/12/11 23:20:44, XSLT vendor: SAXON 8.9 from Saxonica http://www.saxonica.com/"> 346 347 <link rel="schema.DC" href="http://purl.org/dc/elements/1.1/"> … … 471 472 </p> 472 473 <h1 id="rfc.note.1"><a href="#rfc.note.1">Editorial Note (To be removed by RFC Editor)</a></h1> 473 <p>This version of the HTTP specification contains only minimal editorial changes from <a href="#RFC2616" id="rfc.xref.RFC2616.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a> (abstract, introductory paragraph, and authors' addresses). All other changes are due to partitioning the original into seven474 mostly independent parts. The intent is for readers of future drafts to able to use draft 00 as the basis for comparison when475 the WG makes later changes to the specification text. This draft will shortly be followed by draft 01 (containing the first476 round of changes that have already been agreed to on the mailing list). There is no point in reviewing this draft other than477 to verify that the partitioning has been done correctly. Roy T. Fielding, Yves Lafon, and Julian Reschke will be the editors478 after draft 00 is submitted.479 </p>480 474 <p>Discussion of this draft should take place on the HTTPBIS working group mailing list (ietf-http-wg@w3.org). The current issues 481 475 list is at <<a href="http://www.tools.ietf.org/wg/httpbis/trac/report/11">http://www.tools.ietf.org/wg/httpbis/trac/report/11</a>> and related documents (including fancy diffs) can be found at <<a href="http://www.tools.ietf.org/wg/httpbis/">http://www.tools.ietf.org/wg/httpbis/</a>>. … … 517 511 </ul> 518 512 </li> 513 <li class="tocline0">C. <a href="#rfc.section.C">Change Log (to be removed by RFC Editor before publication)</a><ul class="toc"> 514 <li class="tocline1">C.1 <a href="#rfc.section.C.1">Since RFC2616</a></li> 515 <li class="tocline1">C.2 <a href="#rfc.section.C.2">Since draft-ietf-httpbis-p5-range-00</a></li> 516 </ul> 517 </li> 519 518 <li class="tocline0"><a href="#rfc.ipr">Intellectual Property and Copyright Statements</a></li> 520 519 <li class="tocline0"><a href="#rfc.index">Index</a></li> … … 522 521 <h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a> <a id="introduction" href="#introduction">Introduction</a></h1> 523 522 <p id="rfc.section.1.p.1">This document will define aspects of HTTP related to range requests, partial responses, and the multipart/byteranges media 524 type. Right now it only includes the extracted relevant sections of <a href="#RFC2616">RFC 2616</a> <cite title="Hypertext Transfer Protocol -- HTTP/1.1" id="rfc.xref.RFC2616. 2">[RFC2616]</cite> without edit.523 type. Right now it only includes the extracted relevant sections of <a href="#RFC2616">RFC 2616</a> <cite title="Hypertext Transfer Protocol -- HTTP/1.1" id="rfc.xref.RFC2616.1">[RFC2616]</cite> without edit. 525 524 </p> 526 525 <h2 id="rfc.section.1.1"><a href="#rfc.section.1.1">1.1</a> <a id="intro.requirements" href="#intro.requirements">Requirements</a></h2> … … 889 888 <p id="rfc.section.B.2.p.1">Clarify that it is not ok to use a weak cache validator in a 206 response. (<a href="#status.206" id="rfc.xref.status.206.1" title="206 Partial Content">Section 3.1</a>) 890 889 </p> 890 <h1 id="rfc.section.C"><a href="#rfc.section.C">C.</a> Change Log (to be removed by RFC Editor before publication) 891 </h1> 892 <h2 id="rfc.section.C.1"><a href="#rfc.section.C.1">C.1</a> Since RFC2616 893 </h2> 894 <p id="rfc.section.C.1.p.1">Extracted relevant partitions from <a href="#RFC2616" id="rfc.xref.RFC2616.2"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>. 895 </p> 896 <h2 id="rfc.section.C.2"><a href="#rfc.section.C.2">C.2</a> Since draft-ietf-httpbis-p5-range-00 897 </h2> 898 <p id="rfc.section.C.2.p.1">TBD.</p> 891 899 <h1><a id="rfc.copyright" href="#rfc.copyright">Full Copyright Statement</a></h1> 892 900 <p>Copyright © The IETF Trust (2007).</p> … … 1002 1010 <li class="indline1"><em>RFC2046</em> <a class="iref" href="#RFC2046"><b>9</b></a>, <a class="iref" href="#rfc.xref.RFC2046.1">A</a></li> 1003 1011 <li class="indline1"><em>RFC2119</em> <a class="iref" href="#rfc.xref.RFC2119.1">1.1</a>, <a class="iref" href="#RFC2119"><b>9</b></a></li> 1004 <li class="indline1"><em>RFC2616</em> <a class="iref" href="#rfc.xref.RFC2616.1"> §</a>, <a class="iref" href="#rfc.xref.RFC2616.2">1</a>, <a class="iref" href="#RFC2616"><b>9</b></a></li>1012 <li class="indline1"><em>RFC2616</em> <a class="iref" href="#rfc.xref.RFC2616.1">1</a>, <a class="iref" href="#RFC2616"><b>9</b></a>, <a class="iref" href="#rfc.xref.RFC2616.2">C.1</a></li> 1005 1013 </ul> 1006 1014 </li> -
draft-ietf-httpbis/latest/p5-range.xml
r113 r115 187 187 <note title="Editorial Note (To be removed by RFC Editor)"> 188 188 <t> 189 This version of the HTTP specification contains only minimal editorial190 changes from <xref target="RFC2616"/> (abstract, introductory paragraph,191 and authors' addresses). All other changes are due to partitioning the192 original into seven mostly independent parts. The intent is for readers193 of future drafts to able to use draft 00 as the basis for comparison194 when the WG makes later changes to the specification text. This draft195 will shortly be followed by draft 01 (containing the first round of changes196 that have already been agreed to on the mailing list). There is no point in197 reviewing this draft other than to verify that the partitioning has been198 done correctly. Roy T. Fielding, Yves Lafon, and Julian Reschke199 will be the editors after draft 00 is submitted.200 </t>201 <t>202 189 Discussion of this draft should take place on the HTTPBIS working group 203 190 mailing list (ietf-http-wg@w3.org). The current issues list is … … 1014 1001 </section> 1015 1002 1003 <section title="Change Log (to be removed by RFC Editor before publication)"> 1004 1005 <section title="Since RFC2616"> 1006 <t> 1007 Extracted relevant partitions from <xref target="RFC2616"/>. 1008 </t> 1009 </section> 1010 1011 <section title="Since draft-ietf-httpbis-p5-range-00"> 1012 <t> 1013 TBD. 1014 </t> 1015 </section> 1016 1017 </section> 1016 1018 1017 1019 </back> -
draft-ietf-httpbis/latest/p6-cache.html
r113 r115 340 340 <link rel="Chapter" href="#rfc.section.7" title="7 References"> 341 341 <link rel="Appendix" title="A Compatibility with Previous Versions" href="#rfc.section.A"> 342 <link rel="Appendix" title="B Change Log (to be removed by RFC Editor before publication)" href="#rfc.section.B"> 342 343 <meta name="generator" content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.353, 2007/12/11 23:20:44, XSLT vendor: SAXON 8.9 from Saxonica http://www.saxonica.com/"> 343 344 <link rel="schema.DC" href="http://purl.org/dc/elements/1.1/"> … … 469 470 </p> 470 471 <h1 id="rfc.note.1"><a href="#rfc.note.1">Editorial Note (To be removed by RFC Editor)</a></h1> 471 <p>This version of the HTTP specification contains only minimal editorial changes from <a href="#RFC2616" id="rfc.xref.RFC2616.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a> (abstract, introductory paragraph, and authors' addresses). All other changes are due to partitioning the original into seven472 mostly independent parts. The intent is for readers of future drafts to able to use draft 00 as the basis for comparison when473 the WG makes later changes to the specification text. This draft will shortly be followed by draft 01 (containing the first474 round of changes that have already been agreed to on the mailing list). There is no point in reviewing this draft other than475 to verify that the partitioning has been done correctly. Roy T. Fielding, Yves Lafon, and Julian Reschke will be the editors476 after draft 00 is submitted.477 </p>478 472 <p>Discussion of this draft should take place on the HTTPBIS working group mailing list (ietf-http-wg@w3.org). The current issues 479 473 list is at <<a href="http://www.tools.ietf.org/wg/httpbis/trac/report/11">http://www.tools.ietf.org/wg/httpbis/trac/report/11</a>> and related documents (including fancy diffs) can be found at <<a href="http://www.tools.ietf.org/wg/httpbis/">http://www.tools.ietf.org/wg/httpbis/</a>>. … … 557 551 </ul> 558 552 </li> 553 <li class="tocline0">B. <a href="#rfc.section.B">Change Log (to be removed by RFC Editor before publication)</a><ul class="toc"> 554 <li class="tocline1">B.1 <a href="#rfc.section.B.1">Since RFC2616</a></li> 555 <li class="tocline1">B.2 <a href="#rfc.section.B.2">Since draft-ietf-httpbis-p6-cache-00</a></li> 556 </ul> 557 </li> 559 558 <li class="tocline0"><a href="#rfc.ipr">Intellectual Property and Copyright Statements</a></li> 560 559 <li class="tocline0"><a href="#rfc.index">Index</a></li> … … 562 561 <h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a> <a id="introduction" href="#introduction">Introduction</a></h1> 563 562 <p id="rfc.section.1.p.1">This document will define aspects of HTTP related to caching response messages. Right now it only includes the extracted relevant 564 sections of <cite title="Hypertext Transfer Protocol -- HTTP/1.1" id="rfc.xref.RFC2616. 2">RFC 2616</cite> without edit.563 sections of <cite title="Hypertext Transfer Protocol -- HTTP/1.1" id="rfc.xref.RFC2616.1">RFC 2616</cite> without edit. 565 564 </p> 566 565 <h2 id="rfc.section.1.1"><a href="#rfc.section.1.1">1.1</a> <a id="intro.requirements" href="#intro.requirements">Requirements</a></h2> … … 969 968 dates. 970 969 </p> 971 <p id="rfc.section.2.3.2.p.2">Entity Tags are described in <a href="p4-conditional.html#entity.tags" title="Entity Tags">Section 2</a> of <a href="#Part4" id="rfc.xref.Part4.2"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>. 970 <p id="rfc.section.2.3.2.p.2">Entity Tags are described in <a href="p4-conditional.html#entity.tags" title="Entity Tags">Section 2</a> of <a href="#Part4" id="rfc.xref.Part4.2"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>. The headers used with entity tags are described in <a href="p4-conditional.html#header.fields" title="Header Field Definitions">Section 6</a> of <a href="#Part4" id="rfc.xref.Part4.3"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>. 972 971 </p> 973 972 <h3 id="rfc.section.2.3.3"><a href="#rfc.section.2.3.3">2.3.3</a> <a id="non-validating.conditionals" href="#non-validating.conditionals">Non-validating Conditionals</a></h3> … … 1806 1805 <p id="rfc.section.A.2.p.1">Clarify denial of service attack avoidance requirement. (<a href="#invalidation.after.updates.or.deletions" title="Invalidation After Updates or Deletions">Section 2.10</a>) 1807 1806 </p> 1807 <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a> Change Log (to be removed by RFC Editor before publication) 1808 </h1> 1809 <h2 id="rfc.section.B.1"><a href="#rfc.section.B.1">B.1</a> Since RFC2616 1810 </h2> 1811 <p id="rfc.section.B.1.p.1">Extracted relevant partitions from <a href="#RFC2616" id="rfc.xref.RFC2616.2"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>. 1812 </p> 1813 <h2 id="rfc.section.B.2"><a href="#rfc.section.B.2">B.2</a> Since draft-ietf-httpbis-p6-cache-00 1814 </h2> 1815 <p id="rfc.section.B.2.p.1">TBD.</p> 1808 1816 <h1><a id="rfc.copyright" href="#rfc.copyright">Full Copyright Statement</a></h1> 1809 1817 <p>Copyright © The IETF Trust (2007).</p> … … 1983 1991 </ul> 1984 1992 </li> 1985 <li class="indline1"><em>Part4</em> <a class="iref" href="#rfc.xref.Part4.1">2.3</a>, <a class="iref" href="#rfc.xref.Part4.2">2.3.2</a>, <a class="iref" href="# Part4"><b>7</b></a><ul class="ind">1993 <li class="indline1"><em>Part4</em> <a class="iref" href="#rfc.xref.Part4.1">2.3</a>, <a class="iref" href="#rfc.xref.Part4.2">2.3.2</a>, <a class="iref" href="#rfc.xref.Part4.3">2.3.2</a>, <a class="iref" href="#Part4"><b>7</b></a><ul class="ind"> 1986 1994 <li class="indline1"><em>Section 2</em> <a class="iref" href="#rfc.xref.Part4.2">2.3.2</a></li> 1987 1995 <li class="indline1"><em>Section 4</em> <a class="iref" href="#rfc.xref.Part4.1">2.3</a></li> 1996 <li class="indline1"><em>Section 6</em> <a class="iref" href="#rfc.xref.Part4.3">2.3.2</a></li> 1988 1997 </ul> 1989 1998 </li> … … 2018 2027 <li class="indline1"><em>RFC2047</em> <a class="iref" href="#rfc.xref.RFC2047.1">3.6</a>, <a class="iref" href="#RFC2047"><b>7</b></a></li> 2019 2028 <li class="indline1"><em>RFC2119</em> <a class="iref" href="#rfc.xref.RFC2119.1">1.1</a>, <a class="iref" href="#RFC2119"><b>7</b></a></li> 2020 <li class="indline1"><em>RFC2616</em> <a class="iref" href="#rfc.xref.RFC2616.1"> §</a>, <a class="iref" href="#rfc.xref.RFC2616.2">1</a>, <a class="iref" href="#RFC2616"><b>7</b></a></li>2029 <li class="indline1"><em>RFC2616</em> <a class="iref" href="#rfc.xref.RFC2616.1">1</a>, <a class="iref" href="#RFC2616"><b>7</b></a>, <a class="iref" href="#rfc.xref.RFC2616.2">B.1</a></li> 2021 2030 </ul> 2022 2031 </li> -
draft-ietf-httpbis/latest/p6-cache.xml
r113 r115 18 18 <!ENTITY combining-byte-ranges "<xref target='Part5' x:rel='#combining.byte.ranges' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 19 19 <!ENTITY entity-length "<xref target='Part3' x:rel='#entity.length' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 20 <!ENTITY entity-header-fields "<xref target='Part4' x:rel='#header.fields' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 20 21 <!ENTITY entity-tags "<xref target='Part4' x:rel='#entity.tags' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 21 22 <!ENTITY full-date "<xref target='Part1' x:rel='#full.date' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> … … 199 200 <note title="Editorial Note (To be removed by RFC Editor)"> 200 201 <t> 201 This version of the HTTP specification contains only minimal editorial202 changes from <xref target="RFC2616"/> (abstract, introductory paragraph,203 and authors' addresses). All other changes are due to partitioning the204 original into seven mostly independent parts. The intent is for readers205 of future drafts to able to use draft 00 as the basis for comparison206 when the WG makes later changes to the specification text. This draft207 will shortly be followed by draft 01 (containing the first round of changes208 that have already been agreed to on the mailing list). There is no point in209 reviewing this draft other than to verify that the partitioning has been210 done correctly. Roy T. Fielding, Yves Lafon, and Julian Reschke211 will be the editors after draft 00 is submitted.212 </t>213 <t>214 202 Discussion of this draft should take place on the HTTPBIS working group 215 203 mailing list (ietf-http-wg@w3.org). The current issues list is … … 1055 1043 </t> 1056 1044 <t> 1057 Entity Tags are described in &entity-tags;. 1045 Entity Tags are described in &entity-tags;. The headers used with entity 1046 tags are described in &entity-header-fields;. 1058 1047 </t> 1059 1048 </section> … … 2844 2833 </section> 2845 2834 2835 <section title="Change Log (to be removed by RFC Editor before publication)"> 2836 2837 <section title="Since RFC2616"> 2838 <t> 2839 Extracted relevant partitions from <xref target="RFC2616"/>. 2840 </t> 2841 </section> 2842 2843 <section title="Since draft-ietf-httpbis-p6-cache-00"> 2844 <t> 2845 TBD. 2846 </t> 2847 </section> 2848 2849 </section> 2850 2846 2851 </back> 2847 2852 </rfc> -
draft-ietf-httpbis/latest/p7-auth.html
r113 r115 340 340 <link rel="Chapter" href="#rfc.section.7" title="7 References"> 341 341 <link rel="Appendix" title="A Compatibility with Previous Versions" href="#rfc.section.A"> 342 <link rel="Appendix" title="B Change Log (to be removed by RFC Editor before publication)" href="#rfc.section.B"> 342 343 <meta name="generator" content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.353, 2007/12/11 23:20:44, XSLT vendor: SAXON 8.9 from Saxonica http://www.saxonica.com/"> 343 344 <link rel="schema.DC" href="http://purl.org/dc/elements/1.1/"> … … 469 470 </p> 470 471 <h1 id="rfc.note.1"><a href="#rfc.note.1">Editorial Note (To be removed by RFC Editor)</a></h1> 471 <p>This version of the HTTP specification contains only minimal editorial changes from <a href="#RFC2616" id="rfc.xref.RFC2616.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a> (abstract, introductory paragraph, and authors' addresses). All other changes are due to partitioning the original into seven472 mostly independent parts. The intent is for readers of future drafts to able to use draft 00 as the basis for comparison when473 the WG makes later changes to the specification text. This draft will shortly be followed by draft 01 (containing the first474 round of changes that have already been agreed to on the mailing list). There is no point in reviewing this draft other than475 to verify that the partitioning has been done correctly. Roy T. Fielding, Yves Lafon, and Julian Reschke will be the editors476 after draft 00 is submitted.477 </p>478 472 <p>Discussion of this draft should take place on the HTTPBIS working group mailing list (ietf-http-wg@w3.org). The current issues 479 473 list is at <<a href="http://www.tools.ietf.org/wg/httpbis/trac/report/11">http://www.tools.ietf.org/wg/httpbis/trac/report/11</a>> and related documents (including fancy diffs) can be found at <<a href="http://www.tools.ietf.org/wg/httpbis/">http://www.tools.ietf.org/wg/httpbis/</a>>. … … 510 504 </ul> 511 505 </li> 506 <li class="tocline0">B. <a href="#rfc.section.B">Change Log (to be removed by RFC Editor before publication)</a><ul class="toc"> 507 <li class="tocline1">B.1 <a href="#rfc.section.B.1">Since RFC2616</a></li> 508 <li class="tocline1">B.2 <a href="#rfc.section.B.2">Since draft-ietf-httpbis-p7-auth-00</a></li> 509 </ul> 510 </li> 512 511 <li class="tocline0"><a href="#rfc.ipr">Intellectual Property and Copyright Statements</a></li> 513 512 <li class="tocline0"><a href="#rfc.index">Index</a></li> … … 515 514 <h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a> <a id="introduction" href="#introduction">Introduction</a></h1> 516 515 <p id="rfc.section.1.p.1">This document will define aspects of HTTP related to access control and authentication. Right now it only includes the extracted 517 relevant sections of <cite title="Hypertext Transfer Protocol -- HTTP/1.1" id="rfc.xref.RFC2616. 2">RFC 2616</cite> with only minor edits.516 relevant sections of <cite title="Hypertext Transfer Protocol -- HTTP/1.1" id="rfc.xref.RFC2616.1">RFC 2616</cite> with only minor edits. 518 517 </p> 519 518 <p id="rfc.section.1.p.2">HTTP provides several <em class="bcp14">OPTIONAL</em> challenge-response authentication mechanisms which can be used by a server to challenge a client request and by a client to … … 675 674 <h1 id="rfc.section.A"><a href="#rfc.section.A">A.</a> <a id="compatibility" href="#compatibility">Compatibility with Previous Versions</a></h1> 676 675 <h2 id="rfc.section.A.1"><a href="#rfc.section.A.1">A.1</a> <a id="changes.from.rfc.2616" href="#changes.from.rfc.2616">Changes from RFC 2616</a></h2> 676 <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a> Change Log (to be removed by RFC Editor before publication) 677 </h1> 678 <h2 id="rfc.section.B.1"><a href="#rfc.section.B.1">B.1</a> Since RFC2616 679 </h2> 680 <p id="rfc.section.B.1.p.1">Extracted relevant partitions from <a href="#RFC2616" id="rfc.xref.RFC2616.2"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>. 681 </p> 682 <h2 id="rfc.section.B.2"><a href="#rfc.section.B.2">B.2</a> Since draft-ietf-httpbis-p7-auth-00 683 </h2> 684 <p id="rfc.section.B.2.p.1">TBD.</p> 677 685 <h1><a id="rfc.copyright" href="#rfc.copyright">Full Copyright Statement</a></h1> 678 686 <p>Copyright © The IETF Trust (2007).</p> … … 749 757 <li class="indline0"><a id="rfc.index.R" href="#rfc.index.R"><b>R</b></a><ul class="ind"> 750 758 <li class="indline1"><em>RFC2119</em> <a class="iref" href="#rfc.xref.RFC2119.1">1.1</a>, <a class="iref" href="#RFC2119"><b>7</b></a></li> 751 <li class="indline1"><em>RFC2616</em> <a class="iref" href="#rfc.xref.RFC2616.1"> §</a>, <a class="iref" href="#rfc.xref.RFC2616.2">1</a>, <a class="iref" href="#RFC2616"><b>7</b></a></li>759 <li class="indline1"><em>RFC2616</em> <a class="iref" href="#rfc.xref.RFC2616.1">1</a>, <a class="iref" href="#RFC2616"><b>7</b></a>, <a class="iref" href="#rfc.xref.RFC2616.2">B.1</a></li> 752 760 <li class="indline1"><em>RFC2617</em> <a class="iref" href="#rfc.xref.RFC2617.1">1</a>, <a class="iref" href="#rfc.xref.RFC2617.2">2.1</a>, <a class="iref" href="#rfc.xref.RFC2617.3">2.2</a>, <a class="iref" href="#rfc.xref.RFC2617.4">3.1</a>, <a class="iref" href="#rfc.xref.RFC2617.5">3.2</a>, <a class="iref" href="#rfc.xref.RFC2617.6">3.3</a>, <a class="iref" href="#rfc.xref.RFC2617.7">3.4</a>, <a class="iref" href="#RFC2617"><b>7</b></a></li> 753 761 </ul> -
draft-ietf-httpbis/latest/p7-auth.xml
r113 r115 185 185 <note title="Editorial Note (To be removed by RFC Editor)"> 186 186 <t> 187 This version of the HTTP specification contains only minimal editorial188 changes from <xref target="RFC2616"/> (abstract, introductory paragraph,189 and authors' addresses). All other changes are due to partitioning the190 original into seven mostly independent parts. The intent is for readers191 of future drafts to able to use draft 00 as the basis for comparison192 when the WG makes later changes to the specification text. This draft193 will shortly be followed by draft 01 (containing the first round of changes194 that have already been agreed to on the mailing list). There is no point in195 reviewing this draft other than to verify that the partitioning has been196 done correctly. Roy T. Fielding, Yves Lafon, and Julian Reschke197 will be the editors after draft 00 is submitted.198 </t>199 <t>200 187 Discussion of this draft should take place on the HTTPBIS working group 201 188 mailing list (ietf-http-wg@w3.org). The current issues list is … … 598 585 </section> 599 586 587 <section title="Change Log (to be removed by RFC Editor before publication)"> 588 589 <section title="Since RFC2616"> 590 <t> 591 Extracted relevant partitions from <xref target="RFC2616"/>. 592 </t> 593 </section> 594 595 <section title="Since draft-ietf-httpbis-p7-auth-00"> 596 <t> 597 TBD. 598 </t> 599 </section> 600 601 </section> 602 600 603 </back> 601 604 </rfc>
Note: See TracChangeset
for help on using the changeset viewer.