Specification of HTTP/1.1 OPTIONS messages
This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
To learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast).
Distribution of this document is unlimited. Please send comments to the HTTP working group at <http-wg@cuckoo.hpl.hp.com>. Discussions of the working group are archived at URL:http://www.ics.uci.edu/pub/ietf/http/. General discussions about HTTP and the applications which use HTTP should take place on the <www-talk@w3.org> mailing list.
RFC2068 defined a new OPTIONS method for HTTP/1.1. The purpose of OPTIONS is to allow a 'client to determine the options and/or requirements associated with a resource, or the capabilities of a server, without implying a resource action or initiating a resource retrieval.' However, RFC2068 did not defined a specific syntax for using OPTIONS to make such a determination. This proposal clarifies the original specification of OPTIONS, adds several new HTTP message headers to provide syntactic support for OPTIONS, and establishes new IANA registries to avoid namespace conflicts.
RFC2068 は HTTP/1.1 向けに新しい OPTIONS method
を定義しました。 OPTIONS の目的は
「資源の動作又は資源取り出しの開始なしに、クライアントが資源に関連付けられた選択肢及び/又は要件若しくはサーバーの能力を決定する」
ことを可能にすることです。しかし、 RFC 2068 は OPTIONS
を使ってそのような決定を行う特定の構文を定義していませんでした。
この提案は OPTIONS の元の仕様を明確化し、 OPTIONS
を構文的に支援する新しい HTTP メッセージ頭を幾つか追加し、名前空間衝突を防ぐための新しい
IANA 登録簿を確立します。
Section 9.2 of RFC2068 [2] defines an OPTIONS method, to allow a "client to determine the options and/or requirements associated with a resource, or the capabilities of a server, without implying a resource action or initiating a resource retrieval." For example, a client may wish to determine if a particular HTTP method is supported by a server, or for a specific resource. Or, a client may wish to determine if a server supports the use of a particular HTTP request-header.
RFC 2068 の9.2節は OPTIONS method
を定義し、「資源の動作又は資源取り出しの開始なしに、クライアントが資源に関連付けられた選択肢及び/又は要件若しくはサーバーの能力を決定する」
ことを可能としています。例えば、クライアントは、ある HTTP method をサーバーが、
あるいはある資源について、対応しているか否かを決定したいと思うかもしれません。
あるいは、クライアントはサーバーが特定の HTTP 要求頭の使用に対応しているかを決定したいと思うかもしれません。
The description of OPTIONS in RFC2068 has left some implementors confused about what is required, and does not provide a specific syntax for determining support for specific options or extensions. While some of this might be obviated in the future by the Protocol Extension Protocol (PEP) [1], there exists an immediate need to define a simple and well-specified OPTIONS mechanism for HTTP/1.1.
RFC 2068 の OPTIONS の説明は何が必要なのかについて実装者に混乱を残しており、
特定の選択肢や拡張の対応を決定する特定の構文を提供していません。
このうちの幾つかは将来プロトコル拡張プロトコル (PEP)
によって不要になるかもしれませんが、
単純でよく規定された HTTP/1.1 用の OPTIONS 機構がすぐに必要とされています。
- The intended recipient of an OPTIONS request may be any server (including proxies) along the request path. RFC2068 supported this by requiring a transformation of the request-URI for a set of methods (actually, only for OPTIONS); in the current proposal, one can either use the Host header to address a specific server or proxy, or the Max-Forwards header to address the Nth server on a path.
- As in RFC2068, the URI '*' refers to the server, independent of any specific resource. Any other URI refers to the resource normally identified by that URI.
OPTIONS 要求の意図する受信者は要求経路中の (串を含む)
任意のサーバーです。 RFC 2068 は、 method の集合 (実際には、
OPTIONS のみ) に対して request-URI
の変形を要求していることでこれに対応していました。
この提案では、特定のサーバー又は串を Host
頭を使って指定するか、若しくは経路中の何番目のサーバーかを
Max-Forwards 頭で指定するかの方法をとれます。* は、
特定の資源から独立して、サーバー自体を指します。他の URI
は通常その URI により識別される資源を指します。
- The descriptions of the Allow and Public headers, and of the OPTIONS method, are made consistent in their requirements for proxy editing of OPTIONS responses. (In RFC2068, these sections were contradictory).
- A (new) Compliance header is proposed, which allows a client to specify exactly what options it is asking about, and which allows a server to specify exactly what subset of those options are supported.
Allow 頭及び Public
頭の説明並びに OPTIONS method の説明は、
OPTIONS 応答の串による編集の要件で一貫したものとします。
(RFC 2068 では、この節は矛盾していました)。Compliance 頭を提案します。
クライアントがどの選択肢について訊ねているのかを指定可能とすると共に、
サーバーがその選択肢群のどの部分集合に対応しているかを指定可能とします。Discussion question: it might make more sense to use two different header names, one for requests and one for responses, to clarify that in a request, the client is asking the server about its supported options, and in a response, the server is stating its supported options.
要求用と応答用で別の頭名を使って、 要求ではクライアントがサーバーに対応している選択肢を訊ねていることを、 応答ではサーバーが対応している選択肢を言明していることを明確化した方がいいかも。
- The Compliance header allows several namespaces for options; the set of namespaces is under IANA control. One namespace is that of IETF-issued RFCs; this allows a more specific definition of compliance than is available using protocol version numbers. While various interpretations can and do exist about the specific meaning of a protocol version number (such as "HTTP/1.1"), the meaning of an RFC is both well-defined and (more important) immutable.
Compliance 頭では選択肢の名前空間を使えます。
名前空間の集合は IANA が統制します。名前空間の1つは IETF が発行する RFC
のものです。これによってプロトコルの版番号によって利用可能なもの以上に特定の追従性の定義ができます。
(HTTP/1.1 のような) プロトコル版番号の意味については種々の解釈が存在し得て、実際存在していますが、
RFC の意味はよく定義されており、 (より重要なこととして)
不変であります。
- A (new) Non-Compliance header is proposed, allowing a proxy processing an OPTIONS response to indicate its non-compliance with one or more options, and without requiring the proxy to edit the rest of the response (which would result in loss of information).
Non-Conpliance 頭を提案します。
OPTIONS 応答を処理する串が一つ以上の選択肢に追従していないことを示すことができまして、その際串が応答の残りの部分を編集する (ことによって情報の損失を起こす) 必要がありません。Here we propose specific changes to RFC2068.
Remove this:
If a proxy receives a request without any path in the Request-URI and the method specified is capable of supporting the asterisk form of request, then the last proxy on the request chain MUST forward the request with "*" as the final Request-URI. For example, the request
- OPTIONS http://www.ics.uci.edu:8001 HTTP/1.1
would be forwarded by the proxy as
OPTIONS * HTTP/1.1 Host: www.ics.uci.edu:8001after connecting to port 8001 of host "www.ics.uci.edu".
Replace:
Unless the server's response is an error, the response MUST NOT include entity information other than what can be considered as communication options (e.g., Allow is appropriate, but Content-Type is not). Responses to this method are not cachable.
with:
An OPTIONS request MAY include Compliance headers (see section 14.ZZZ) that indicate the set of options the sender wants information about.
Responses to OPTIONS are not cachable, unless caching is explicitly allowed by the server that first sent the OPTIONS reply (see section 13.4).
OPTIONS 要求は、
送信者が情報を求める選択肢の集合を示す Compliance 頭を含んでも構いません。
OPTIONS に対する応答は、最初に OPTIONS
返信を送ったサーバーがキャッシュすることを陽に認めていない限りキャッシュ可能ではありません。
Replace:
If the Request-URI is an asterisk ("*"), the OPTIONS request is intended to apply to the server as a whole. A 200 response SHOULD include any header fields which indicate optional features implemented by the server (e.g., Public), including any extensions not defined by this specification, in addition to any applicable general or response-header fields. As described in section 5.1.2, an "OPTIONS *" request can be applied through a proxy by specifying the destination server in the Request-URI without any path information.
with:
If the Request-URI is an asterisk ("*"), the OPTIONS request is intended to apply to the server as a whole. A 200 response SHOULD include a Public header field (see section 14.35). If the request includes a Compliance header field, a 200 response SHOULD include a Compliance header field, indicating the subset of the requested Compliance options supported by the server as a whole. The response SHOULD include any other applicable general or response-header fields.
Request-URI が星印 (*) であれば、
OPTIONS 要求はサーバー全体に適用されることを意図しています。
200 応答は Public 頭欄を含むべきです。
要求が Compliance 頭欄を含んでいるなら、 200
応答は Compliance 頭欄を含めて、
要求された Compliance 選択肢のサーバー全体として対応している部分集合を示すべきです。
応答は他の適用可能な一般頭欄又は応答頭ランを含めるべきです。
If an OPTIONS request includes a Host header (see section 14.23), this is the intended destination of the OPTIONS method. Proxy servers MUST forward such a message until it reaches the specified host. If the specified host has more than one `virtual server', the OPTIONS request applies to the specified virtual server.
OPTIONS 要求が Host 頭を含んでいれば、
これは OPTIONS method の宛先を示しています。
串サーバーはその特定のホストに到達するまでメッセージを転送しなければなりません。
特定のホストが複数の「仮想サーバー」であれば、
OPTIONS 要求は特定の仮想サーバーにのみ適用されます。
Note: An OPTIONS request may also include a Max-Forwards header, as described in section 14.31. This allows the sender to select the Nth proxy on a path, without knowing its hostname.
注意 : OPTIONS 要求は Max-Forwards
頭も含むかもしれません。これによって送信者はホスト名を知らずとも経路上の
N 番目の串を選択することができます。
Replace:
If the Request-URI is not an asterisk, the OPTIONS request applies only to the options that are available when communicating with that resource. A 200 response SHOULD include any header fields which indicate optional features implemented by the server and applicable to that resource (e.g., Allow), including any extensions not defined by this specification, in addition to any applicable general or response-header fields. If the OPTIONS request passes through a proxy, the proxy MUST edit the response to exclude those options which apply to a proxy's capabilities and which are known to be unavailable through that proxy.
with:
If the Request-URI is not an asterisk, the OPTIONS request applies only to the options that are available when communicating with that resource. A 200 response SHOULD include an Allow header field (see section 14.7). If the request includes a Compliance header field, a 200 response SHOULD include a Compliance header field, indicating the subset of the requested Compliance options supported by the server as a whole. If the subset is empty, the response SHOULD include a Compliance header with an empty field-value. The response SHOULD include any other applicable general or response-header fields.
Note: if an OPTION request contains a Compliance header, and the response does not, the response may have been generated by RFC2068-compliant implementation, which would not support Compliance. In this case, it is not possible to infer that the sender fails to support all of the options listed in the Compliance header of the request.
If the OPTIONS request passes through a proxy, the proxy SHOULD add a Non-Compliance header field (see section 14.QQQ) to the response, to list those options that apply to a proxy's capabilities and that are known to be unavailable through that proxy.
Replace:
Each proxy or gateway recipient of a TRACE request containing a Max- Forwards header field SHOULD check and update its value prior to forwarding the request.
with:
Each proxy or gateway recipient of a TRACE or OPTIONS request containing a Max-Forwards header field SHOULD check and update its value prior to forwarding the request.
Insert in section 14, as a new subsection titled ``14.ZZZ Compliance
The Compliance general header field lists a set of options that may or may not be supported by a server. In a request message, this header lists the set of options that a client wishes to know about. In a response message, this header lists the subset of the requested options that the server complies with.
A compliance header MAY appear on any message, but is normally used with the OPTIONS request (see section 9.2).
- Compliance = "Compliance" ":" ("*" | #(compliance-option))
- compliance-option = compliance-namespace "=" option-item [ option-params ]
- compliance-namespace = token
- option-item = token | quoted-string | rfc-option-item | hdr-option-item
- option-params = 1*( ";" option-param)
- option-param = "cond" | "uncond" | token | quoted-string
A Compliance header field with the field-value of "*" MAY be used in a request, to ask about all options complied with by the recipient. This field-value MUST NOT be used in a response.
When the Compliance header is present in a response, it takes priority over an Allow header or a Public header in the same response.
Tokens used for compliance-namespace, option-item, and option-param values are case-insensitive.
The compliance-namespace is used to select from one of several namespaces for compliance options. The option-item is used to specify one or more options within a namespace.
The Internet Assigned Numbers Authority (IANA) acts as a registry for compliance-namespace tokens. Initially, the registry contains the following tokens:
"RFC" Compliance is with an RFC, specified by an RFC number.
For example, "rfc=1945". rfc-option-item = "RFC" "=" RFC-number
RFC-number = 1*DIGIT Leading zeroes are permitted and ignored in
RFC-number (i.e., comparisons are numeric). "HDR" Compliance is with a named HTTP header. For example,
"HDR=Authorization". There is no IANA registry for
HTTP header names, but to avoid potential namespace
confusion, only those HTTP headers listed in an
IETF standards-track document should be used in
this namespace.hdr-option-item = "HDR" "=" field-name
An implementation SHOULD NOT send option-param values other than "cond" or "uncond" with an rfc-option-item or a hdr-option-item.
The option-param is used to provide additional parameters. Unconditional compliance with a compliance-option is indicated using the "uncond" option-param; for example, "rfc=1945;uncond". Conditional compliance is indicated using the "cond" option-param; for example, "HDR=Authorization;uncond". Additional option-param values might be defined as part of another specification.
For the purposes of this header field, an implementation that satisfies all the MUST and all the SHOULD requirements for its protocols is defined as "unconditionally compliant"; one that satisfies all the MUST requirements but not all the SHOULD requirements for its protocols is defined as "conditionally compliant." See also RFC2119 for a discussion of the terms MUST and SHOULD.
Examples:
- Compliance: rfc=2068;uncond
- Compliance: rfc=1945;uncond, rfc=2068;cond
- Compliance: rfc=2068, hdr=SetCookie2
Note: when a resource is implemented using a subprogram outside the control of the server itself (such as a CGI application), and the server cannot ensure that this implementation of the resource will comply with a requested option, the server's Compliance response-header for the resource ought not to assert compliance with the option. That is, in case of uncertainty, it is better to imply non-compliance when the implementation might comply, than to claim compliance when the implementation might not comply.
Insert in section 14, as a new subsection titled ``14.QQQ Non-Compliance
A proxy server SHOULD add this response-header to a response containing a Compliance header if the proxy does not implement one or more of the options described in the Compliance header.
- Non-Compliance = "Non-Compliance" ":" 1#non-compliance-option
- proxy-host = host [ ":" port ]
- non-compliance-option = compliance-option "@" proxy-host
A non-compliance-option listed in a Non-Compliance response-header field indicates that the proxy server named by the proxy-host value does not support the listed compliance-option. The set of non-compliance options SHOULD be a subset of the compliance-options listed in a Compliance header field of the forwarded message.
Note: because the proxy-host value is not authenticated, this is only for advisory purposes (e.g., for debugging).
If the compliance-option in a non-compliance-option includes one or more option-param(s) (see section 14.ZZZ), then the proxy server's non-compliance is limited to the scope of the option-param(s). If the compliance-option does not include an option-param, then the proxy server is asserting non-compliance with the option in general.
For example, a response with:
- Compliance: rfc=9999;uncond
- Non-Compliance: rfc=9999;uncond@proxy.foo.net
states that proxy.foo.net is not unconditionally compliant with RFC9999, but does not imply that proxy.foo.net is not conditionally compliant with RFC9999. If the proxy is not even conditionally compliant with RFC9999, it should instead send
- Compliance: rfc=9999;uncond
- Non-Compliance: rfc=9999@proxy.foo.net
when forwarding the response.
A proxy MUST NOT delete a Non-Compliance header that it has received from another server.
The problem we address here is that RFC2068's specifications for the Allow and Public headers are inconsistent as to whether a proxy "MUST" or "MUST NOT" edit them. We believe that they should be consistent. Given that, there are arguments for either alternative:
- Requiring proxies to edit these headers provides the ultimate client with a simple way to determine if a method is allowed along the entire path to the origin server.
- However, requiring proxies not to edit these headers allows a client to find out about the capabilities of the origin server, since (as RFC2068 says about the Allow header) "the user agent may have other means of communicating with the origin server."
The second alternative seems more robust. Although we do not currently have an efficient mechanism for finding out if a method is supported along the entire path, presumbly any request using an unsupported method would immediately be rejected. However, we list both alternatives in the hope that further discussion will lead to a more satisfying solution.
Note: one possibility, not yet explored in detail, is that the compliance-namespace could be extended to include a "METH" token, allowing the Compliance header (and hence the Non-Compliance header) to completely replace the Allow and Public headers. E.g., the client could send
- Compliance: METH=*
to which the origin server might respond
- Compliance: METH=GET,METH=PUT,METH=HEAD
If this passes through a proxy that bans (e.g.) PUT, the proxy could forward the response as
Compliance: METH=GET,METH=PUT,METH=HEAD Non-Compliance: METH=PUT@roproxy.net
In section 14.35 (Public), replace
This header field applies only to the server directly connected to the client (i.e., the nearest neighbor in a chain of connections). If the response passes through a proxy, the proxy MUST either remove the Public header field or replace it with one applicable to its own capabilities.
with:
A proxy MUST NOT modify the Public header field even if it does not understand all the methods specified, since the user agent might have other means of communicating with the origin server.
Also, in section 14.7 (Allow), replace
A proxy MUST NOT modify the Allow header field even if it does not understand all the methods specified, since the user agent MAY have other means of communicating with the origin server.
with:
A proxy MUST NOT modify the Allow header field even if it does not understand all the methods specified, since the user agent might have other means of communicating with the origin server.
(removes an incorrect use of the term "MAY").
In section 14.7 (Allow), replace
A proxy MUST NOT modify the Allow header field even if it does not understand all the methods specified, since the user agent MAY have other means of communicating with the origin server.
with:
A proxy MUST remove methods from an Allow header field if it does not support the use of those methods for the resource identified by the Request-URI.
and in section 14.35 (Public), replace this paragraph:
This header field applies only to the server directly connected to the client (i.e., the nearest neighbor in a chain of connections). If the response passes through a proxy, the proxy MUST either remove the Public header field or replace it with one applicable to its own capabilities.
with:
A proxy MUST remove methods from a Public header field if it does not support the use of those methods.
To list all extensions supported by proxy "proxy4.example.com"
Client sends:
OPTIONS * HTTP/1.1 Host: proxy4.example.com Compliance: *proxy4.example.com responds:
HTTP/1.1 200 OK Date: Tue, 22 Jul 1997 20:21:51 GMT Server: SuperProxy/1.0 Public: OPTIONS, GET, HEAD, PUT, POST, TRACE Compliance: rfc=1543, rfc=2068, hdr=set-proxy Compliance: hdr=wonder-bar-http-widget-set Content-Length: 0
Probing for a feature which is not supported by "proxy4.example.com"
Client sends:
OPTIONS * HTTP/1.1 Host: proxy4.example.com Compliance: HDR=TimeTravelproxy4.example.com responds:
HTTP/1.1 200 OK Date: Tue, 22 Jul 1997 20:21:52 GMT Server: SuperProxy/1.0 Public: OPTIONS, GET, HEAD, PUT, POST, TRACE Compliance: Content-Length: 0
Because the proxy-host value in a Non-Compliance header is not authenticated, in theory, a malicious proxy along the path could insert a Non-Compliance header with the name of some other proxy, perhaps one not even involved in the response. However, because the proxy-host value is used only for advisory purposes (e.g., for debugging), there does not appear to be a serious security problem with this lack of authentication.
Besides, any proxy along the request/response path for an HTTP interaction is able to perform far more disruptive (and far less easily detected) modifications of the messages it forwards; this proposal does not change that.
We would like to thank Roy Fielding, Jim Gettys, Paul Leach, Larry Masinter, Henrik Frystyk Nielsen, Ross Patterson, and Jim Whitehead for help in constructing this proposal.
Jeffrey C. Mogul Western Research Laboratory Digital Equipment Corporation 250 University Avenue Palo Alto, California, 94305, USA Email: mogul@wrl.dec.com
Josh Cohen Netscape Communications Corporation 501 E. Middlefield Rd Mountain View, CA 94043 Phone (415) 937-4157 EMail: josh@netscape.com
Scott Lawrence Agranat Systems, Inc. 1345 Main St. Waltham, MA 02154 Phone: +1-617-893-7868 Fax: +1-617-893-5740 Email: lawrence@agranat.com