* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Changeset 1040


Ignore:
Timestamp:
2010-10-20 09:00:58 (4 years ago)
Author:
julian.reschke@gmx.de
Message:

Rephrase the requirement about message bodies as a statement of fact (see #230)

Location:
draft-ietf-httpbis/latest
Files:
2 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/p2-semantics.html

    r1038 r1040  
    403403      <meta name="dct.creator" content="Reschke, J. F."> 
    404404      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest"> 
    405       <meta name="dct.issued" scheme="ISO8601" content="2010-10-19"> 
     405      <meta name="dct.issued" scheme="ISO8601" content="2010-10-20"> 
    406406      <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 
    407407      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 2 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 2 defines the semantics of HTTP messages as expressed by request methods, request-header fields, response status codes, and response-header fields."> 
     
    434434            </tr> 
    435435            <tr> 
    436                <td class="left">Expires: April 22, 2011</td> 
     436               <td class="left">Expires: April 23, 2011</td> 
    437437               <td class="right">HP</td> 
    438438            </tr> 
     
    487487            <tr> 
    488488               <td class="left"></td> 
    489                <td class="right">October 19, 2010</td> 
     489               <td class="right">October 20, 2010</td> 
    490490            </tr> 
    491491         </tbody> 
     
    514514         in progress”. 
    515515      </p> 
    516       <p>This Internet-Draft will expire on April 22, 2011.</p> 
     516      <p>This Internet-Draft will expire on April 23, 2011.</p> 
    517517      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 
    518518      <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p> 
     
    799799         or application. 
    800800      </p> 
    801       <p id="rfc.section.2.1.1.p.3">New methods <em class="bcp14">MUST NOT</em> prohibit a message-body on either the request or the response message; however they <em class="bcp14">MAY</em> specify that only a zero-length body is allowed. 
     801      <p id="rfc.section.2.1.1.p.3">Due to the parsing rules defined in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.18"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, definitions of HTTP methods cannot prohibit the presence of a message-body on either the request or the response message 
     802         (with responses to HEAD requests being the single exception). Definitions of new methods cannot change this rule, but they 
     803         can specify that only zero-length bodies (as opposed to absent bodies) are allowed. 
    802804      </p> 
    803805      <p id="rfc.section.2.1.1.p.4">New methods <em class="bcp14">MUST</em> define whether they are safe (<a href="#safe.methods" title="Safe Methods">Section&nbsp;7.1.1</a>) and whether they are idempotent (<a href="#idempotent.methods" title="Idempotent Methods">Section&nbsp;7.1.2</a>). They <em class="bcp14">MUST</em> also state whether they can be cached (<a href="#Part6" id="rfc.xref.Part6.3"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>); in particular what conditions a cache may store the response, and under what conditions such a stored response may be used 
     
    821823                 / <a href="#header.expect" class="smpl">Expect</a>                   ; <a href="#header.expect" id="rfc.xref.header.expect.1" title="Expect">Section&nbsp;9.2</a> 
    822824                 / <a href="#header.from" class="smpl">From</a>                     ; <a href="#header.from" id="rfc.xref.header.from.1" title="From">Section&nbsp;9.3</a> 
    823                  / <a href="#abnf.dependencies" class="smpl">Host</a>                     ; <a href="#Part1" id="rfc.xref.Part1.18"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#header.host" title="Host">Section 9.4</a> 
     825                 / <a href="#abnf.dependencies" class="smpl">Host</a>                     ; <a href="#Part1" id="rfc.xref.Part1.19"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#header.host" title="Host">Section 9.4</a> 
    824826                 / <a href="#abnf.dependencies" class="smpl">If-Match</a>                 ; <a href="#Part4" id="rfc.xref.Part4.7"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>, <a href="p4-conditional.html#header.if-match" title="If-Match">Section 6.2</a> 
    825827                 / <a href="#abnf.dependencies" class="smpl">If-Modified-Since</a>        ; <a href="#Part4" id="rfc.xref.Part4.8"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>, <a href="p4-conditional.html#header.if-modified-since" title="If-Modified-Since">Section 6.3</a> 
     
    831833                 / <a href="#abnf.dependencies" class="smpl">Range</a>                    ; <a href="#Part5" id="rfc.xref.Part5.5"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>, <a href="p5-range.html#header.range" title="Range">Section 5.4</a> 
    832834                 / <a href="#header.referer" class="smpl">Referer</a>                  ; <a href="#header.referer" id="rfc.xref.header.referer.1" title="Referer">Section&nbsp;9.6</a> 
    833                  / <a href="#abnf.dependencies" class="smpl">TE</a>                       ; <a href="#Part1" id="rfc.xref.Part1.19"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#header.te" title="TE">Section 9.5</a> 
     835                 / <a href="#abnf.dependencies" class="smpl">TE</a>                       ; <a href="#Part1" id="rfc.xref.Part1.20"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#header.te" title="TE">Section 9.5</a> 
    834836                 / <a href="#header.user-agent" class="smpl">User-Agent</a>               ; <a href="#header.user-agent" id="rfc.xref.header.user-agent.1" title="User-Agent">Section&nbsp;9.9</a> 
    835837</pre><p id="rfc.section.3.p.3">Request-header field names can be extended reliably only in combination with a change in the protocol version. However, new 
     
    919921      <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a>&nbsp;<a id="response.header.fields" href="#response.header.fields">Response Header Fields</a></h1> 
    920922      <p id="rfc.section.5.p.1">The response-header fields allow the server to pass additional information about the response which cannot be placed in the 
    921          Status-Line. These header fields give information about the server and about further access to the target resource (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.20"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). 
     923         Status-Line. These header fields give information about the server and about further access to the target resource (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.21"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). 
    922924      </p> 
    923925      <div id="rfc.figure.u.11"></div><pre class="inline"><span id="rfc.iref.g.7"></span>  <a href="#response.header.fields" class="smpl">response-header</a> = <a href="#abnf.dependencies" class="smpl">Accept-Ranges</a>           ; <a href="#Part5" id="rfc.xref.Part5.9"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>, <a href="p5-range.html#header.accept-ranges" title="Accept-Ranges">Section 5.1</a> 
     
    940942         in an HTTP message, it is referred to as the payload of the message. HTTP representations are defined in <a href="#Part3" id="rfc.xref.Part3.9"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>. 
    941943      </p> 
    942       <p id="rfc.section.6.p.2">A representation body is only present in a message when a message-body is present, as described in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.21"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. The representation body is obtained from the message-body by decoding any Transfer-Encoding that might have been applied 
     944      <p id="rfc.section.6.p.2">A representation body is only present in a message when a message-body is present, as described in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.22"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. The representation body is obtained from the message-body by decoding any Transfer-Encoding that might have been applied 
    943945         to ensure safe and proper transfer of the message. 
    944946      </p> 
     
    946948      <p id="rfc.section.6.1.p.1">It is sometimes necessary to determine an identifier for the resource associated with a representation.</p> 
    947949      <p id="rfc.section.6.1.p.2">An HTTP request representation, when present, is always associated with an anonymous (i.e., unidentified) resource.</p> 
    948       <p id="rfc.section.6.1.p.3">In the common case, an HTTP response is a representation of the target resource (see <a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.22"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). However, this is not always the case. To determine the URI of the resource a response is associated with, the following 
     950      <p id="rfc.section.6.1.p.3">In the common case, an HTTP response is a representation of the target resource (see <a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.23"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). However, this is not always the case. To determine the URI of the resource a response is associated with, the following 
    949951         rules are used (with the first applicable one being selected): 
    950952      </p> 
     
    11291131      </p> 
    11301132      <p id="rfc.section.7.8.p.2">TRACE allows the client to see what is being received at the other end of the request chain and use that data for testing 
    1131          or diagnostic information. The value of the Via header field (<a href="p1-messaging.html#header.via" title="Via">Section 9.9</a> of <a href="#Part1" id="rfc.xref.Part1.23"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) is of particular interest, since it acts as a trace of the request chain. Use of the Max-Forwards header field allows the 
     1133         or diagnostic information. The value of the Via header field (<a href="p1-messaging.html#header.via" title="Via">Section 9.9</a> of <a href="#Part1" id="rfc.xref.Part1.24"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) is of particular interest, since it acts as a trace of the request chain. Use of the Max-Forwards header field allows the 
    11321134         client to limit the length of the request chain, which is useful for testing a chain of proxies forwarding messages in an 
    11331135         infinite loop. 
    11341136      </p> 
    1135       <p id="rfc.section.7.8.p.3">If the request is valid, the response <em class="bcp14">SHOULD</em> have a Content-Type of "message/http" (see <a href="p1-messaging.html#internet.media.type.message.http" title="Internet Media Type message/http">Section 10.3.1</a> of <a href="#Part1" id="rfc.xref.Part1.24"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) and contain a message-body that encloses a copy of the entire request message. Responses to the TRACE method are not cacheable. 
     1137      <p id="rfc.section.7.8.p.3">If the request is valid, the response <em class="bcp14">SHOULD</em> have a Content-Type of "message/http" (see <a href="p1-messaging.html#internet.media.type.message.http" title="Internet Media Type message/http">Section 10.3.1</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>) and contain a message-body that encloses a copy of the entire request message. Responses to the TRACE method are not cacheable. 
    11361138      </p> 
    11371139      <div id="rfc.iref.c.1"></div> 
     
    11601162      <p id="rfc.section.8.1.1.p.1">The client <em class="bcp14">SHOULD</em> continue with its request. This interim response is used to inform the client that the initial part of the request has been 
    11611163         received and has not yet been rejected by the server. The client <em class="bcp14">SHOULD</em> continue by sending the remainder of the request or, if the request has already been completed, ignore this response. The 
    1162          server <em class="bcp14">MUST</em> send a final response after the request has been completed. See <a href="p1-messaging.html#use.of.the.100.status" title="Use of the 100 (Continue) Status">Section 7.2.3</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> for detailed discussion of the use and handling of this status code. 
     1164         server <em class="bcp14">MUST</em> send a final response after the request has been completed. See <a href="p1-messaging.html#use.of.the.100.status" title="Use of the 100 (Continue) Status">Section 7.2.3</a> of <a href="#Part1" id="rfc.xref.Part1.26"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for detailed discussion of the use and handling of this status code. 
    11631165      </p> 
    11641166      <div id="rfc.iref.26"></div> 
    11651167      <div id="rfc.iref.s.3"></div> 
    11661168      <h3 id="rfc.section.8.1.2"><a href="#rfc.section.8.1.2">8.1.2</a>&nbsp;<a id="status.101" href="#status.101">101 Switching Protocols</a></h3> 
    1167       <p id="rfc.section.8.1.2.p.1">The server understands and is willing to comply with the client's request, via the Upgrade message header field (<a href="p1-messaging.html#header.upgrade" title="Upgrade">Section 9.8</a> of <a href="#Part1" id="rfc.xref.Part1.26"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>), for a change in the application protocol being used on this connection. The server will switch protocols to those defined 
     1169      <p id="rfc.section.8.1.2.p.1">The server understands and is willing to comply with the client's request, via the Upgrade message header field (<a href="p1-messaging.html#header.upgrade" title="Upgrade">Section 9.8</a> of <a href="#Part1" id="rfc.xref.Part1.27"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>), for a change in the application protocol being used on this connection. The server will switch protocols to those defined 
    11681170         by the response's Upgrade header field immediately after the empty line which terminates the 101 response. 
    11691171      </p> 
     
    15501552      <p id="rfc.section.8.5.6.p.1">The server does not support, or refuses to support, the protocol version that was used in the request message. The server 
    15511553         is indicating that it is unable or unwilling to complete the request using the same major version as the client, as described 
    1552          in <a href="p1-messaging.html#http.version" title="HTTP Version">Section 2.5</a> of <a href="#Part1" id="rfc.xref.Part1.27"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, other than with this error message. The response <em class="bcp14">SHOULD</em> contain a representation describing why that version is not supported and what other protocols are supported by that server. 
     1554         in <a href="p1-messaging.html#http.version" title="HTTP Version">Section 2.5</a> of <a href="#Part1" id="rfc.xref.Part1.28"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, other than with this error message. The response <em class="bcp14">SHOULD</em> contain a representation describing why that version is not supported and what other protocols are supported by that server. 
    15531555      </p> 
    15541556      <h1 id="rfc.section.9"><a href="#rfc.section.9">9.</a>&nbsp;<a id="header.fields" href="#header.fields">Header Field Definitions</a></h1> 
     
    15921594      </p> 
    15931595      <p id="rfc.section.9.2.p.7">Many older HTTP/1.0 and HTTP/1.1 applications do not understand the Expect header field.</p> 
    1594       <p id="rfc.section.9.2.p.8">See <a href="p1-messaging.html#use.of.the.100.status" title="Use of the 100 (Continue) Status">Section 7.2.3</a> of <a href="#Part1" id="rfc.xref.Part1.28"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for the use of the 100 (Continue) status code. 
     1596      <p id="rfc.section.9.2.p.8">See <a href="p1-messaging.html#use.of.the.100.status" title="Use of the 100 (Continue) Status">Section 7.2.3</a> of <a href="#Part1" id="rfc.xref.Part1.29"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for the use of the 100 (Continue) status code. 
    15951597      </p> 
    15961598      <div id="rfc.iref.f.1"></div> 
     
    17031705      <h2 id="rfc.section.9.8"><a href="#rfc.section.9.8">9.8</a>&nbsp;<a id="header.server" href="#header.server">Server</a></h2> 
    17041706      <p id="rfc.section.9.8.p.1">The "Server" response-header field contains information about the software used by the origin server to handle the request.</p> 
    1705       <p id="rfc.section.9.8.p.2">The field can contain multiple product tokens (<a href="p1-messaging.html#product.tokens" title="Product Tokens">Section 6.3</a> of <a href="#Part1" id="rfc.xref.Part1.29"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) and comments (<a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.30"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) identifying the server and any significant subproducts. The product tokens are listed in order of their significance for 
     1707      <p id="rfc.section.9.8.p.2">The field can contain multiple product tokens (<a href="p1-messaging.html#product.tokens" title="Product Tokens">Section 6.3</a> of <a href="#Part1" id="rfc.xref.Part1.30"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) and comments (<a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.31"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) identifying the server and any significant subproducts. The product tokens are listed in order of their significance for 
    17061708         identifying the application. 
    17071709      </p> 
     
    17111713</pre><p id="rfc.section.9.8.p.4">Example:</p> 
    17121714      <div id="rfc.figure.u.27"></div><pre class="text">  Server: CERN/3.0 libwww/2.17 
    1713 </pre><p id="rfc.section.9.8.p.6">If the response is being forwarded through a proxy, the proxy application <em class="bcp14">MUST NOT</em> modify the Server response-header field. Instead, it <em class="bcp14">MUST</em> include a Via field (as described in <a href="p1-messaging.html#header.via" title="Via">Section 9.9</a> of <a href="#Part1" id="rfc.xref.Part1.31"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). 
     1715</pre><p id="rfc.section.9.8.p.6">If the response is being forwarded through a proxy, the proxy application <em class="bcp14">MUST NOT</em> modify the Server response-header field. Instead, it <em class="bcp14">MUST</em> include a Via field (as described in <a href="p1-messaging.html#header.via" title="Via">Section 9.9</a> of <a href="#Part1" id="rfc.xref.Part1.32"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). 
    17141716      </p> 
    17151717      <div class="note" id="rfc.section.9.8.p.7">  
     
    17271729         user agent limitations. 
    17281730      </p> 
    1729       <p id="rfc.section.9.9.p.3">The field can contain multiple product tokens (<a href="p1-messaging.html#product.tokens" title="Product Tokens">Section 6.3</a> of <a href="#Part1" id="rfc.xref.Part1.32"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) and comments (<a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.33"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) identifying the agent and its significant subproducts. By convention, the product tokens are listed in order of their significance 
     1731      <p id="rfc.section.9.9.p.3">The field can contain multiple product tokens (<a href="p1-messaging.html#product.tokens" title="Product Tokens">Section 6.3</a> of <a href="#Part1" id="rfc.xref.Part1.33"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) and comments (<a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.34"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) identifying the agent and its significant subproducts. By convention, the product tokens are listed in order of their significance 
    17301732         for identifying the application. 
    17311733      </p> 
     
    23132315      </p> 
    23142316      <p id="rfc.section.A.p.8">In the description of the Server header field, the Via field was described as a SHOULD. The requirement was and is stated 
    2315          correctly in the description of the Via header field in <a href="p1-messaging.html#header.via" title="Via">Section 9.9</a> of <a href="#Part1" id="rfc.xref.Part1.34"><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&nbsp;9.8</a>) 
     2317         correctly in the description of the Via header field in <a href="p1-messaging.html#header.via" title="Via">Section 9.9</a> of <a href="#Part1" id="rfc.xref.Part1.35"><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&nbsp;9.8</a>) 
    23162318      </p> 
    23172319      <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a>&nbsp;<a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1> 
     
    27902792            </li> 
    27912793            <li class="indline0"><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul class="ind"> 
    2792                   <li class="indline1"><em>Part1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.1">1</a>, <a class="iref" href="#rfc.xref.Part1.2">1.2</a>, <a class="iref" href="#rfc.xref.Part1.3">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.4">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.5">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.6">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.7">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.8">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.9">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.10">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.11">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.12">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.13">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.14">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.15">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.16">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.17">2</a>, <a class="iref" href="#rfc.xref.Part1.18">3</a>, <a class="iref" href="#rfc.xref.Part1.19">3</a>, <a class="iref" href="#rfc.xref.Part1.20">5</a>, <a class="iref" href="#rfc.xref.Part1.21">6</a>, <a class="iref" href="#rfc.xref.Part1.22">6.1</a>, <a class="iref" href="#rfc.xref.Part1.23">7.8</a>, <a class="iref" href="#rfc.xref.Part1.24">7.8</a>, <a class="iref" href="#rfc.xref.Part1.25">8.1.1</a>, <a class="iref" href="#rfc.xref.Part1.26">8.1.2</a>, <a class="iref" href="#rfc.xref.Part1.27">8.5.6</a>, <a class="iref" href="#rfc.xref.Part1.28">9.2</a>, <a class="iref" href="#rfc.xref.Part1.29">9.8</a>, <a class="iref" href="#rfc.xref.Part1.30">9.8</a>, <a class="iref" href="#rfc.xref.Part1.31">9.8</a>, <a class="iref" href="#rfc.xref.Part1.32">9.9</a>, <a class="iref" href="#rfc.xref.Part1.33">9.9</a>, <a class="iref" href="#Part1"><b>13.1</b></a>, <a class="iref" href="#rfc.xref.Part1.34">A</a><ul class="ind"> 
     2794                  <li class="indline1"><em>Part1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.1">1</a>, <a class="iref" href="#rfc.xref.Part1.2">1.2</a>, <a class="iref" href="#rfc.xref.Part1.3">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.4">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.5">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.6">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.7">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.8">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.9">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.10">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.11">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.12">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.13">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.14">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.15">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.16">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.17">2</a>, <a class="iref" href="#rfc.xref.Part1.18">2.1.1</a>, <a class="iref" href="#rfc.xref.Part1.19">3</a>, <a class="iref" href="#rfc.xref.Part1.20">3</a>, <a class="iref" href="#rfc.xref.Part1.21">5</a>, <a class="iref" href="#rfc.xref.Part1.22">6</a>, <a class="iref" href="#rfc.xref.Part1.23">6.1</a>, <a class="iref" href="#rfc.xref.Part1.24">7.8</a>, <a class="iref" href="#rfc.xref.Part1.25">7.8</a>, <a class="iref" href="#rfc.xref.Part1.26">8.1.1</a>, <a class="iref" href="#rfc.xref.Part1.27">8.1.2</a>, <a class="iref" href="#rfc.xref.Part1.28">8.5.6</a>, <a class="iref" href="#rfc.xref.Part1.29">9.2</a>, <a class="iref" href="#rfc.xref.Part1.30">9.8</a>, <a class="iref" href="#rfc.xref.Part1.31">9.8</a>, <a class="iref" href="#rfc.xref.Part1.32">9.8</a>, <a class="iref" href="#rfc.xref.Part1.33">9.9</a>, <a class="iref" href="#rfc.xref.Part1.34">9.9</a>, <a class="iref" href="#Part1"><b>13.1</b></a>, <a class="iref" href="#rfc.xref.Part1.35">A</a><ul class="ind"> 
    27932795                        <li class="indline1"><em>Section 1.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.2">1.2</a></li> 
    27942796                        <li class="indline1"><em>Section 1.2.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.3">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.4">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.5">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.6">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.7">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.8">1.2.1</a></li> 
    2795                         <li class="indline1"><em>Section 2.5</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.27">8.5.6</a></li> 
     2797                        <li class="indline1"><em>Section 2.5</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.28">8.5.6</a></li> 
    27962798                        <li class="indline1"><em>Section 2.6</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.9">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.11">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.13">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.16">1.2.2</a></li> 
    2797                         <li class="indline1"><em>Section 3.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.10">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.30">9.8</a>, <a class="iref" href="#rfc.xref.Part1.33">9.9</a></li> 
    2798                         <li class="indline1"><em>Section 3.3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.21">6</a></li> 
    2799                         <li class="indline1"><em>Section 4.3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.17">2</a>, <a class="iref" href="#rfc.xref.Part1.20">5</a>, <a class="iref" href="#rfc.xref.Part1.22">6.1</a></li> 
     2799                        <li class="indline1"><em>Section 3.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.10">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.31">9.8</a>, <a class="iref" href="#rfc.xref.Part1.34">9.9</a></li> 
     2800                        <li class="indline1"><em>Section 3.3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.18">2.1.1</a>, <a class="iref" href="#rfc.xref.Part1.22">6</a></li> 
     2801                        <li class="indline1"><em>Section 4.3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.17">2</a>, <a class="iref" href="#rfc.xref.Part1.21">5</a>, <a class="iref" href="#rfc.xref.Part1.23">6.1</a></li> 
    28002802                        <li class="indline1"><em>Section 6.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.12">1.2.2</a></li> 
    2801                         <li class="indline1"><em>Section 6.3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.14">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.29">9.8</a>, <a class="iref" href="#rfc.xref.Part1.32">9.9</a></li> 
    2802                         <li class="indline1"><em>Section 7.2.3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.25">8.1.1</a>, <a class="iref" href="#rfc.xref.Part1.28">9.2</a></li> 
    2803                         <li class="indline1"><em>Section 9.4</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.18">3</a></li> 
    2804                         <li class="indline1"><em>Section 9.5</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.15">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.19">3</a></li> 
    2805                         <li class="indline1"><em>Section 9.8</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.26">8.1.2</a></li> 
    2806                         <li class="indline1"><em>Section 9.9</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.23">7.8</a>, <a class="iref" href="#rfc.xref.Part1.31">9.8</a>, <a class="iref" href="#rfc.xref.Part1.34">A</a></li> 
    2807                         <li class="indline1"><em>Section 10.3.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.24">7.8</a></li> 
     2803                        <li class="indline1"><em>Section 6.3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.14">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.30">9.8</a>, <a class="iref" href="#rfc.xref.Part1.33">9.9</a></li> 
     2804                        <li class="indline1"><em>Section 7.2.3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.26">8.1.1</a>, <a class="iref" href="#rfc.xref.Part1.29">9.2</a></li> 
     2805                        <li class="indline1"><em>Section 9.4</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.19">3</a></li> 
     2806                        <li class="indline1"><em>Section 9.5</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.15">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.20">3</a></li> 
     2807                        <li class="indline1"><em>Section 9.8</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.27">8.1.2</a></li> 
     2808                        <li class="indline1"><em>Section 9.9</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.24">7.8</a>, <a class="iref" href="#rfc.xref.Part1.32">9.8</a>, <a class="iref" href="#rfc.xref.Part1.35">A</a></li> 
     2809                        <li class="indline1"><em>Section 10.3.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.25">7.8</a></li> 
    28082810                     </ul> 
    28092811                  </li> 
  • draft-ietf-httpbis/latest/p2-semantics.xml

    r1038 r1040  
    494494</t> 
    495495<t> 
    496    New methods &MUST-NOT; prohibit a message-body on either the request or 
    497    the response message; however they &MAY; specify that only a zero-length 
    498    body is allowed. 
     496   Due to the parsing rules defined in &message-body;, definitions of HTTP 
     497   methods cannot prohibit the presence of a message-body on either the request 
     498   or the response message (with responses to HEAD requests being the single 
     499   exception). Definitions of new methods cannot change this rule, but they can 
     500   specify that only zero-length bodies (as opposed to absent bodies) are allowed. 
    499501</t> 
    500502<t> 
Note: See TracChangeset for help on using the changeset viewer.