31/07/13 17:43:09 (9 years ago)

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

1 edited


  • draft-ietf-httpbis/latest/p1-messaging.xml

    r2319 r2332  
    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).
     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.
     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.
     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.
     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.
    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.