Changeset 115 for draft-ietf-httpbis/latest/p1-messaging.html
- Timestamp:
- 30/12/07 14:56:05 (13 years ago)
- File:
-
- 1 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>
Note: See TracChangeset
for help on using the changeset viewer.