Ticket #59: i59.2.diff
File i59.2.diff, 18.5 KB (added by julian.reschke@…, 14 years ago) |
---|
-
p1-messaging.html
476 476 </tr> 477 477 <tr> 478 478 <td class="header left"></td> 479 <td class="header right">June 6, 2008</td>479 <td class="header right">June 9, 2008</td> 480 480 </tr> 481 481 </table> 482 482 <p class="title">HTTP/1.1, part 1: URIs, Connections, and Message Parsing<br><span class="filename">draft-ietf-httpbis-p1-messaging-latest</span></p> -
p2-semantics.xml
72 72 <?rfc inline="yes"?> 73 73 <?rfc-ext allow-markup-in-artwork="yes" ?> 74 74 <?rfc-ext include-references-in-index="yes" ?> 75 <rfc obsoletes="2616" category="std"75 <rfc obsoletes="2616" updates="2817" category="std" 76 76 ipr="full3978" docName="draft-ietf-httpbis-p2-semantics-&ID-VERSION;" 77 77 xmlns:x='http://purl.org/net/xml2rfc/ext'> 78 78 <front> … … 538 538 with the response, since that entity is likely to include human-readable 539 539 information which will explain the unusual status. 540 540 </t> 541 542 <section title="Status Code Registry" anchor="status.code.registry"> 543 <t> 544 The HTTP Status Code Registry defines the name space for the Status-Code 545 token in the Status line of an HTTP response. 546 </t> 547 <t> 548 Values to be added to this name space are subject to IETF review. Any 549 document registering new status codes should be traceable through statuses of 550 either 'Obsoletes' or 'Updates' to this document. 551 </t> 552 <t> 553 The registry itself is maintained at <eref target="http://www.iana.org/assignments/http-status-codes"/>. 554 </t> 541 555 </section> 542 556 557 </section> 558 543 559 <section title="Response Header Fields" anchor="response.header.fields"> 544 560 <x:anchor-alias value="response-header"/> 545 561 <t> … … 2073 2089 2074 2090 <section title="IANA Considerations" anchor="IANA.considerations"> 2075 2091 <section title="Status Code Registry" anchor="status.code.registration"> 2092 <t> 2093 The registration procedure for HTTP Status Codes -- previously defined 2094 in <xref target="RFC2817" x:fmt="of" x:sec="7.1"/> -- is now defined 2095 by <xref target="status.code.registry"/> of this document. 2096 </t> 2076 2097 <!--AUTOGENERATED FROM extract-status-code-defs.xslt, do not edit manually--> 2077 2098 <!--(START)--> 2078 2099 <t xmlns:x="http://purl.org/net/xml2rfc/ext"> 2079 2100 The HTTP Status Code Registry located at <eref target="http://www.iana.org/assignments/http-status-codes"/> 2080 should be updated with the registrations below (see <xref target="RFC2817" x:sec="7.1" x:fmt=","/>).2101 should be updated with the registrations below: 2081 2102 </t> 2082 2103 <texttable xmlns:x="http://purl.org/net/xml2rfc/ext"> 2083 2104 <ttcol>Value</ttcol> … … 2330 2351 <xref target="status.505"/> 2331 2352 </c> 2332 2353 </texttable> 2333 <t xmlns:x="http://purl.org/net/xml2rfc/ext"/>2334 2354 <!--(END)--> 2335 2355 </section> 2336 2356 <section title="Message Header Registration" anchor="message.header.registration"> … … 3009 3029 3010 3030 <section title="Changes from RFC 2616" anchor="changes.from.rfc.2616"> 3011 3031 <t> 3032 This document takes over the Status Code Registry, previously defined 3033 in <xref target="RFC2817" x:fmt="of" x:sec="7.1"/>. 3034 (<xref target="status.code.registry"/>) 3035 </t> 3036 <t> 3012 3037 Clarify definition of POST. 3013 3038 (<xref target="POST"/>) 3014 3039 </t> … … 3151 3176 "Requiring Allow in 405 responses" 3152 3177 </t> 3153 3178 <t> 3179 <eref target="http://www3.tools.ietf.org/wg/httpbis/trac/ticket/59"/>: 3180 "Status Code Registry" 3181 </t> 3182 <t> 3154 3183 <eref target="http://www3.tools.ietf.org/wg/httpbis/trac/ticket/61"/>: 3155 3184 "Redirection vs. Location" 3156 3185 </t> … … 3182 3211 </list> 3183 3212 </t> 3184 3213 <t> 3185 Ongoing work on IANA HTTP Status Code Registration (<eref target="http://www3.tools.ietf.org/wg/httpbis/trac/ticket/59"/>):3186 <list style="symbols">3187 <t>3188 Reference RFC 2817, and update the HTTP status code registrations.3189 </t>3190 </list>3191 </t>3192 <t>3193 3214 Ongoing work on ABNF conversion (<eref target="http://www3.tools.ietf.org/wg/httpbis/trac/ticket/36"/>): 3194 3215 <list style="symbols"> 3195 3216 <t> -
p2-semantics.html
418 418 <td class="header right">One Laptop per Child</td> 419 419 </tr> 420 420 <tr> 421 <td class="header left">Intended status: Standards Track</td> 421 <td class="header left">Updates: <a href="http://tools.ietf.org/html/rfc2817">2817</a> (if approved) 422 </td> 422 423 <td class="header right">J. Mogul</td> 423 424 </tr> 424 425 <tr> 425 <td class="header left"> Expires: December 2008</td>426 <td class="header left">Intended status: Standards Track</td> 426 427 <td class="header right">HP</td> 427 428 </tr> 428 429 <tr> 429 <td class="header left"> </td>430 <td class="header left">Expires: December 2008</td> 430 431 <td class="header right">H. Frystyk</td> 431 432 </tr> 432 433 <tr> … … 475 476 </tr> 476 477 <tr> 477 478 <td class="header left"></td> 478 <td class="header right">June 6, 2008</td>479 <td class="header right">June 10, 2008</td> 479 480 </tr> 480 481 </table> 481 482 <p class="title">HTTP/1.1, part 2: Message Semantics<br><span class="filename">draft-ietf-httpbis-p2-semantics-latest</span></p> … … 519 520 <li class="tocline0">2. <a href="#notation">Notational Conventions and Generic Grammar</a></li> 520 521 <li class="tocline0">3. <a href="#method">Method</a></li> 521 522 <li class="tocline0">4. <a href="#request.header.fields">Request Header Fields</a></li> 522 <li class="tocline0">5. <a href="#status.code.and.reason.phrase">Status Code and Reason Phrase</a></li> 523 <li class="tocline0">5. <a href="#status.code.and.reason.phrase">Status Code and Reason Phrase</a><ul class="toc"> 524 <li class="tocline1">5.1 <a href="#status.code.registry">Status Code Registry</a></li> 525 </ul> 526 </li> 523 527 <li class="tocline0">6. <a href="#response.header.fields">Response Header Fields</a></li> 524 528 <li class="tocline0">7. <a href="#entity">Entity</a></li> 525 529 <li class="tocline0">8. <a href="#method.definitions">Method Definitions</a><ul class="toc"> … … 808 812 something wrong with its request and treat the response as if it had received a 400 status code. In such cases, user agents <em class="bcp14">SHOULD</em> present to the user the entity returned with the response, since that entity is likely to include human-readable information 809 813 which will explain the unusual status. 810 814 </p> 815 <h2 id="rfc.section.5.1"><a href="#rfc.section.5.1">5.1</a> <a id="status.code.registry" href="#status.code.registry">Status Code Registry</a></h2> 816 <p id="rfc.section.5.1.p.1">The HTTP Status Code Registry defines the name space for the Status-Code token in the Status line of an HTTP response.</p> 817 <p id="rfc.section.5.1.p.2">Values to be added to this name space are subject to IETF review. Any document registering new status codes should be traceable 818 through statuses of either 'Obsoletes' or 'Updates' to this document. 819 </p> 820 <p id="rfc.section.5.1.p.3">The registry itself is maintained at <<a href="http://www.iana.org/assignments/http-status-codes">http://www.iana.org/assignments/http-status-codes</a>>. 821 </p> 811 822 <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a> <a id="response.header.fields" href="#response.header.fields">Response Header Fields</a></h1> 812 823 <p id="rfc.section.6.p.1">The response-header fields allow the server to pass additional information about the response which cannot be placed in the 813 824 Status-Line. These header fields give information about the server and about further access to the resource identified by … … 1578 1589 <div id="rfc.figure.u.29"></div><pre class="text"> User-Agent: CERN-LineMode/2.15 libwww/2.17b3 1579 1590 </pre><h1 id="rfc.section.11"><a href="#rfc.section.11">11.</a> <a id="IANA.considerations" href="#IANA.considerations">IANA Considerations</a></h1> 1580 1591 <h2 id="rfc.section.11.1"><a href="#rfc.section.11.1">11.1</a> <a id="status.code.registration" href="#status.code.registration">Status Code Registry</a></h2> 1581 <p id="rfc.section.11.1.p.1">The HTTP Status Code Registry located at <<a href="http://www.iana.org/assignments/http-status-codes">http://www.iana.org/assignments/http-status-codes</a>> should be updated with the registrations below (see <a href="#RFC2817" id="rfc.xref.RFC2817.1"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>, <a href="http://tools.ietf.org/html/rfc2817#section-7.1">Section 7.1</a>).1592 <p id="rfc.section.11.1.p.1">The registration procedure for HTTP Status Codes -- previously defined in <a href="http://tools.ietf.org/html/rfc2817#section-7.1">Section 7.1</a> of <a href="#RFC2817" id="rfc.xref.RFC2817.1"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a> -- is now defined by <a href="#status.code.registry" title="Status Code Registry">Section 5.1</a> of this document. 1582 1593 </p> 1594 <p id="rfc.section.11.1.p.2">The HTTP Status Code Registry located at <<a href="http://www.iana.org/assignments/http-status-codes">http://www.iana.org/assignments/http-status-codes</a>> should be updated with the registrations below: 1595 </p> 1583 1596 <div id="rfc.table.u.1"> 1584 1597 <table summary="" class="tt full" cellpadding="3" cellspacing="0"> 1585 1598 <thead> … … 2093 2106 <p id="rfc.section.A.1.p.6">The PATCH<span id="rfc.iref.p.3"></span><span id="rfc.iref.m.10"></span>, LINK<span id="rfc.iref.l.2"></span><span id="rfc.iref.m.11"></span>, UNLINK<span id="rfc.iref.u.2"></span><span id="rfc.iref.m.12"></span> methods were defined but not commonly implemented in previous versions of this specification. See <a href="#RFC2068" id="rfc.xref.RFC2068.2"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>. 2094 2107 </p> 2095 2108 <h2 id="rfc.section.A.2"><a href="#rfc.section.A.2">A.2</a> <a id="changes.from.rfc.2616" href="#changes.from.rfc.2616">Changes from RFC 2616</a></h2> 2096 <p id="rfc.section.A.2.p.1"> Clarify definition of POST. (<a href="#POST" id="rfc.xref.POST.2" title="POST">Section 8.5</a>)2109 <p id="rfc.section.A.2.p.1">This document takes over the Status Code Registry, previously defined in <a href="http://tools.ietf.org/html/rfc2817#section-7.1">Section 7.1</a> of <a href="#RFC2817" id="rfc.xref.RFC2817.2"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>. (<a href="#status.code.registry" title="Status Code Registry">Section 5.1</a>) 2097 2110 </p> 2098 <p id="rfc.section.A.2.p.2">Failed to consider that there are many other request methods that are safe to automatically redirect, and further that the 2111 <p id="rfc.section.A.2.p.2">Clarify definition of POST. (<a href="#POST" id="rfc.xref.POST.2" title="POST">Section 8.5</a>) 2112 </p> 2113 <p id="rfc.section.A.2.p.3">Failed to consider that there are many other request methods that are safe to automatically redirect, and further that the 2099 2114 user agent is able to make that determination based on the request method semantics. (Sections <a href="#status.301" id="rfc.xref.status.301.3" title="301 Moved Permanently">9.3.2</a>, <a href="#status.302" id="rfc.xref.status.302.3" title="302 Found">9.3.3</a> and <a href="#status.307" id="rfc.xref.status.307.3" title="307 Temporary Redirect">9.3.8</a>) 2100 2115 </p> 2101 <p id="rfc.section.A.2.p. 3">Deprecate 305 Use Proxy status code, because user agents did not implement it. It used to indicate that the requested resource2116 <p id="rfc.section.A.2.p.4">Deprecate 305 Use Proxy status code, because user agents did not implement it. It used to indicate that the requested resource 2102 2117 must be accessed through the proxy given by the Location field. The Location field gave the URI of the proxy. The recipient 2103 2118 was expected to repeat this single request via the proxy. (<a href="#status.305" id="rfc.xref.status.305.3" title="305 Use Proxy">Section 9.3.6</a>) 2104 2119 </p> 2105 <p id="rfc.section.A.2.p. 4">Reclassify Allow header as response header, removing the option to specify it in a PUT request. Relax the server requirement2120 <p id="rfc.section.A.2.p.5">Reclassify Allow header as response header, removing the option to specify it in a PUT request. Relax the server requirement 2106 2121 on the contents of the Allow header and remove requirement on clients to always trust the header value. (<a href="#header.allow" id="rfc.xref.header.allow.4" title="Allow">Section 10.1</a>) 2107 2122 </p> 2108 <p id="rfc.section.A.2.p. 5">Correct syntax of Location header to allow fragment, as referred symbol wasn't what was expected, and add some clarifications2123 <p id="rfc.section.A.2.p.6">Correct syntax of Location header to allow fragment, as referred symbol wasn't what was expected, and add some clarifications 2109 2124 as to when it would not be appropriate. (<a href="#header.location" id="rfc.xref.header.location.4" title="Location">Section 10.4</a>) 2110 2125 </p> 2111 <p id="rfc.section.A.2.p. 6">In the description of the Server header, the Via field was described as a SHOULD. The requirement was and is stated correctly2126 <p id="rfc.section.A.2.p.7">In the description of the Server header, the Via field was described as a SHOULD. The requirement was and is stated correctly 2112 2127 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.25"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. (<a href="#header.server" id="rfc.xref.header.server.4" title="Server">Section 10.8</a>) 2113 2128 </p> 2114 2129 <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a> <a id="change.log" href="#change.log">Change Log (to be removed by RFC Editor before publication)</a></h1> … … 2163 2178 <ul> 2164 2179 <li> <<a href="http://www3.tools.ietf.org/wg/httpbis/trac/ticket/24">http://www3.tools.ietf.org/wg/httpbis/trac/ticket/24</a>>: "Requiring Allow in 405 responses" 2165 2180 </li> 2181 <li> <<a href="http://www3.tools.ietf.org/wg/httpbis/trac/ticket/59">http://www3.tools.ietf.org/wg/httpbis/trac/ticket/59</a>>: "Status Code Registry" 2182 </li> 2166 2183 <li> <<a href="http://www3.tools.ietf.org/wg/httpbis/trac/ticket/61">http://www3.tools.ietf.org/wg/httpbis/trac/ticket/61</a>>: "Redirection vs. Location" 2167 2184 </li> 2168 2185 <li> <<a href="http://www3.tools.ietf.org/wg/httpbis/trac/ticket/70">http://www3.tools.ietf.org/wg/httpbis/trac/ticket/70</a>>: "Cacheability of 303 response" … … 2179 2196 <ul> 2180 2197 <li>Reference RFC 3984, and update header registrations for headers defined in this document.</li> 2181 2198 </ul> 2182 <p id="rfc.section.B.4.p.3">Ongoing work on IANA HTTP Status Code Registration (<<a href="http://www3.tools.ietf.org/wg/httpbis/trac/ticket/59">http://www3.tools.ietf.org/wg/httpbis/trac/ticket/59</a>>):2199 <p id="rfc.section.B.4.p.3">Ongoing work on ABNF conversion (<<a href="http://www3.tools.ietf.org/wg/httpbis/trac/ticket/36">http://www3.tools.ietf.org/wg/httpbis/trac/ticket/36</a>>): 2183 2200 </p> 2184 2201 <ul> 2185 <li>Reference RFC 2817, and update the HTTP status code registrations.</li>2186 </ul>2187 <p id="rfc.section.B.4.p.4">Ongoing work on ABNF conversion (<<a href="http://www3.tools.ietf.org/wg/httpbis/trac/ticket/36">http://www3.tools.ietf.org/wg/httpbis/trac/ticket/36</a>>):2188 </p>2189 <ul>2190 2202 <li>Replace string literals when the string really is case-sensitive (method).</li> 2191 2203 </ul> 2192 2204 <h1><a id="rfc.copyright" href="#rfc.copyright">Full Copyright Statement</a></h1> … … 2430 2442 <li class="indline1"><em>RFC2068</em> <a class="iref" href="#rfc.xref.RFC2068.1">9.3.3</a>, <a class="iref" href="#RFC2068"><b>14.2</b></a>, <a class="iref" href="#rfc.xref.RFC2068.2">A.1</a></li> 2431 2443 <li class="indline1"><em>RFC2119</em> <a class="iref" href="#rfc.xref.RFC2119.1">1.1</a>, <a class="iref" href="#RFC2119"><b>14.1</b></a></li> 2432 2444 <li class="indline1"><em>RFC2616</em> <a class="iref" href="#rfc.xref.RFC2616.1">1</a>, <a class="iref" href="#RFC2616"><b>14.2</b></a>, <a class="iref" href="#rfc.xref.RFC2616.2">B.1</a></li> 2433 <li class="indline1"><em>RFC2817</em> <a class="iref" href="#rfc.xref.RFC2817.1">11.1</a>, <a class="iref" href="#RFC2817"><b>14.2</b></a> <ul class="ind">2434 <li class="indline1"><em>Section 7.1</em> <a class="iref" href="#rfc.xref.RFC2817.1">11.1</a> </li>2445 <li class="indline1"><em>RFC2817</em> <a class="iref" href="#rfc.xref.RFC2817.1">11.1</a>, <a class="iref" href="#RFC2817"><b>14.2</b></a>, <a class="iref" href="#rfc.xref.RFC2817.2">A.2</a><ul class="ind"> 2446 <li class="indline1"><em>Section 7.1</em> <a class="iref" href="#rfc.xref.RFC2817.1">11.1</a>, <a class="iref" href="#rfc.xref.RFC2817.2">A.2</a></li> 2435 2447 </ul> 2436 2448 </li> 2437 2449 <li class="indline1"><em>RFC2822</em> <a class="iref" href="#rfc.xref.RFC2822.1">10.3</a>, <a class="iref" href="#rfc.xref.RFC2822.2">10.3</a>, <a class="iref" href="#RFC2822"><b>14.2</b></a><ul class="ind"> -
extract-status-code-defs.xslt
12 12 <xsl:text> </xsl:text> 13 13 <t> 14 14 The HTTP Status Code Registry located at <eref target="http://www.iana.org/assignments/http-status-codes"/> 15 should be updated with the registrations below (see <xref target="RFC2817" x:sec="7.1" x:fmt=","/>).15 should be updated with the registrations below: 16 16 </t> 17 17 <texttable> 18 18 <ttcol>Value</ttcol>