Changeset 2064


Ignore:
Timestamp:
Dec 28, 2012, 7:20:00 PM (7 years ago)
Author:
fielding@…
Message:

(editorial) rephrase OPTIONS for better targeting of subject requirements

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

Legend:

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

    r2063 r2064  
    15691569      </p>
    15701570      <p id="rfc.section.4.3.7.p.2">Responses to the OPTIONS method are not cacheable.</p>
    1571       <p id="rfc.section.4.3.7.p.3">If the OPTIONS request includes a payload, then the media type <em class="bcp14">MUST</em> be indicated by a <a href="#header.content-type" class="smpl">Content-Type</a> field. Although this specification does not define any use for such a body, future extensions to HTTP might use the OPTIONS
    1572          body to make more detailed queries on the server.
    1573       </p>
    1574       <p id="rfc.section.4.3.7.p.4">If the request-target (<a href="p1-messaging.html#request-target" title="Request Target">Section 5.3</a> of <a href="#Part1" id="rfc.xref.Part1.16"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>) is an asterisk ("*"), the OPTIONS request is intended to apply to the server in general rather than to a specific resource.
    1575          Since a server's communication options typically depend on the resource, the "*" request is only useful as a "ping" or "no-op"
    1576          type of method; it does nothing beyond allowing the client to test the capabilities of the server. For example, this can be
    1577          used to test a proxy for HTTP/1.1 conformance (or lack thereof).
    1578       </p>
    1579       <p id="rfc.section.4.3.7.p.5">If the request-target is not an asterisk, the OPTIONS request applies only to the options that are available when communicating
    1580          with that resource.
    1581       </p>
    1582       <p id="rfc.section.4.3.7.p.6">A <a href="#status.200" class="smpl">200 (OK)</a> response <em class="bcp14">SHOULD</em> include any header fields that indicate optional features implemented by the server and applicable to that resource (e.g., <a href="#header.allow" class="smpl">Allow</a>), possibly including extensions not defined by this specification. The response payload, if any, <em class="bcp14">SHOULD</em> also include information about the communication options. The format for such a payload is not defined by this specification,
    1583          but might be defined by future extensions to HTTP. Content negotiation <em class="bcp14">MAY</em> be used to select the appropriate representation. If no payload body is included, the response <em class="bcp14">MUST</em> include a <a href="p1-messaging.html#header.content-length" class="smpl">Content-Length</a> field with a field-value of "0".
    1584       </p>
    1585       <p id="rfc.section.4.3.7.p.7">The <a href="#header.max-forwards" class="smpl">Max-Forwards</a> header field <em class="bcp14">MAY</em> be used to target a specific proxy in the request chain (see <a href="#header.max-forwards" id="rfc.xref.header.max-forwards.1" title="Max-Forwards">Section&nbsp;5.1.1</a>). If no Max-Forwards field is present in the request, then the forwarded request <em class="bcp14">MUST NOT</em> include a Max-Forwards field.
     1571      <p id="rfc.section.4.3.7.p.3">A client that generates an OPTIONS request containing a payload body <em class="bcp14">MUST</em> send a valid <a href="#header.content-type" class="smpl">Content-Type</a> header field describing the representation media type. Although this specification does not define any use for such a payload,
     1572         future extensions to HTTP might use the OPTIONS body to make more detailed queries about the target resource.
     1573      </p>
     1574      <p id="rfc.section.4.3.7.p.4">An OPTIONS request with an asterisk ("*") as the request-target (<a href="p1-messaging.html#request-target" title="Request Target">Section 5.3</a> of <a href="#Part1" id="rfc.xref.Part1.16"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>) applies to the server in general rather than to a specific resource. Since a server's communication options typically depend
     1575         on the resource, the "*" request is only useful as a "ping" or "no-op" type of method; it does nothing beyond allowing the
     1576         client to test the capabilities of the server. For example, this can be used to test a proxy for HTTP/1.1 conformance (or
     1577         lack thereof).
     1578      </p>
     1579      <p id="rfc.section.4.3.7.p.5">If the request-target is not an asterisk, the OPTIONS request applies to the options that are available when communicating
     1580         with the target resource.
     1581      </p>
     1582      <p id="rfc.section.4.3.7.p.6">A server generating a successful response to OPTIONS <em class="bcp14">SHOULD</em> send any header fields that might indicate optional features implemented by the server and applicable to the target resource
     1583         (e.g., <a href="#header.allow" class="smpl">Allow</a>), including potential extensions not defined by this specification. The response payload, if any, might also describe the
     1584         communication options in a machine or human-readable representation. A standard format for such a payload is not defined by
     1585         this specification, but might be defined by future extensions to HTTP. A server <em class="bcp14">MUST</em> generate a <a href="p1-messaging.html#header.content-length" class="smpl">Content-Length</a> field with a value of "0" if no payload body is to be sent in the response.
     1586      </p>
     1587      <p id="rfc.section.4.3.7.p.7">A client <em class="bcp14">MAY</em> send a <a href="#header.max-forwards" class="smpl">Max-Forwards</a> header field in an OPTIONS request to target a specific recipient in the request chain (see <a href="#header.max-forwards" id="rfc.xref.header.max-forwards.1" title="Max-Forwards">Section&nbsp;5.1.1</a>). A proxy <em class="bcp14">MUST NOT</em> generate a Max-Forwards header field while forwarding a request unless that request was received with a Max-Forwards field.
    15861588      </p>
    15871589      <h3 id="rfc.section.4.3.8"><a href="#rfc.section.4.3.8">4.3.8</a>&nbsp;<a id="TRACE" href="#TRACE">TRACE</a></h3>
  • 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.