Changeset 1875


Ignore:
Timestamp:
Sep 9, 2012, 7:46:17 PM (7 years ago)
Author:
fielding@…
Message:

Be more consistent regarding targeting conformance requirements.
Only define conformance criteria once, but repeat required nits.

Remove antiquated requirement about media type parameters not being
recognized by 1993-era browsers.

Add reference to TLS in p1.

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

Legend:

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

    r1874 r1875  
    898898         for some type(s) of absolute URI and attempt to satisfy those requests via translation through the HTTP interface. Some translations
    899899         are minimal, such as for proxy requests for "http" URIs, whereas other requests might require translation to and from entirely
    900          different application-layer protocols. Proxies are often used to group an organization's HTTP requests through a common intermediary
     900         different application-level protocols. Proxies are often used to group an organization's HTTP requests through a common intermediary
    901901         for the sake of security, annotation services, or shared caching.
    902902      </p>
     
    921921         to the HTTP communication, though the tunnel might have been initiated by an HTTP request. A tunnel ceases to exist when both
    922922         ends of the relayed connection are closed. Tunnels are used to extend a virtual connection through an intermediary, such as
    923          when transport-layer security is used to establish confidential communication through a shared firewall proxy.
     923         when Transport Layer Security (TLS, <a href="#RFC5246" id="rfc.xref.RFC5246.1"><cite title="The Transport Layer Security (TLS) Protocol Version 1.2">[RFC5246]</cite></a>) is used to establish confidential communication through a shared firewall proxy.
    924924      </p>
    925925      <p id="rfc.section.2.3.p.10"><span id="rfc.iref.i.3"></span>  <span id="rfc.iref.t.3"></span>  <span id="rfc.iref.c.3"></span> The above categories for intermediary only consider those acting as participants in the HTTP communication. There are also
     
    961961      <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
    962962         requirements are placed on senders, recipients, clients, servers, user agents, intermediaries, origin servers, proxies, gateways,
    963          or caches, depending on what behavior is being constrained by the requirement.
     963         or caches, depending on what behavior is being constrained by the requirement. Additional (social) requirements are placed
     964         on implementations, resource owners, and protocol element registrations when they apply beyond the scope of a single communication.
    964965      </p>
    965966      <p id="rfc.section.2.5.p.2">The verb "generate" is used instead of "send" where a requirement differentiates between creating a protocol element and merely
     
    11581159      </p>
    11591160      <div id="rfc.figure.u.12"></div><pre class="inline"><span id="rfc.iref.g.27"></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>
    1160 </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
     1161</pre><p id="rfc.section.3.1.p.3">A sender <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
    11611162         attempt to trick a server into ignoring that field or processing the line after it as a new request, either of which might
    11621163         result in a security vulnerability if other implementations within the request chain interpret the same message differently.
     
    14731474      </ol>
    14741475      <p id="rfc.section.3.3.3.p.3">Since there is no way to distinguish a successfully completed, close-delimited message from a partially-received message interrupted
    1475          by network failure, implementations <em class="bcp14">SHOULD</em> use encoding or length-delimited messages whenever possible. The close-delimiting feature exists primarily for backwards compatibility
     1476         by network failure, a server <em class="bcp14">SHOULD</em> use encoding or length-delimited messages whenever possible. The close-delimiting feature exists primarily for backwards compatibility
    14761477         with HTTP/1.0.
    14771478      </p>
     
    21382139      </p>
    21392140      <p id="rfc.section.6.3.p.6">Upgrade cannot be used to insist on a protocol change; its acceptance and use by the server is optional. The capabilities
    2140          and nature of the application-layer communication after the protocol change is entirely dependent upon the new protocol chosen,
     2141         and nature of the application-level communication after the protocol change is entirely dependent upon the new protocol chosen,
    21412142         although the first action after changing the protocol <em class="bcp14">MUST</em> be a response to the initial HTTP request that contained the Upgrade header field.
    21422143      </p>
     
    21492150         that might not implement the listed protocols. A server <em class="bcp14">MUST</em> ignore an Upgrade header field that is received in an HTTP/1.0 request.
    21502151      </p>
    2151       <p id="rfc.section.6.3.p.9">The Upgrade header field only applies to switching application-layer protocols on the existing transport-layer connection;
    2152          it cannot be used to switch to a protocol on a different connection. For that purpose, it is more appropriate to use a <a href="p2-semantics.html#status.3xx" class="smpl">3xx (Redirection)</a> response (<a href="p2-semantics.html#status.3xx" title="Redirection 3xx">Section 7.4</a> of <a href="#Part2" id="rfc.xref.Part2.24"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>).
     2152      <p id="rfc.section.6.3.p.9">The Upgrade header field only applies to switching application-level protocols on the existing connection; it cannot be used
     2153         to switch to a protocol on a different connection. For that purpose, it is more appropriate to use a <a href="p2-semantics.html#status.3xx" class="smpl">3xx (Redirection)</a> response (<a href="p2-semantics.html#status.3xx" title="Redirection 3xx">Section 7.4</a> of <a href="#Part2" id="rfc.xref.Part2.24"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>).
    21532154      </p>
    21542155      <p id="rfc.section.6.3.p.10">This specification only defines the protocol name "HTTP" for use by the family of Hypertext Transfer Protocols, as defined
     
    25332534      </p>
    25342535      <h2 id="rfc.section.8.3"><a href="#rfc.section.8.3">8.3</a>&nbsp;<a id="attack.pathname" href="#attack.pathname">Attacks Based On File and Path Names</a></h2>
    2535       <p id="rfc.section.8.3.p.1">Implementations of HTTP origin servers <em class="bcp14">SHOULD</em> be careful to restrict the documents returned by HTTP requests to be only those that were intended by the server administrators.
     2536      <p id="rfc.section.8.3.p.1">Origin servers <em class="bcp14">SHOULD</em> be careful to restrict the documents returned by HTTP requests to be only those that were intended by the server administrators.
    25362537         If an HTTP server translates HTTP URIs directly into file system calls, the server <em class="bcp14">MUST</em> take special care not to serve files that were not intended to be delivered to HTTP clients. For example, UNIX, Microsoft
    25372538         Windows, and other operating systems use ".." as a path component to indicate a directory level above the current one. On
    25382539         such a system, an HTTP server <em class="bcp14">MUST</em> disallow any such construct in the request-target if it would otherwise allow access to a resource outside those intended
    25392540         to be accessible via the HTTP server. Similarly, files intended for reference only internally to the server (such as access
    2540          control files, configuration files, and script code) <em class="bcp14">MUST</em> be protected from inappropriate retrieval, since they might contain sensitive information. Experience has shown that minor
    2541          bugs in such HTTP server implementations have turned into security risks.
     2541         control files, configuration files, and script code) <em class="bcp14">MUST</em> be protected from inappropriate retrieval, since they might contain sensitive information.
    25422542      </p>
    25432543      <h2 id="rfc.section.8.4"><a href="#rfc.section.8.4">8.4</a>&nbsp;<a id="dns.related.attacks" href="#dns.related.attacks">DNS-related Attacks</a></h2>
     
    25692569      <p id="rfc.section.8.6.p.3">This specification also provides a way for servers to reject messages that have request-targets that are too long (<a href="p2-semantics.html#status.414" title="414 URI Too Long">Section 7.5.12</a> of <a href="#Part2" id="rfc.xref.Part2.26"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) or request entities that are too large (<a href="p2-semantics.html#status.4xx" title="Client Error 4xx">Section 7.5</a> of <a href="#Part2" id="rfc.xref.Part2.27"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>).
    25702570      </p>
    2571       <p id="rfc.section.8.6.p.4">Other fields (including but not limited to request methods, response status phrases, header field-names, and body chunks) <em class="bcp14">SHOULD</em> be limited by implementations carefully, so as to not impede interoperability.
     2571      <p id="rfc.section.8.6.p.4">Recipients <em class="bcp14">SHOULD</em> carefully limit the extent to which they read other fields, including (but not limited to) request methods, response status
     2572         phrases, header field-names, and body chunks, so as to avoid denial of service attacks without impeding interoperability.
    25722573      </p>
    25732574      <h1 id="rfc.section.9"><a href="#rfc.section.9">9.</a>&nbsp;<a id="acks" href="#acks">Acknowledgments</a></h1>
     
    26772678      <h2 id="rfc.references.2"><a href="#rfc.section.10.2" id="rfc.section.10.2">10.2</a> Informative References
    26782679      </h2>
    2679       <table>                                           
     2680      <table>                                             
    26802681         <tr>
    26812682            <td class="reference"><b id="ISO-8859-1">[ISO-8859-1]</b></td>
     
    27702771            <td class="reference"><b id="RFC5226">[RFC5226]</b></td>
    27712772            <td class="top"><a href="mailto:narten@us.ibm.com" title="IBM">Narten, T.</a> and <a href="mailto:Harald@Alvestrand.no" title="Google">H. Alvestrand</a>, “<a href="http://tools.ietf.org/html/rfc5226">Guidelines for Writing an IANA Considerations Section in RFCs</a>”, BCP&nbsp;26, RFC&nbsp;5226, May&nbsp;2008.
     2773            </td>
     2774         </tr>
     2775         <tr>
     2776            <td class="reference"><b id="RFC5246">[RFC5246]</b></td>
     2777            <td class="top">Dierks, T. and E. Rescorla, “<a href="http://tools.ietf.org/html/rfc5246">The Transport Layer Security (TLS) Protocol Version 1.2</a>”, RFC&nbsp;5246, August&nbsp;2008.
    27722778            </td>
    27732779         </tr>
     
    37513757                     </ul>
    37523758                  </li>
     3759                  <li><em>RFC5246</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5246.1">2.3</a>, <a href="#RFC5246"><b>10.2</b></a></li>
    37533760                  <li><em>RFC5322</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5322.1">2.1</a>, <a href="#rfc.xref.RFC5322.2">3</a>, <a href="#rfc.xref.RFC5322.3">5.7</a>, <a href="#RFC5322"><b>10.2</b></a><ul>
    37543761                        <li><em>Section 3.6.7</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5322.3">5.7</a></li>
  • draft-ietf-httpbis/latest/p1-messaging.xml

    r1874 r1875  
    478478   are minimal, such as for proxy requests for "http" URIs, whereas
    479479   other requests might require translation to and from entirely different
    480    application-layer protocols. Proxies are often used to group an
     480   application-level protocols. Proxies are often used to group an
    481481   organization's HTTP requests through a common intermediary for the
    482482   sake of security, annotation services, or shared caching.
     
    533533   both ends of the relayed connection are closed. Tunnels are used to
    534534   extend a virtual connection through an intermediary, such as when
    535    transport-layer security is used to establish confidential communication
    536    through a shared firewall proxy.
     535   Transport Layer Security (TLS, <xref target="RFC5246"/>) is used to
     536   establish confidential communication through a shared firewall proxy.
    537537</t>
    538538<t><iref primary="true" item="interception proxy"/>
     
    617617   on senders, recipients, clients, servers, user agents, intermediaries,
    618618   origin servers, proxies, gateways, or caches, depending on what behavior
    619    is being constrained by the requirement.
     619   is being constrained by the requirement. Additional (social) requirements
     620   are placed on implementations, resource owners, and protocol element
     621   registrations when they apply beyond the scope of a single communication.
    620622</t>
    621623<t>
     
    10491051</artwork></figure>
    10501052<t>
    1051    Implementations &MUST-NOT; send whitespace between the start-line and
     1053   A sender &MUST-NOT; send whitespace between the start-line and
    10521054   the first header field. The presence of such whitespace in a request
    10531055   might be an attempt to trick a server into ignoring that field or
     
    17091711   Since there is no way to distinguish a successfully completed,
    17101712   close-delimited message from a partially-received message interrupted
    1711    by network failure, implementations &SHOULD; use encoding or
     1713   by network failure, a server &SHOULD; use encoding or
    17121714   length-delimited messages whenever possible.  The close-delimiting
    17131715   feature exists primarily for backwards compatibility with HTTP/1.0.
     
    30973099   Upgrade cannot be used to insist on a protocol change; its acceptance and
    30983100   use by the server is optional. The capabilities and nature of the
    3099    application-layer communication after the protocol change is entirely
     3101   application-level communication after the protocol change is entirely
    31003102   dependent upon the new protocol chosen, although the first action
    31013103   after changing the protocol &MUST; be a response to the initial HTTP
     
    31223124</t>
    31233125<t>
    3124    The Upgrade header field only applies to switching application-layer
    3125    protocols on the existing transport-layer connection; it cannot be used
     3126   The Upgrade header field only applies to switching application-level
     3127   protocols on the existing connection; it cannot be used
    31263128   to switch to a protocol on a different connection. For that purpose, it is
    31273129   more appropriate to use a <x:ref>3xx (Redirection)</x:ref> response
     
    35823584<section title="Attacks Based On File and Path Names" anchor="attack.pathname">
    35833585<t>
    3584    Implementations of HTTP origin servers &SHOULD; be careful to restrict
     3586   Origin servers &SHOULD; be careful to restrict
    35853587   the documents returned by HTTP requests to be only those that were
    35863588   intended by the server administrators. If an HTTP server translates
     
    35963598   files, configuration files, and script code) &MUST; be protected from
    35973599   inappropriate retrieval, since they might contain sensitive
    3598    information. Experience has shown that minor bugs in such HTTP server
    3599    implementations have turned into security risks.
     3600   information.
    36003601</t>
    36013602</section>
     
    36613662</t>
    36623663<t>
    3663    Other fields (including but not limited to request methods, response status
    3664    phrases, header field-names, and body chunks) &SHOULD; be limited by
    3665    implementations carefully, so as to not impede interoperability.
     3664   Recipients &SHOULD; carefully limit the extent to which they read other
     3665   fields, including (but not limited to) request methods, response status
     3666   phrases, header field-names, and body chunks, so as to avoid denial of
     3667   service attacks without impeding interoperability.
    36663668</t>
    36673669</section>
     
    45574559</reference>
    45584560
     4561<reference anchor='RFC5246'>
     4562   <front>
     4563      <title>The Transport Layer Security (TLS) Protocol Version 1.2</title>
     4564      <author initials='T.' surname='Dierks' fullname='T. Dierks'>
     4565         <organization />
     4566      </author>
     4567      <author initials='E.' surname='Rescorla' fullname='E. Rescorla'>
     4568         <organization>RTFM, Inc.</organization>
     4569      </author>
     4570      <date year='2008' month='August' />
     4571   </front>
     4572   <seriesInfo name='RFC' value='5246' />
     4573</reference>
     4574
    45594575<reference anchor="RFC5322">
    45604576  <front>
  • draft-ietf-httpbis/latest/p2-semantics.html

    r1873 r1875  
    15681568      <div id="rfc.iref.t.1"></div>
    15691569      <div id="rfc.iref.m.8"></div>
    1570       <p id="rfc.section.5.3.8.p.1">The TRACE method requests a remote, application-layer loop-back of the request message. The final recipient of the request <em class="bcp14">SHOULD</em> reflect the message received back to the client as the message body of a <a href="#status.200" class="smpl">200 (OK)</a> response. The final recipient is either the origin server or the first proxy to receive a <a href="#header.max-forwards" class="smpl">Max-Forwards</a> value of zero (0) in the request (see <a href="#header.max-forwards" id="rfc.xref.header.max-forwards.2" title="Max-Forwards">Section&nbsp;6.1.1</a>). A TRACE request <em class="bcp14">MUST NOT</em> include a message body.
     1570      <p id="rfc.section.5.3.8.p.1">The TRACE method requests a remote, application-level loop-back of the request message. The final recipient of the request <em class="bcp14">SHOULD</em> reflect the message received back to the client as the message body of a <a href="#status.200" class="smpl">200 (OK)</a> response. The final recipient is either the origin server or the first proxy to receive a <a href="#header.max-forwards" class="smpl">Max-Forwards</a> value of zero (0) in the request (see <a href="#header.max-forwards" id="rfc.xref.header.max-forwards.2" title="Max-Forwards">Section&nbsp;6.1.1</a>). A TRACE request <em class="bcp14">MUST NOT</em> include a message body.
    15711571      </p>
    15721572      <p id="rfc.section.5.3.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
     
    31663166      <p id="rfc.section.9.5.p.6">A parameter value that matches the <a href="#imported.abnf" class="smpl">token</a> production can be transmitted as either a token or within a quoted-string. The quoted and unquoted values are equivalent.
    31673167      </p>
    3168       <p id="rfc.section.9.5.p.7">Note that some older HTTP applications do not recognize media type parameters. When sending data to older HTTP applications,
    3169          implementations <em class="bcp14">SHOULD</em> only use media type parameters when they are required by that type/subtype definition.
    3170       </p>
    3171       <p id="rfc.section.9.5.p.8">Media-type values are registered with the Internet Assigned Number Authority (IANA). The media type registration process is
     3168      <p id="rfc.section.9.5.p.7">Media-type values are registered with the Internet Assigned Number Authority (IANA). The media type registration process is
    31723169         outlined in <a href="#RFC4288" id="rfc.xref.RFC4288.1"><cite title="Media Type Specifications and Registration Procedures">[RFC4288]</cite></a>. Use of non-registered media types is discouraged.
    31733170      </p>
     
    31873184      <h3 id="rfc.section.9.5.2"><a href="#rfc.section.9.5.2">9.5.2</a>&nbsp;<a id="multipart.types" href="#multipart.types">Multipart Types</a></h3>
    31883185      <p id="rfc.section.9.5.2.p.1">MIME provides for a number of "multipart" types — encapsulations of one or more representations within a single message body.
    3189          All multipart types share a common syntax, as defined in <a href="http://tools.ietf.org/html/rfc2046#section-5.1.1">Section 5.1.1</a> of <a href="#RFC2046" id="rfc.xref.RFC2046.3"><cite title="Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types">[RFC2046]</cite></a>, and <em class="bcp14">MUST</em> include a boundary parameter as part of the media type value. The message body is itself a protocol element and <em class="bcp14">MUST</em> therefore use only CRLF to represent line breaks between body-parts.
     3186         All multipart types share a common syntax, as defined in <a href="http://tools.ietf.org/html/rfc2046#section-5.1.1">Section 5.1.1</a> of <a href="#RFC2046" id="rfc.xref.RFC2046.3"><cite title="Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types">[RFC2046]</cite></a>, and include a boundary parameter as part of the media type value. The message body is itself a protocol element; a sender <em class="bcp14">MUST</em> generate only CRLF to represent line breaks between body-parts.
    31903187      </p>
    31913188      <p id="rfc.section.9.5.2.p.2">In general, HTTP treats a multipart message body no differently than any other media type: strictly as payload. HTTP does
     
    31933190         each body-part of a multipart message body do not have any significance to HTTP beyond that defined by their MIME semantics.
    31943191      </p>
    3195       <p id="rfc.section.9.5.2.p.3">If an application receives an unrecognized multipart subtype, the application <em class="bcp14">MUST</em> treat it as being equivalent to "multipart/mixed".
     3192      <p id="rfc.section.9.5.2.p.3">A recipient <em class="bcp14">MUST</em> treat an unrecognized multipart subtype as being equivalent to "multipart/mixed".
    31963193      </p>
    31973194      <div class="note" id="rfc.section.9.5.2.p.4">
  • draft-ietf-httpbis/latest/p2-semantics.xml

    r1868 r1875  
    15311531  <iref primary="true" item="Methods" subitem="TRACE" x:for-anchor=""/>
    15321532<t>
    1533    The TRACE method requests a remote, application-layer loop-back
     1533   The TRACE method requests a remote, application-level loop-back
    15341534   of the request message. The final recipient of the request
    15351535   &SHOULD; reflect the message received back to the client as the message body
     
    39603960</t>
    39613961<t>
    3962    Note that some older HTTP applications do not recognize media type
    3963    parameters. When sending data to older HTTP applications,
    3964    implementations &SHOULD; only use media type parameters when they are
    3965    required by that type/subtype definition.
    3966 </t>
    3967 <t>
    39683962   Media-type values are registered with the Internet Assigned Number
    39693963   Authority (IANA). The media type registration process is
     
    40064000   one or more representations within a single message body. All multipart
    40074001   types share a common syntax, as defined in <xref target="RFC2046" x:sec="5.1.1" x:fmt="of"/>,
    4008    and &MUST; include a boundary parameter as part of the media type
    4009    value. The message body is itself a protocol element and &MUST;
    4010    therefore use only CRLF to represent line breaks between body-parts.
     4002   and include a boundary parameter as part of the media type
     4003   value. The message body is itself a protocol element; a sender &MUST;
     4004   generate only CRLF to represent line breaks between body-parts.
    40114005</t>
    40124006<t>
     
    40224016</t>
    40234017<t>
    4024    If an application receives an unrecognized multipart subtype, the
    4025    application &MUST; treat it as being equivalent to "multipart/mixed".
     4018   A recipient &MUST; treat an unrecognized multipart subtype
     4019   as being equivalent to "multipart/mixed".
    40264020</t>
    40274021<x:note>
  • draft-ietf-httpbis/latest/p4-conditional.html

    r1873 r1875  
    573573      <ul class="toc">
    574574         <li><a href="#rfc.section.1">1.</a>&nbsp;&nbsp;&nbsp;<a href="#introduction">Introduction</a><ul>
    575                <li><a href="#rfc.section.1.1">1.1</a>&nbsp;&nbsp;&nbsp;<a href="#intro.conformance.and.error.handling">Conformance and Error Handling</a></li>
     575               <li><a href="#rfc.section.1.1">1.1</a>&nbsp;&nbsp;&nbsp;<a href="#conformance">Conformance and Error Handling</a></li>
    576576               <li><a href="#rfc.section.1.2">1.2</a>&nbsp;&nbsp;&nbsp;<a href="#notation">Syntax Notation</a></li>
    577577            </ul>
     
    651651         selected representation.
    652652      </p>
    653       <h2 id="rfc.section.1.1"><a href="#rfc.section.1.1">1.1</a>&nbsp;<a id="intro.conformance.and.error.handling" href="#intro.conformance.and.error.handling">Conformance and Error Handling</a></h2>
     653      <h2 id="rfc.section.1.1"><a href="#rfc.section.1.1">1.1</a>&nbsp;<a id="conformance" href="#conformance">Conformance and Error Handling</a></h2>
    654654      <p id="rfc.section.1.1.p.1">The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"
    655655         in this document are to be interpreted as described in <a href="#RFC2119" id="rfc.xref.RFC2119.1"><cite title="Key words for use in RFCs to Indicate Requirement Levels">[RFC2119]</cite></a>.
    656656      </p>
    657       <p id="rfc.section.1.1.p.2">This specification targets conformance criteria according to the role of a participant in HTTP communication. Hence, HTTP
    658          requirements are placed on senders, recipients, clients, servers, user agents, intermediaries, origin servers, proxies, gateways,
    659          or caches, depending on what behavior is being constrained by the requirement. See <a href="p1-messaging.html#architecture" title="Architecture">Section 2</a> of <a href="#Part1" id="rfc.xref.Part1.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a> for definitions of these terms.
    660       </p>
    661       <p id="rfc.section.1.1.p.3">The verb "generate" is used instead of "send" where a requirement differentiates between creating a protocol element and merely
    662          forwarding a received element downstream.
    663       </p>
    664       <p id="rfc.section.1.1.p.4">An implementation is considered conformant if it complies with all of the requirements associated with the roles it partakes
    665          in HTTP. Note that SHOULD-level requirements are relevant here, unless one of the documented exceptions is applicable.
    666       </p>
    667       <p id="rfc.section.1.1.p.5">This document also uses ABNF to define valid protocol elements (<a href="#notation" title="Syntax Notation">Section&nbsp;1.2</a>). In addition to the prose requirements placed upon them, 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 that are applicable
    668          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
    669          to the recipient's role.
    670       </p>
    671       <p id="rfc.section.1.1.p.6">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
    672          except when they have a direct impact on security, since different applications of the protocol require different error handling
    673          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
    674          to be dangerous.
     657      <p id="rfc.section.1.1.p.2">Conformance criteria and considerations regarding error handling are defined in <a href="p1-messaging.html#conformance" title="Conformance and Error Handling">Section 2.5</a> of <a href="#Part1" id="rfc.xref.Part1.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>.
    675658      </p>
    676659      <h2 id="rfc.section.1.2"><a href="#rfc.section.1.2">1.2</a>&nbsp;<a id="notation" href="#notation">Syntax Notation</a></h2>
     
    14631446                  <li><em>Part1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.1">1</a>, <a href="#rfc.xref.Part1.2">1.1</a>, <a href="#rfc.xref.Part1.3">1.2</a>, <a href="#rfc.xref.Part1.4">2.3.3</a>, <a href="#rfc.xref.Part1.5">7</a>, <a href="#rfc.xref.Part1.6">8</a>, <a href="#Part1"><b>9.1</b></a>, <a href="#rfc.xref.Part1.7">B</a>, <a href="#rfc.xref.Part1.8">B</a>, <a href="#rfc.xref.Part1.9">B</a><ul>
    14641447                        <li><em>Section 1.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.3">1.2</a></li>
    1465                         <li><em>Section 2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.2">1.1</a></li>
     1448                        <li><em>Section 2.5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.2">1.1</a></li>
    14661449                        <li><em>Section 3.2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.8">B</a></li>
    14671450                        <li><em>Section 3.2.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.9">B</a></li>
  • draft-ietf-httpbis/latest/p4-conditional.xml

    r1867 r1875  
    1717  <!ENTITY Note "<x:h xmlns:x='http://purl.org/net/xml2rfc/ext'>Note:</x:h>">
    1818  <!ENTITY architecture               "<xref target='Part1' x:rel='#architecture' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
     19  <!ENTITY conformance                "<xref target='Part1' x:rel='#conformance' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    1920  <!ENTITY notation                   "<xref target='Part1' x:rel='#notation' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    2021  <!ENTITY abnf-extension             "<xref target='Part1' x:rel='#abnf.extension' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
     
    172173</t>
    173174
    174 <section title="Conformance and Error Handling" anchor="intro.conformance.and.error.handling">
     175<section title="Conformance and Error Handling" anchor="conformance">
    175176<t>
    176177   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
     
    179180</t>
    180181<t>
    181    This specification targets conformance criteria according to the role of
    182    a participant in HTTP communication.  Hence, HTTP requirements are placed
    183    on senders, recipients, clients, servers, user agents, intermediaries,
    184    origin servers, proxies, gateways, or caches, depending on what behavior
    185    is being constrained by the requirement. See &architecture; for definitions
    186    of these terms.
    187 </t>
    188 <t>
    189    The verb "generate" is used instead of "send" where a requirement
    190    differentiates between creating a protocol element and merely forwarding a
    191    received element downstream.
    192 </t>
    193 <t>
    194    An implementation is considered conformant if it complies with all of the
    195    requirements associated with the roles it partakes in HTTP. Note that
    196    SHOULD-level requirements are relevant here, unless one of the documented
    197    exceptions is applicable.
    198 </t>
    199 <t>
    200    This document also uses ABNF to define valid protocol elements
    201    (<xref target="notation"/>).
    202    In addition to the prose requirements placed upon them, senders &MUST-NOT;
    203    generate protocol elements that do not match the grammar defined by the
    204    ABNF rules for those protocol elements that are applicable to the sender's
    205    role. If a received protocol element is processed, the recipient &MUST; be
    206    able to parse any value that would match the ABNF rules for that protocol
    207    element, excluding only those rules not applicable to the recipient's role.
    208 </t>
    209 <t>
    210    Unless noted otherwise, a recipient &MAY; attempt to recover a usable
    211    protocol element from an invalid construct.  HTTP does not define
    212    specific error handling mechanisms except when they have a direct impact
    213    on security, since different applications of the protocol require
    214    different error handling strategies.  For example, a Web browser might
    215    wish to transparently recover from a response where the
    216    <x:ref>Location</x:ref> header field doesn't parse according to the ABNF,
    217    whereas a systems control client might consider any form of error recovery
    218    to be dangerous.
     182   Conformance criteria and considerations regarding error handling
     183   are defined in &conformance;.
    219184</t>
    220185</section>
  • draft-ietf-httpbis/latest/p5-range.html

    r1873 r1875  
    572572      <ul class="toc">
    573573         <li><a href="#rfc.section.1">1.</a>&nbsp;&nbsp;&nbsp;<a href="#introduction">Introduction</a><ul>
    574                <li><a href="#rfc.section.1.1">1.1</a>&nbsp;&nbsp;&nbsp;<a href="#intro.conformance.and.error.handling">Conformance and Error Handling</a></li>
     574               <li><a href="#rfc.section.1.1">1.1</a>&nbsp;&nbsp;&nbsp;<a href="#conformance">Conformance and Error Handling</a></li>
    575575               <li><a href="#rfc.section.1.2">1.2</a>&nbsp;&nbsp;&nbsp;<a href="#notation">Syntax Notation</a></li>
    576576            </ul>
     
    644644         requests for byte ranges.
    645645      </p>
    646       <h2 id="rfc.section.1.1"><a href="#rfc.section.1.1">1.1</a>&nbsp;<a id="intro.conformance.and.error.handling" href="#intro.conformance.and.error.handling">Conformance and Error Handling</a></h2>
     646      <h2 id="rfc.section.1.1"><a href="#rfc.section.1.1">1.1</a>&nbsp;<a id="conformance" href="#conformance">Conformance and Error Handling</a></h2>
    647647      <p id="rfc.section.1.1.p.1">The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"
    648648         in this document are to be interpreted as described in <a href="#RFC2119" id="rfc.xref.RFC2119.1"><cite title="Key words for use in RFCs to Indicate Requirement Levels">[RFC2119]</cite></a>.
    649649      </p>
    650       <p id="rfc.section.1.1.p.2">This specification targets conformance criteria according to the role of a participant in HTTP communication. Hence, HTTP
    651          requirements are placed on senders, recipients, clients, servers, user agents, intermediaries, origin servers, proxies, gateways,
    652          or caches, depending on what behavior is being constrained by the requirement. See <a href="p1-messaging.html#architecture" title="Architecture">Section 2</a> of <a href="#Part1" id="rfc.xref.Part1.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a> for definitions of these terms.
    653       </p>
    654       <p id="rfc.section.1.1.p.3">The verb "generate" is used instead of "send" where a requirement differentiates between creating a protocol element and merely
    655          forwarding a received element downstream.
    656       </p>
    657       <p id="rfc.section.1.1.p.4">An implementation is considered conformant if it complies with all of the requirements associated with the roles it partakes
    658          in HTTP. Note that SHOULD-level requirements are relevant here, unless one of the documented exceptions is applicable.
    659       </p>
    660       <p id="rfc.section.1.1.p.5">This document also uses ABNF to define valid protocol elements (<a href="#notation" title="Syntax Notation">Section&nbsp;1.2</a>). In addition to the prose requirements placed upon them, 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 that are applicable
    661          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
    662          to the recipient's role.
    663       </p>
    664       <p id="rfc.section.1.1.p.6">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
    665          except when they have a direct impact on security, since different applications of the protocol require different error handling
    666          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
    667          to be dangerous.
     650      <p id="rfc.section.1.1.p.2">Conformance criteria and considerations regarding error handling are defined in <a href="p1-messaging.html#conformance" title="Conformance and Error Handling">Section 2.5</a> of <a href="#Part1" id="rfc.xref.Part1.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>.
    668651      </p>
    669652      <h2 id="rfc.section.1.2"><a href="#rfc.section.1.2">1.2</a>&nbsp;<a id="notation" href="#notation">Syntax Notation</a></h2>
     
    14131396                  <li><em>Part1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.1">1.1</a>, <a href="#rfc.xref.Part1.2">1.2</a>, <a href="#rfc.xref.Part1.3">8</a>, <a href="#Part1"><b>9.1</b></a>, <a href="#rfc.xref.Part1.4">C</a>, <a href="#rfc.xref.Part1.5">C</a>, <a href="#rfc.xref.Part1.6">C</a><ul>
    14141397                        <li><em>Section 1.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.2">1.2</a></li>
    1415                         <li><em>Section 2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.1">1.1</a></li>
     1398                        <li><em>Section 2.5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.1">1.1</a></li>
    14161399                        <li><em>Section 3.2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.5">C</a></li>
    14171400                        <li><em>Section 3.2.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.6">C</a></li>
  • draft-ietf-httpbis/latest/p5-range.xml

    r1867 r1875  
    1717  <!ENTITY Note "<x:h xmlns:x='http://purl.org/net/xml2rfc/ext'>Note:</x:h>">
    1818  <!ENTITY architecture               "<xref target='Part1' x:rel='#architecture' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
     19  <!ENTITY conformance                "<xref target='Part1' x:rel='#conformance' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    1920  <!ENTITY notation                   "<xref target='Part1' x:rel='#notation' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    2021  <!ENTITY abnf-extension             "<xref target='Part1' x:rel='#abnf.extension' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
     
    153154</t>
    154155
    155 <section title="Conformance and Error Handling" anchor="intro.conformance.and.error.handling">
     156<section title="Conformance and Error Handling" anchor="conformance">
    156157<t>
    157158   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
     
    160161</t>
    161162<t>
    162    This specification targets conformance criteria according to the role of
    163    a participant in HTTP communication.  Hence, HTTP requirements are placed
    164    on senders, recipients, clients, servers, user agents, intermediaries,
    165    origin servers, proxies, gateways, or caches, depending on what behavior
    166    is being constrained by the requirement. See &architecture; for definitions
    167    of these terms.
    168 </t>
    169 <t>
    170    The verb "generate" is used instead of "send" where a requirement
    171    differentiates between creating a protocol element and merely forwarding a
    172    received element downstream.
    173 </t>
    174 <t>
    175    An implementation is considered conformant if it complies with all of the
    176    requirements associated with the roles it partakes in HTTP. Note that
    177    SHOULD-level requirements are relevant here, unless one of the documented
    178    exceptions is applicable.
    179 </t>
    180 <t>
    181    This document also uses ABNF to define valid protocol elements
    182    (<xref target="notation"/>).
    183    In addition to the prose requirements placed upon them, senders &MUST-NOT;
    184    generate protocol elements that do not match the grammar defined by the
    185    ABNF rules for those protocol elements that are applicable to the sender's
    186    role. If a received protocol element is processed, the recipient &MUST; be
    187    able to parse any value that would match the ABNF rules for that protocol
    188    element, excluding only those rules not applicable to the recipient's role.
    189 </t>
    190 <t>
    191    Unless noted otherwise, a recipient &MAY; attempt to recover a usable
    192    protocol element from an invalid construct.  HTTP does not define
    193    specific error handling mechanisms except when they have a direct impact
    194    on security, since different applications of the protocol require
    195    different error handling strategies.  For example, a Web browser might
    196    wish to transparently recover from a response where the
    197    <x:ref>Location</x:ref> header field doesn't parse according to the ABNF,
    198    whereas a systems control client might consider any form of error recovery
    199    to be dangerous.
     163   Conformance criteria and considerations regarding error handling
     164   are defined in &conformance;.
    200165</t>
    201166</section>
  • draft-ietf-httpbis/latest/p6-cache.html

    r1873 r1875  
    585585               <li><a href="#rfc.section.1.1">1.1</a>&nbsp;&nbsp;&nbsp;<a href="#intro.purpose">Purpose</a></li>
    586586               <li><a href="#rfc.section.1.2">1.2</a>&nbsp;&nbsp;&nbsp;<a href="#intro.terminology">Terminology</a></li>
    587                <li><a href="#rfc.section.1.3">1.3</a>&nbsp;&nbsp;&nbsp;<a href="#intro.conformance.and.error.handling">Conformance and Error Handling</a></li>
     587               <li><a href="#rfc.section.1.3">1.3</a>&nbsp;&nbsp;&nbsp;<a href="#conformance">Conformance and Error Handling</a></li>
    588588               <li><a href="#rfc.section.1.4">1.4</a>&nbsp;&nbsp;&nbsp;<a href="#notation">Syntax Notation</a><ul>
    589589                     <li><a href="#rfc.section.1.4.1">1.4.1</a>&nbsp;&nbsp;&nbsp;<a href="#delta-seconds">Delta Seconds</a></li>
     
    776776         </li>
    777777      </ul>
    778       <h2 id="rfc.section.1.3"><a href="#rfc.section.1.3">1.3</a>&nbsp;<a id="intro.conformance.and.error.handling" href="#intro.conformance.and.error.handling">Conformance and Error Handling</a></h2>
     778      <h2 id="rfc.section.1.3"><a href="#rfc.section.1.3">1.3</a>&nbsp;<a id="conformance" href="#conformance">Conformance and Error Handling</a></h2>
    779779      <p id="rfc.section.1.3.p.1">The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"
    780780         in this document are to be interpreted as described in <a href="#RFC2119" id="rfc.xref.RFC2119.1"><cite title="Key words for use in RFCs to Indicate Requirement Levels">[RFC2119]</cite></a>.
    781781      </p>
    782       <p id="rfc.section.1.3.p.2">This specification targets conformance criteria according to the role of a participant in HTTP communication. Hence, HTTP
    783          requirements are placed on senders, recipients, clients, servers, user agents, intermediaries, origin servers, proxies, gateways,
    784          or caches, depending on what behavior is being constrained by the requirement. See <a href="p1-messaging.html#architecture" title="Architecture">Section 2</a> of <a href="#Part1" id="rfc.xref.Part1.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a> for definitions of these terms.
    785       </p>
    786       <p id="rfc.section.1.3.p.3">The verb "generate" is used instead of "send" where a requirement differentiates between creating a protocol element and merely
    787          forwarding a received element downstream.
    788       </p>
    789       <p id="rfc.section.1.3.p.4">An implementation is considered conformant if it complies with all of the requirements associated with the roles it partakes
    790          in HTTP. Note that SHOULD-level requirements are relevant here, unless one of the documented exceptions is applicable.
    791       </p>
    792       <p id="rfc.section.1.3.p.5">This document also uses ABNF to define valid protocol elements (<a href="#notation" title="Syntax Notation">Section&nbsp;1.4</a>). In addition to the prose requirements placed upon them, 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 that are applicable
    793          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
    794          to the recipient's role.
    795       </p>
    796       <p id="rfc.section.1.3.p.6">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
    797          except when they have a direct impact on security, since different applications of the protocol require different error handling
    798          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
    799          to be dangerous.
     782      <p id="rfc.section.1.3.p.2">Conformance criteria and considerations regarding error handling are defined in <a href="p1-messaging.html#conformance" title="Conformance and Error Handling">Section 2.5</a> of <a href="#Part1" id="rfc.xref.Part1.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>.
    800783      </p>
    801784      <h2 id="rfc.section.1.4"><a href="#rfc.section.1.4">1.4</a>&nbsp;<a id="notation" href="#notation">Syntax Notation</a></h2>
     
    10381021      <p id="rfc.section.4.1.3.p.15"> </p>
    10391022      <ul>
    1040          <li>HTTP/1.1 clients and caches <em class="bcp14">SHOULD</em> assume that an RFC-850 date which appears to be more than 50 years in the future is in fact in the past (this helps solve
     1023         <li>Recipients <em class="bcp14">SHOULD</em> assume that an RFC-850 date which appears to be more than 50 years in the future is in fact in the past (this helps solve
    10411024            the "year 2000" problem).
    10421025         </li>
    10431026         <li>Although all date formats are specified to be case-sensitive, recipients <em class="bcp14">SHOULD</em> match day, week and timezone names case-insensitively.
    10441027         </li>
    1045          <li>An HTTP/1.1 implementation <em class="bcp14">MAY</em> internally represent a parsed <a href="#header.expires" class="smpl">Expires</a> date as earlier than the proper value, but <em class="bcp14">MUST NOT</em> internally represent a parsed Expires date as later than the proper value.
    1046          </li>
    1047          <li>All expiration-related calculations <em class="bcp14">MUST</em> be done in GMT. The local time zone <em class="bcp14">MUST NOT</em> influence the calculation or comparison of an age or expiration time.
     1028         <li>An implementation <em class="bcp14">MAY</em> internally represent a parsed <a href="#header.expires" class="smpl">Expires</a> date as earlier than the proper value, but <em class="bcp14">MUST NOT</em> internally represent a parsed Expires date as later than the proper value.
     1029         </li>
     1030         <li>Recipients <em class="bcp14">MUST</em> perform all expiration-related calculations in GMT. The local time zone <em class="bcp14">MUST NOT</em> influence the calculation or comparison of an age or expiration time.
    10481031         </li>
    10491032         <li>Caches <em class="bcp14">SHOULD</em> consider dates with time zones other than "GMT" invalid.
     
    21862169                  <li><em>Part1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.1">1.3</a>, <a href="#rfc.xref.Part1.2">1.4</a>, <a href="#rfc.xref.Part1.3">3.1</a>, <a href="#rfc.xref.Part1.4">4</a>, <a href="#rfc.xref.Part1.5">4.3</a>, <a href="#rfc.xref.Part1.6">6</a>, <a href="#rfc.xref.Part1.7">6</a>, <a href="#rfc.xref.Part1.8">6</a>, <a href="#rfc.xref.Part1.9">11</a>, <a href="#Part1"><b>12.1</b></a>, <a href="#rfc.xref.Part1.10">B</a>, <a href="#rfc.xref.Part1.11">B</a>, <a href="#rfc.xref.Part1.12">B</a>, <a href="#rfc.xref.Part1.13">B</a>, <a href="#rfc.xref.Part1.14">B</a>, <a href="#rfc.xref.Part1.15">B</a>, <a href="#rfc.xref.Part1.16">B</a>, <a href="#rfc.xref.Part1.17">B</a><ul>
    21872170                        <li><em>Section 1.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.2">1.4</a></li>
    2188                         <li><em>Section 2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.1">1.3</a></li>
     2171                        <li><em>Section 2.5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.1">1.3</a></li>
    21892172                        <li><em>Section 2.7</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.15">B</a>, <a href="#rfc.xref.Part1.17">B</a></li>
    21902173                        <li><em>Section 3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.5">4.3</a>, <a href="#rfc.xref.Part1.12">B</a></li>
  • draft-ietf-httpbis/latest/p6-cache.xml

    r1867 r1875  
    1818  <!ENTITY Note "<x:h xmlns:x='http://purl.org/net/xml2rfc/ext'>Note:</x:h>">
    1919  <!ENTITY architecture                "<xref target='Part1' x:rel='#architecture' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
     20  <!ENTITY conformance                 "<xref target='Part1' x:rel='#conformance' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    2021  <!ENTITY notation                    "<xref target='Part1' x:rel='#notation' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    2122  <!ENTITY acks                        "<xref target='Part1' x:rel='#acks' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
     
    298299</section>
    299300
    300 <section title="Conformance and Error Handling" anchor="intro.conformance.and.error.handling">
     301<section title="Conformance and Error Handling" anchor="conformance">
    301302<t>
    302303   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
     
    305306</t>
    306307<t>
    307    This specification targets conformance criteria according to the role of
    308    a participant in HTTP communication.  Hence, HTTP requirements are placed
    309    on senders, recipients, clients, servers, user agents, intermediaries,
    310    origin servers, proxies, gateways, or caches, depending on what behavior
    311    is being constrained by the requirement. See &architecture; for definitions
    312    of these terms.
    313 </t>
    314 <t>
    315    The verb "generate" is used instead of "send" where a requirement
    316    differentiates between creating a protocol element and merely forwarding a
    317    received element downstream.
    318 </t>
    319 <t>
    320    An implementation is considered conformant if it complies with all of the
    321    requirements associated with the roles it partakes in HTTP. Note that
    322    SHOULD-level requirements are relevant here, unless one of the documented
    323    exceptions is applicable.
    324 </t>
    325 <t>
    326    This document also uses ABNF to define valid protocol elements
    327    (<xref target="notation"/>).
    328    In addition to the prose requirements placed upon them, senders &MUST-NOT;
    329    generate protocol elements that do not match the grammar defined by the
    330    ABNF rules for those protocol elements that are applicable to the sender's
    331    role. If a received protocol element is processed, the recipient &MUST; be
    332    able to parse any value that would match the ABNF rules for that protocol
    333    element, excluding only those rules not applicable to the recipient's role.
    334 </t>
    335 <t>
    336    Unless noted otherwise, a recipient &MAY; attempt to recover a usable
    337    protocol element from an invalid construct.  HTTP does not define
    338    specific error handling mechanisms except when they have a direct impact
    339    on security, since different applications of the protocol require
    340    different error handling strategies.  For example, a Web browser might
    341    wish to transparently recover from a response where the
    342    <x:ref>Location</x:ref> header field doesn't parse according to the ABNF,
    343    whereas a systems control client might consider any form of error recovery
    344    to be dangerous.
     308   Conformance criteria and considerations regarding error handling
     309   are defined in &conformance;.
    345310</t>
    346311</section>
     
    816781<t>
    817782  <list style="symbols">
    818      <t>HTTP/1.1 clients and caches &SHOULD; assume that an RFC-850 date
     783     <t>Recipients &SHOULD; assume that an RFC-850 date
    819784        which appears to be more than 50 years in the future is in fact
    820785        in the past (this helps solve the "year 2000" problem).</t>
     
    824789        case-insensitively.</t>
    825790             
    826      <t>An HTTP/1.1 implementation &MAY; internally represent a parsed
     791     <t>An implementation &MAY; internally represent a parsed
    827792        <x:ref>Expires</x:ref> date as earlier than the proper value, but
    828793        &MUST-NOT; internally represent a parsed Expires date as later than the
    829794        proper value.</t>
    830795
    831      <t>All expiration-related calculations &MUST; be done in GMT. The
    832         local time zone &MUST-NOT; influence the calculation or comparison
     796     <t>Recipients &MUST; perform all expiration-related calculations in GMT.
     797        The local time zone &MUST-NOT; influence the calculation or comparison
    833798        of an age or expiration time.</t>
    834799
  • draft-ietf-httpbis/latest/p7-auth.html

    r1873 r1875  
    570570      <ul class="toc">
    571571         <li><a href="#rfc.section.1">1.</a>&nbsp;&nbsp;&nbsp;<a href="#introduction">Introduction</a><ul>
    572                <li><a href="#rfc.section.1.1">1.1</a>&nbsp;&nbsp;&nbsp;<a href="#intro.conformance.and.error.handling">Conformance and Error Handling</a></li>
     572               <li><a href="#rfc.section.1.1">1.1</a>&nbsp;&nbsp;&nbsp;<a href="#conformance">Conformance and Error Handling</a></li>
    573573               <li><a href="#rfc.section.1.2">1.2</a>&nbsp;&nbsp;&nbsp;<a href="#notation">Syntax Notation</a></li>
    574574            </ul>
     
    630630         provide authentication information. The "basic" and "digest" authentication schemes continue to be specified in <cite title="HTTP Authentication: Basic and Digest Access Authentication" id="rfc.xref.RFC2617.2">RFC 2617</cite>.
    631631      </p>
    632       <h2 id="rfc.section.1.1"><a href="#rfc.section.1.1">1.1</a>&nbsp;<a id="intro.conformance.and.error.handling" href="#intro.conformance.and.error.handling">Conformance and Error Handling</a></h2>
     632      <h2 id="rfc.section.1.1"><a href="#rfc.section.1.1">1.1</a>&nbsp;<a id="conformance" href="#conformance">Conformance and Error Handling</a></h2>
    633633      <p id="rfc.section.1.1.p.1">The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"
    634634         in this document are to be interpreted as described in <a href="#RFC2119" id="rfc.xref.RFC2119.1"><cite title="Key words for use in RFCs to Indicate Requirement Levels">[RFC2119]</cite></a>.
    635635      </p>
    636       <p id="rfc.section.1.1.p.2">This specification targets conformance criteria according to the role of a participant in HTTP communication. Hence, HTTP
    637          requirements are placed on senders, recipients, clients, servers, user agents, intermediaries, origin servers, proxies, gateways,
    638          or caches, depending on what behavior is being constrained by the requirement. See <a href="p1-messaging.html#architecture" title="Architecture">Section 2</a> of <a href="#Part1" id="rfc.xref.Part1.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a> for definitions of these terms.
    639       </p>
    640       <p id="rfc.section.1.1.p.3">The verb "generate" is used instead of "send" where a requirement differentiates between creating a protocol element and merely
    641          forwarding a received element downstream.
    642       </p>
    643       <p id="rfc.section.1.1.p.4">An implementation is considered conformant if it complies with all of the requirements associated with the roles it partakes
    644          in HTTP. Note that SHOULD-level requirements are relevant here, unless one of the documented exceptions is applicable.
    645       </p>
    646       <p id="rfc.section.1.1.p.5">This document also uses ABNF to define valid protocol elements (<a href="#notation" title="Syntax Notation">Section&nbsp;1.2</a>). In addition to the prose requirements placed upon them, 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 that are applicable
    647          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
    648          to the recipient's role.
    649       </p>
    650       <p id="rfc.section.1.1.p.6">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
    651          except when they have a direct impact on security, since different applications of the protocol require different error handling
    652          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
    653          to be dangerous.
     636      <p id="rfc.section.1.1.p.2">Conformance criteria and considerations regarding error handling are defined in <a href="p1-messaging.html#conformance" title="Conformance and Error Handling">Section 2.5</a> of <a href="#Part1" id="rfc.xref.Part1.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>.
    654637      </p>
    655638      <h2 id="rfc.section.1.2"><a href="#rfc.section.1.2">1.2</a>&nbsp;<a id="notation" href="#notation">Syntax Notation</a></h2>
     
    12091192                  <li><em>Part1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.1">1.1</a>, <a href="#rfc.xref.Part1.2">1.2</a>, <a href="#rfc.xref.Part1.3">2.2</a>, <a href="#rfc.xref.Part1.4">2.3.1</a>, <a href="#rfc.xref.Part1.5">4.2</a>, <a href="#rfc.xref.Part1.6">4.4</a>, <a href="#rfc.xref.Part1.7">7</a>, <a href="#Part1"><b>8.1</b></a>, <a href="#rfc.xref.Part1.8">B</a>, <a href="#rfc.xref.Part1.9">B</a>, <a href="#rfc.xref.Part1.10">B</a>, <a href="#rfc.xref.Part1.11">B</a>, <a href="#rfc.xref.Part1.12">B</a><ul>
    12101193                        <li><em>Section 1.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.2">1.2</a></li>
    1211                         <li><em>Section 2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.1">1.1</a></li>
    12121194                        <li><em>Section 2.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.4">2.3.1</a></li>
     1195                        <li><em>Section 2.5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.1">1.1</a></li>
    12131196                        <li><em>Section 3.2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.9">B</a>, <a href="#rfc.xref.Part1.10">B</a></li>
    12141197                        <li><em>Section 3.2.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.11">B</a>, <a href="#rfc.xref.Part1.12">B</a></li>
  • draft-ietf-httpbis/latest/p7-auth.xml

    r1867 r1875  
    1818  <!ENTITY Note "<x:h xmlns:x='http://purl.org/net/xml2rfc/ext'>Note:</x:h>">
    1919  <!ENTITY architecture                 "<xref target='Part1' x:rel='#architecture' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
     20  <!ENTITY conformance                  "<xref target='Part1' x:rel='#conformance' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    2021  <!ENTITY notation                     "<xref target='Part1' x:rel='#notation' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    2122  <!ENTITY abnf-extension               "<xref target='Part1' x:rel='#abnf.extension' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
     
    139140</t>
    140141
    141 <section title="Conformance and Error Handling" anchor="intro.conformance.and.error.handling">
     142<section title="Conformance and Error Handling" anchor="conformance">
    142143<t>
    143144   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
     
    146147</t>
    147148<t>
    148    This specification targets conformance criteria according to the role of
    149    a participant in HTTP communication.  Hence, HTTP requirements are placed
    150    on senders, recipients, clients, servers, user agents, intermediaries,
    151    origin servers, proxies, gateways, or caches, depending on what behavior
    152    is being constrained by the requirement. See &architecture; for definitions
    153    of these terms.
    154 </t>
    155 <t>
    156    The verb "generate" is used instead of "send" where a requirement
    157    differentiates between creating a protocol element and merely forwarding a
    158    received element downstream.
    159 </t>
    160 <t>
    161    An implementation is considered conformant if it complies with all of the
    162    requirements associated with the roles it partakes in HTTP. Note that
    163    SHOULD-level requirements are relevant here, unless one of the documented
    164    exceptions is applicable.
    165 </t>
    166 <t>
    167    This document also uses ABNF to define valid protocol elements
    168    (<xref target="notation"/>).
    169    In addition to the prose requirements placed upon them, senders &MUST-NOT;
    170    generate protocol elements that do not match the grammar defined by the
    171    ABNF rules for those protocol elements that are applicable to the sender's
    172    role. If a received protocol element is processed, the recipient &MUST; be
    173    able to parse any value that would match the ABNF rules for that protocol
    174    element, excluding only those rules not applicable to the recipient's role.
    175 </t>
    176 <t>
    177    Unless noted otherwise, a recipient &MAY; attempt to recover a usable
    178    protocol element from an invalid construct.  HTTP does not define
    179    specific error handling mechanisms except when they have a direct impact
    180    on security, since different applications of the protocol require
    181    different error handling strategies.  For example, a Web browser might
    182    wish to transparently recover from a response where the
    183    <x:ref>Location</x:ref> header field doesn't parse according to the ABNF,
    184    whereas a systems control client might consider any form of error recovery
    185    to be dangerous.
     149   Conformance criteria and considerations regarding error handling
     150   are defined in &conformance;.
    186151</t>
    187152</section>
Note: See TracChangeset for help on using the changeset viewer.