Changeset 2332


Ignore:
Timestamp:
Jul 31, 2013, 10:43:09 AM (6 years ago)
Author:
fielding@…
Message:

Explain in more detail the conformance requirements related to specific roles, recipients, and workarounds; addresses #484

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

Legend:

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

    r2319 r2332  
    449449  }
    450450  @bottom-center {
    451        content: "Expires January 29, 2014";
     451       content: "Expires February 1, 2014";
    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="2013-07-28">
     493      <meta name="dct.issued" scheme="ISO8601" content="2013-07-31">
    494494      <meta name="dct.replaces" content="urn:ietf:rfc:2145">
    495495      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
     
    520520            <tr>
    521521               <td class="left">Intended status: Standards Track</td>
    522                <td class="right">July 28, 2013</td>
     522               <td class="right">July 31, 2013</td>
    523523            </tr>
    524524            <tr>
    525                <td class="left">Expires: January 29, 2014</td>
     525               <td class="left">Expires: February 1, 2014</td>
    526526               <td class="right"></td>
    527527            </tr>
     
    551551         in progress”.
    552552      </p>
    553       <p>This Internet-Draft will expire on January 29, 2014.</p>
     553      <p>This Internet-Draft will expire on February 1, 2014.</p>
    554554      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    555555      <p>Copyright © 2013 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
     
    955955         in HTTP.
    956956      </p>
    957       <p id="rfc.section.2.5.p.4">Conformance applies to both the syntax and semantics of HTTP protocol elements. A sender <em class="bcp14">MUST NOT</em> generate protocol elements that convey a meaning that is known by that sender to be false. 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
    958          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
    959          to the recipient's role.
    960       </p>
    961       <p id="rfc.section.2.5.p.5">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
     957      <p id="rfc.section.2.5.p.4">Conformance includes both the syntax and semantics of HTTP protocol elements. A sender <em class="bcp14">MUST NOT</em> generate protocol elements that convey a meaning that is known by that sender to be false. A sender <em class="bcp14">MUST NOT</em> generate protocol elements that do not match the grammar defined by the corresponding ABNF rules. Within a given message,
     958         a sender <em class="bcp14">MUST NOT</em> generate protocol elements or syntax alternatives that are only allowed to be generated by participants in other roles (i.e.,
     959         a role that the sender does not have for that message).
     960      </p>
     961      <p id="rfc.section.2.5.p.5">When a received protocol element is parsed, the recipient <em class="bcp14">MUST</em> be able to parse any value of reasonable length that is applicable to the recipient's role and matches the grammar defined
     962         by the corresponding ABNF rules. Note, however, that some received protocol elements might not be parsed. For example, an
     963         intermediary forwarding a message might parse a header-field into generic field-name and field-value components, but then
     964         forward the header field without further parsing inside the field-value.
     965      </p>
     966      <p id="rfc.section.2.5.p.6">HTTP does not have specific length limitations for many of its protocol elements because the lengths that might be appropriate
     967         will vary widely, depending on the deployment context and purpose of the implementation. Hence, interoperability between senders
     968         and recipients depends on shared expectations regarding what is a reasonable length for each protocol element. Furthermore,
     969         what is commonly understood to be a reasonable length for some protocol elements has changed over the course of the past two
     970         decades of HTTP use, and is expected to continue changing in the future.
     971      </p>
     972      <p id="rfc.section.2.5.p.7">At a minimum, a recipient <em class="bcp14">MUST</em> be able to parse and process protocol element lengths that are at least as long as the values that it generates for those
     973         same protocol elements in other messages. For example, an origin server that publishes very long URI references to its own
     974         resources needs to be able to parse and process those same references when received as a request target.
     975      </p>
     976      <p id="rfc.section.2.5.p.8">A recipient <em class="bcp14">MUST</em> interpret a received protocol element according to the semantics defined for it by this specification, including extensions
     977         to this specification, unless the recipient has determined (through experience or configuration) that the sender incorrectly
     978         implements what is implied by those semantics. For example, an origin server might disregard the contents of a received <a href="p2-semantics.html#header.accept-encoding" class="smpl">Accept-Encoding</a> header field if inspection of the <a href="p2-semantics.html#header.user-agent" class="smpl">User-Agent</a> header field indicates a specific implementation version that is known to fail on receipt of certain content codings.
     979      </p>
     980      <p id="rfc.section.2.5.p.9">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
    962981         except when they have a direct impact on security, since different applications of the protocol require different error handling
    963982         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
  • draft-ietf-httpbis/latest/p1-messaging.xml

    r2319 r2332  
    620620</t>
    621621<t>
    622    Conformance applies to both the syntax and semantics of HTTP protocol
     622   Conformance includes both the syntax and semantics of HTTP protocol
    623623   elements. A sender &MUST-NOT; generate protocol elements that convey a
    624624   meaning that is known by that sender to be false. A sender &MUST-NOT;
    625625   generate protocol elements that do not match the grammar defined by the
    626    ABNF rules for those protocol elements that are applicable to the sender's
    627    role. If a received protocol element is processed, the recipient &MUST; be
    628    able to parse any value that would match the ABNF rules for that protocol
    629    element, excluding only those rules not applicable to the recipient's role.
     626   corresponding ABNF rules. Within a given message, a sender &MUST-NOT;
     627   generate protocol elements or syntax alternatives that are only allowed to
     628   be generated by participants in other roles (i.e., a role that the sender
     629   does not have for that message).
     630</t>
     631<t>
     632   When a received protocol element is parsed, the recipient &MUST; be able to
     633   parse any value of reasonable length that is applicable to the recipient's
     634   role and matches the grammar defined by the corresponding ABNF rules.
     635   Note, however, that some received protocol elements might not be parsed.
     636   For example, an intermediary forwarding a message might parse a
     637   header-field into generic field-name and field-value components, but then
     638   forward the header field without further parsing inside the field-value.
     639</t>
     640<t>
     641   HTTP does not have specific length limitations for many of its protocol
     642   elements because the lengths that might be appropriate will vary widely,
     643   depending on the deployment context and purpose of the implementation.
     644   Hence, interoperability between senders and recipients depends on shared
     645   expectations regarding what is a reasonable length for each protocol
     646   element. Furthermore, what is commonly understood to be a reasonable length
     647   for some protocol elements has changed over the course of the past two
     648   decades of HTTP use, and is expected to continue changing in the future.
     649</t>
     650<t>
     651   At a minimum, a recipient &MUST; be able to parse and process protocol
     652   element lengths that are at least as long as the values that it generates
     653   for those same protocol elements in other messages. For example, an origin
     654   server that publishes very long URI references to its own resources needs
     655   to be able to parse and process those same references when received as a
     656   request target.
     657</t>
     658<t>
     659   A recipient &MUST; interpret a received protocol element according to the
     660   semantics defined for it by this specification, including extensions to
     661   this specification, unless the recipient has determined (through experience
     662   or configuration) that the sender incorrectly implements what is implied by
     663   those semantics.
     664   For example, an origin server might disregard the contents of a received
     665   <x:ref>Accept-Encoding</x:ref> header field if inspection of the
     666   <x:ref>User-Agent</x:ref> header field indicates a specific implementation
     667   version that is known to fail on receipt of certain content codings.
    630668</t>
    631669<t>
     
    40884126    <x:defines>502 (Bad Gateway)</x:defines>
    40894127    <x:defines>505 (HTTP Version Not Supported)</x:defines>
     4128    <x:defines>Accept-Encoding</x:defines>
    40904129    <x:defines>Allow</x:defines>
    40914130    <x:defines>Content-Encoding</x:defines>
Note: See TracChangeset for help on using the changeset viewer.