Ignore:
Timestamp:
29/12/12 03:20:00 (8 years ago)
Author:
fielding@…
Message:

(editorial) rephrase OPTIONS for better targeting of subject requirements

File:
1 edited

Legend:

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

    r2063 r2064  
    16281628</t>
    16291629<t>
    1630    If the OPTIONS request includes a payload,
    1631    then the media type &MUST; be indicated by a <x:ref>Content-Type</x:ref>
    1632    field. Although this specification does not define any use for such a body,
    1633    future extensions to HTTP might use the OPTIONS body to make more detailed
    1634    queries on the server.
    1635 </t>
    1636 <t>
    1637    If the request-target (&request-target;) is an asterisk ("*"),
    1638    the OPTIONS request is
    1639    intended to apply to the server in general rather than to a specific
    1640    resource. Since a server's communication options typically depend on
    1641    the resource, the "*" request is only useful as a "ping" or "no-op"
     1630   A client that generates an OPTIONS request containing a payload body
     1631   &MUST; send a valid <x:ref>Content-Type</x:ref> header field describing
     1632   the representation media type. Although this specification does not define
     1633   any use for such a payload, future extensions to HTTP might use the OPTIONS
     1634   body to make more detailed queries about the target resource.
     1635</t>
     1636<t>
     1637   An OPTIONS request with an asterisk ("*") as the request-target
     1638   (&request-target;) applies to the server in general rather than to a
     1639   specific resource. Since a server's communication options typically depend
     1640   on the resource, the "*" request is only useful as a "ping" or "no-op"
    16421641   type of method; it does nothing beyond allowing the client to test
    16431642   the capabilities of the server. For example, this can be used to test
     
    16461645<t>
    16471646   If the request-target is not an asterisk, the OPTIONS request applies
    1648    only to the options that are available when communicating with that
     1647   to the options that are available when communicating with the target
    16491648   resource.
    16501649</t>
    16511650<t>
    1652    A <x:ref>200 (OK)</x:ref> response &SHOULD; include any header fields that
    1653    indicate optional features implemented by the server and applicable to that
    1654    resource (e.g., <x:ref>Allow</x:ref>), possibly including extensions not
    1655    defined by this specification. The response payload, if any, &SHOULD; also
    1656    include information about the communication options. The format for such a
     1651   A server generating a successful response to OPTIONS &SHOULD; send any
     1652   header fields that might indicate optional features implemented by the
     1653   server and applicable to the target resource (e.g., <x:ref>Allow</x:ref>),
     1654   including potential extensions not defined by this specification.
     1655   The response payload, if any, might also describe the communication options
     1656   in a machine or human-readable representation. A standard format for such a
    16571657   payload is not defined by this specification, but might be defined by
    1658    future extensions to HTTP. Content negotiation &MAY; be used to select
    1659    the appropriate representation. If no payload body is included, the
    1660    response &MUST; include a <x:ref>Content-Length</x:ref> field with a
    1661    field-value of "0".
    1662 </t>
    1663 <t>
    1664    The <x:ref>Max-Forwards</x:ref> header field &MAY; be used to target a
    1665    specific proxy in the request chain (see <xref target="header.max-forwards"/>).
    1666    If no Max-Forwards field is present in the request, then the forwarded
    1667    request &MUST-NOT; include a Max-Forwards field.
     1658   future extensions to HTTP.
     1659   A server &MUST; generate a <x:ref>Content-Length</x:ref> field with a value
     1660   of "0" if no payload body is to be sent in the response.
     1661</t>
     1662<t>
     1663   A client &MAY; send a <x:ref>Max-Forwards</x:ref> header field in an
     1664   OPTIONS request to target a specific recipient in the request chain (see
     1665   <xref target="header.max-forwards"/>). A proxy &MUST-NOT; generate a
     1666   Max-Forwards header field while forwarding a request unless that request
     1667   was received with a Max-Forwards field.
    16681668</t>
    16691669</section>
Note: See TracChangeset for help on using the changeset viewer.