Changeset 2064 for draft-ietf-httpbis/latest/p2-semantics.html

Timestamp:

29/12/12 03:20:00 (8 years ago)

Author:

fielding@…

Message:

(editorial) rephrase OPTIONS for better targeting of subject requirements

File:

• draft-ietf-httpbis/latest/p2-semantics.html (modified) (1 diff)

draft-ietf-httpbis/latest/p2-semantics.html

@@ -1569 +1569 @@
       </p>
       <p id="rfc.section.4.3.7.p.2">Responses to the OPTIONS method are not cacheable.</p>
-      <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
-         body to make more detailed queries on the server.
-      </p>
-      <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.
-         Since a server's communication options typically depend on the resource, the "*" request is only useful as a "ping" or "no-op"
-         type of method; it does nothing beyond allowing the client to test the capabilities of the server. For example, this can be
-         used to test a proxy for HTTP/1.1 conformance (or lack thereof).
-      </p>
-      <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
-         with that resource.
-      </p>
-      <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,
-         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".
-      </p>
-      <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.
+      <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,
+         future extensions to HTTP might use the OPTIONS body to make more detailed queries about the target resource.
+      </p>
+      <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
+         on the resource, the "*" request is only useful as a "ping" or "no-op" type of method; it does nothing beyond allowing the
+         client to test the capabilities of the server. For example, this can be used to test a proxy for HTTP/1.1 conformance (or
+         lack thereof).
+      </p>
+      <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
+         with the target resource.
+      </p>
+      <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
+         (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
+         communication options in a machine or human-readable representation. A standard format for such a payload is not defined by
+         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.
+      </p>
+      <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.
       </p>
       <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>