Ignore:
Timestamp:
Jul 9, 2012, 1:35:28 AM (7 years ago)
Author:
fielding@…
Message:

fix [1682] so that it takes roles into consideration (#361)

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

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/p1-messaging.html

    r1744 r1747  
    449449  }
    450450  @bottom-center {
    451        content: "Expires January 9, 2013";
     451       content: "Expires January 10, 2013";
    452452  }
    453453  @bottom-right {
     
    491491      <meta name="dct.creator" content="Reschke, J. F.">
    492492      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p1-messaging-latest">
    493       <meta name="dct.issued" scheme="ISO8601" content="2012-07-08">
     493      <meta name="dct.issued" scheme="ISO8601" content="2012-07-09">
    494494      <meta name="dct.replaces" content="urn:ietf:rfc:2145">
    495495      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
     
    523523            </tr>
    524524            <tr>
    525                <td class="left">Expires: January 9, 2013</td>
     525               <td class="left">Expires: January 10, 2013</td>
    526526               <td class="right">greenbytes</td>
    527527            </tr>
    528528            <tr>
    529529               <td class="left"></td>
    530                <td class="right">July 8, 2012</td>
     530               <td class="right">July 9, 2012</td>
    531531            </tr>
    532532         </tbody>
     
    561561         in progress”.
    562562      </p>
    563       <p>This Internet-Draft will expire on January 9, 2013.</p>
     563      <p>This Internet-Draft will expire on January 10, 2013.</p>
    564564      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    565565      <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
     
    953953      <p id="rfc.section.2.5.p.1">This specification targets conformance criteria according to the role of a participant in HTTP communication. Hence, HTTP
    954954         requirements are placed on senders, recipients, clients, servers, user agents, intermediaries, origin servers, proxies, gateways,
    955          or caches, depending on what behavior is being constrained by the requirement.
     955         or caches, depending on what behavior is being constrained by the requirement. The verb "generate" is used instead of "send"
     956         where a requirement differentiates between creating a protocol element and merely forwarding a received element downstream.
    956957      </p>
    957958      <p id="rfc.section.2.5.p.2">An implementation is considered conformant if it complies with all of the requirements associated with the roles it partakes
    958959         in HTTP.
    959960      </p>
    960       <p id="rfc.section.2.5.p.3">Senders <em class="bcp14">MUST NOT</em> generate protocol elements that do not match the grammar defined by the ABNF rules for those protocol elements.
    961       </p>
    962       <p id="rfc.section.2.5.p.4">Unless noted otherwise, recipients <em class="bcp14">MUST</em> be able to parse all protocol elements matching the ABNF rules defined for them and <em class="bcp14">MAY</em> attempt to recover a usable protocol element from an invalid construct. HTTP does not define specific error handling mechanisms
     961      <p id="rfc.section.2.5.p.3">A sender <em class="bcp14">MUST NOT</em> generate protocol elements that do not match the grammar defined by the ABNF rules for those protocol elements that are applicable
     962         to the sender's role. If a received protocol element is processed, the recipient <em class="bcp14">MUST</em> be able to parse any value that would match the ABNF rules for that protocol element, excluding only those rules not applicable
     963         to the recipient's role.
     964      </p>
     965      <p id="rfc.section.2.5.p.4">Unless noted otherwise, a recipient <em class="bcp14">MAY</em> attempt to recover a usable protocol element from an invalid construct. HTTP does not define specific error handling mechanisms
    963966         except when they have a direct impact on security, since different applications of the protocol require different error handling
    964967         strategies. For example, a Web browser might wish to transparently recover from a response where the <a href="p2-semantics.html#header.location" class="smpl">Location</a> header field doesn't parse according to the ABNF, whereas a systems control client might consider any form of error recovery
     
    11451148      </p>
    11461149      <div id="rfc.figure.u.12"></div><pre class="inline"><span id="rfc.iref.g.26"></span>  <a href="#http.message" class="smpl">start-line</a>     = <a href="#request.line" class="smpl">request-line</a> / <a href="#status.line" class="smpl">status-line</a>
    1147 </pre><p id="rfc.section.3.1.p.4">Implementations <em class="bcp14">MUST NOT</em> send whitespace between the start-line and the first header field. The presence of such whitespace in a request might be an
     1150</pre><p id="rfc.section.3.1.p.3">Implementations <em class="bcp14">MUST NOT</em> send whitespace between the start-line and the first header field. The presence of such whitespace in a request might be an
    11481151         attempt to trick a server into ignoring that field or processing the line after it as a new request, either of which might
    11491152         result in a security vulnerability if other implementations within the request chain interpret the same message differently.
     
    11551158      </p>
    11561159      <div id="rfc.figure.u.13"></div><pre class="inline"><span id="rfc.iref.g.27"></span>  <a href="#request.line" class="smpl">request-line</a>   = <a href="#method" class="smpl">method</a> <a href="#core.rules" class="smpl">SP</a> <a href="#request-target" class="smpl">request-target</a> <a href="#core.rules" class="smpl">SP</a> <a href="#http.version" class="smpl">HTTP-version</a> <a href="#core.rules" class="smpl">CRLF</a>
    1157 </pre><div id="rfc.iref.m.2"></div>
     1160</pre><p id="rfc.section.3.1.1.p.3">A server <em class="bcp14">MUST</em> be able to parse any received message that begins with a request-line and matches the ABNF rule for HTTP-message.
     1161      </p>
     1162      <div id="rfc.iref.m.2"></div>
    11581163      <div id="method">
    1159          <p id="rfc.section.3.1.1.p.3">The method token indicates the request method to be performed on the target resource. The request method is case-sensitive.</p>
     1164         <p id="rfc.section.3.1.1.p.4">The method token indicates the request method to be performed on the target resource. The request method is case-sensitive.</p>
    11601165      </div>
    11611166      <div id="rfc.figure.u.14"></div><pre class="inline"><span id="rfc.iref.g.28"></span>  <a href="#method" class="smpl">method</a>         = <a href="#rule.token.separators" class="smpl">token</a>
    1162 </pre><p id="rfc.section.3.1.1.p.5">The methods defined by this specification can be found in <a href="p2-semantics.html#methods" title="Methods">Section 2</a> of <a href="#Part2" id="rfc.xref.Part2.4"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>, along with information regarding the HTTP method registry and considerations for defining new methods.
     1167</pre><p id="rfc.section.3.1.1.p.6">The methods defined by this specification can be found in <a href="p2-semantics.html#methods" title="Methods">Section 2</a> of <a href="#Part2" id="rfc.xref.Part2.4"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>, along with information regarding the HTTP method registry and considerations for defining new methods.
    11631168      </p>
    11641169      <div id="rfc.iref.r.6"></div>
    1165       <p id="rfc.section.3.1.1.p.6">The request-target identifies the target resource upon which to apply the request, as defined in <a href="#request-target" title="Request Target">Section&nbsp;5.3</a>.
    1166       </p>
    1167       <p id="rfc.section.3.1.1.p.7">No whitespace is allowed inside the method, request-target, and protocol version. Hence, recipients typically parse the request-line
     1170      <p id="rfc.section.3.1.1.p.7">The request-target identifies the target resource upon which to apply the request, as defined in <a href="#request-target" title="Request Target">Section&nbsp;5.3</a>.
     1171      </p>
     1172      <p id="rfc.section.3.1.1.p.8">No whitespace is allowed inside the method, request-target, and protocol version. Hence, recipients typically parse the request-line
    11681173         into its component parts by splitting on the SP characters.
    11691174      </p>
    1170       <p id="rfc.section.3.1.1.p.8">Unfortunately, some user agents fail to properly encode hypertext references that have embedded whitespace, sending the characters
     1175      <p id="rfc.section.3.1.1.p.9">Unfortunately, some user agents fail to properly encode hypertext references that have embedded whitespace, sending the characters
    11711176         directly instead of properly percent-encoding the disallowed characters. Recipients of an invalid request-line <em class="bcp14">SHOULD</em> respond with either a <a href="p2-semantics.html#status.400" class="smpl">400 (Bad Request)</a> error or a <a href="p2-semantics.html#status.301" class="smpl">301 (Moved Permanently)</a> redirect with the request-target properly encoded. Recipients <em class="bcp14">SHOULD NOT</em> attempt to autocorrect and then process the request without a redirect, since the invalid request-line might be deliberately
    11721177         crafted to bypass security filters along the request chain.
    11731178      </p>
    1174       <p id="rfc.section.3.1.1.p.9">HTTP does not place a pre-defined limit on the length of a request-line. A server that receives a method longer than any that
     1179      <p id="rfc.section.3.1.1.p.10">HTTP does not place a pre-defined limit on the length of a request-line. A server that receives a method longer than any that
    11751180         it implements <em class="bcp14">SHOULD</em> respond with either a <a href="p2-semantics.html#status.405" class="smpl">405 (Method Not Allowed)</a>, if it is an origin server, or a <a href="p2-semantics.html#status.501" class="smpl">501 (Not Implemented)</a> status code. A server <em class="bcp14">MUST</em> be prepared to receive URIs of unbounded length and respond with the <a href="p2-semantics.html#status.414" class="smpl">414 (URI Too Long)</a> status code if the received request-target would be longer than the server wishes to handle (see <a href="p2-semantics.html#status.414" title="414 URI Too Long">Section 4.6.12</a> of <a href="#Part2" id="rfc.xref.Part2.5"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>).
    11761181      </p>
    1177       <p id="rfc.section.3.1.1.p.10">Various ad-hoc limitations on request-line length are found in practice. It is <em class="bcp14">RECOMMENDED</em> that all HTTP senders and recipients support, at a minimum, request-line lengths of up to 8000 octets.
     1182      <p id="rfc.section.3.1.1.p.11">Various ad-hoc limitations on request-line length are found in practice. It is <em class="bcp14">RECOMMENDED</em> that all HTTP senders and recipients support, at a minimum, request-line lengths of up to 8000 octets.
    11781183      </p>
    11791184      <h3 id="rfc.section.3.1.2"><a href="#rfc.section.3.1.2">3.1.2</a>&nbsp;<a id="status.line" href="#status.line">Status Line</a></h3>
     
    11821187      </p>
    11831188      <div id="rfc.figure.u.15"></div><pre class="inline"><span id="rfc.iref.g.29"></span>  <a href="#status.line" class="smpl">status-line</a> = <a href="#http.version" class="smpl">HTTP-version</a> <a href="#core.rules" class="smpl">SP</a> <a href="#status-code" class="smpl">status-code</a> <a href="#core.rules" class="smpl">SP</a> <a href="#reason-phrase" class="smpl">reason-phrase</a> <a href="#core.rules" class="smpl">CRLF</a>
    1184 </pre><div id="status-code">
    1185          <p id="rfc.section.3.1.2.p.3">The status-code element is a 3-digit integer result code of the attempt to understand and satisfy the request. See <a href="p2-semantics.html#status.codes" title="Status Codes">Section 4</a> of <a href="#Part2" id="rfc.xref.Part2.6"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a> for further information, such as the list of status codes defined by this specification, the IANA registry, and considerations
     1189</pre><p id="rfc.section.3.1.2.p.3">A client <em class="bcp14">MUST</em> be able to parse any received message that begins with a status-line and matches the ABNF rule for HTTP-message.
     1190      </p>
     1191      <div id="status-code">
     1192         <p id="rfc.section.3.1.2.p.4">The status-code element is a 3-digit integer result code of the attempt to understand and satisfy the request. See <a href="p2-semantics.html#status.codes" title="Status Codes">Section 4</a> of <a href="#Part2" id="rfc.xref.Part2.6"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a> for further information, such as the list of status codes defined by this specification, the IANA registry, and considerations
    11861193            for new status codes.
    11871194         </p>
     
    11891196      <div id="rfc.figure.u.16"></div><pre class="inline"><span id="rfc.iref.g.30"></span>  <a href="#status-code" class="smpl">status-code</a>    = 3<a href="#core.rules" class="smpl">DIGIT</a>
    11901197</pre><div id="reason-phrase">
    1191          <p id="rfc.section.3.1.2.p.5">The reason-phrase element exists for the sole purpose of providing a textual description associated with the numeric status
     1198         <p id="rfc.section.3.1.2.p.6">The reason-phrase element exists for the sole purpose of providing a textual description associated with the numeric status
    11921199            code, mostly out of deference to earlier Internet application protocols that were more frequently used with interactive text
    11931200            clients. A client <em class="bcp14">SHOULD</em> ignore the reason-phrase content.
     
    13721379      </p>
    13731380      <p id="rfc.section.3.3.p.5">The presence of a message body in a response depends on both the request method to which it is responding and the response
    1374          status code (<a href="#status-code">Paragraph&nbsp;3</a>). Responses to the HEAD request method never include a message body because the associated response header fields (e.g., <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a>, <a href="#header.content-length" class="smpl">Content-Length</a>, etc.) only indicate what their values would have been if the request method had been GET. <a href="p2-semantics.html#status.2xx" class="smpl">2xx (Successful)</a> responses to CONNECT switch to tunnel mode instead of having a message body. All <a href="p2-semantics.html#status.1xx" class="smpl">1xx (Informational)</a>, <a href="p2-semantics.html#status.204" class="smpl">204 (No Content)</a>, and <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> responses <em class="bcp14">MUST NOT</em> include a message body. All other responses do include a message body, although the body <em class="bcp14">MAY</em> be of zero length. (See <a href="p2-semantics.html#status.codes" title="Status Codes">Section 4</a> of <a href="#Part2" id="rfc.xref.Part2.9"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a> and <a href="p4-conditional.html#status.304" title="304 Not Modified">Section 4.1</a> of <a href="#Part4" id="rfc.xref.Part4.1"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>.)
     1381         status code (<a href="#status-code">Paragraph&nbsp;4</a>). Responses to the HEAD request method never include a message body because the associated response header fields (e.g., <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a>, <a href="#header.content-length" class="smpl">Content-Length</a>, etc.) only indicate what their values would have been if the request method had been GET. <a href="p2-semantics.html#status.2xx" class="smpl">2xx (Successful)</a> responses to CONNECT switch to tunnel mode instead of having a message body. All <a href="p2-semantics.html#status.1xx" class="smpl">1xx (Informational)</a>, <a href="p2-semantics.html#status.204" class="smpl">204 (No Content)</a>, and <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> responses <em class="bcp14">MUST NOT</em> include a message body. All other responses do include a message body, although the body <em class="bcp14">MAY</em> be of zero length. (See <a href="p2-semantics.html#status.codes" title="Status Codes">Section 4</a> of <a href="#Part2" id="rfc.xref.Part2.9"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a> and <a href="p4-conditional.html#status.304" title="304 Not Modified">Section 4.1</a> of <a href="#Part4" id="rfc.xref.Part4.1"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>.)
    13751382      </p>
    13761383      <div id="rfc.iref.t.4"></div>
  • draft-ietf-httpbis/latest/p1-messaging.xml

    r1744 r1747  
    600600   on senders, recipients, clients, servers, user agents, intermediaries,
    601601   origin servers, proxies, gateways, or caches, depending on what behavior
    602    is being constrained by the requirement.
     602   is being constrained by the requirement. The verb "generate" is used
     603   instead of "send" where a requirement differentiates between creating a
     604   protocol element and merely forwarding a received element downstream.
    603605</t>
    604606<t>
     
    607609</t>
    608610<t>
    609    Senders &MUST-NOT; generate protocol elements that do not match the grammar
    610    defined by the ABNF rules for those protocol elements.
    611 </t>
    612 <t>
    613    Unless noted otherwise, recipients &MUST; be able to parse all protocol
    614    elements matching the ABNF rules defined for them and &MAY; attempt to recover a usable
     611   A sender &MUST-NOT; generate protocol elements that do not match
     612   the grammar defined by the ABNF rules for those protocol elements that
     613   are applicable to the sender's role.
     614   If a received protocol element is processed, the recipient &MUST; be able
     615   to parse any value that would match the ABNF rules for that protocol
     616   element, excluding only those rules not applicable to the recipient's role.
     617</t>
     618<t>
     619   Unless noted otherwise, a recipient &MAY; attempt to recover a usable
    615620   protocol element from an invalid construct.  HTTP does not define
    616621   specific error handling mechanisms except when they have a direct impact
     
    10191024</artwork></figure>
    10201025<t>
    1021 </t>
    1022 <t>
    10231026   Implementations &MUST-NOT; send whitespace between the start-line and
    10241027   the first header field. The presence of such whitespace in a request
     
    10421045  <x:ref>request-line</x:ref>   = <x:ref>method</x:ref> <x:ref>SP</x:ref> <x:ref>request-target</x:ref> <x:ref>SP</x:ref> <x:ref>HTTP-version</x:ref> <x:ref>CRLF</x:ref>
    10431046</artwork></figure>
     1047<t>
     1048   A server &MUST; be able to parse any received message that begins
     1049   with a request-line and matches the ABNF rule for HTTP-message.
     1050</t>
    10441051<iref primary="true" item="method"/>
    10451052<t anchor="method">
     
    11051112  <x:ref>status-line</x:ref> = <x:ref>HTTP-version</x:ref> <x:ref>SP</x:ref> <x:ref>status-code</x:ref> <x:ref>SP</x:ref> <x:ref>reason-phrase</x:ref> <x:ref>CRLF</x:ref>
    11061113</artwork></figure>
     1114<t>
     1115   A client &MUST; be able to parse any received message that begins
     1116   with a status-line and matches the ABNF rule for HTTP-message.
     1117</t>
    11071118
    11081119<t anchor="status-code">
Note: See TracChangeset for help on using the changeset viewer.