Changeset 2064 for draft-ietf-httpbis/latest/p2-semantics.html
- Timestamp:
- 29/12/12 03:20:00 (9 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p2-semantics.html
r2063 r2064 1569 1569 </p> 1570 1570 <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 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 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. 1586 1588 </p> 1587 1589 <h3 id="rfc.section.4.3.8"><a href="#rfc.section.4.3.8">4.3.8</a> <a id="TRACE" href="#TRACE">TRACE</a></h3>
Note: See TracChangeset
for help on using the changeset viewer.