- From: Roy T. Fielding <fielding@kiwi.ics.uci.edu>
- Date: Sun, 16 Nov 1997 18:10:44 -0800
- To: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
- Cc: Jim Gettys <jg@pa.dec.com>
I was asked to write up the changes needed to specify OPTIONS
minimally as a method that may still be useful sometime in the
future. Below is a context diff from Rev-00. The one possible item
of controversy is whether or not proxy implemementers are willing
to do the Max-Forwards calculation, but I feel this version is
much clearer and more reliable than the original.
Note that in the process I also deleted the Public header field,
since it hasn't been shown to be useful and most servers do not
implement it anyway, and its presence was confusing the issue.
It may be more appropriate to just move it to an appendix
(referencing the definition in RFC 2068).
....Roy
*** draft-ietf-http-v11-spec-rev-00.txt Fri Oct 17 16:24:07 1997
--- rev-options.txt Sun Nov 16 18:09:43 1997
***************
*** 85,91 ****
a separate internet draft on the topic that you should
review NOT incorporated into this draft (though editorial
notes identify where changes may occur). This draft is
! draft-ietf-http-options-00.txt.
Also an issue: AGE-CALCULATION; Roy Fielding has issued an
ID on the topic; Jeff Mogul intends to issue a draft as
--- 85,91 ----
a separate internet draft on the topic that you should
review NOT incorporated into this draft (though editorial
notes identify where changes may occur). This draft is
! draft-ietf-http-options-02.txt.
Also an issue: AGE-CALCULATION; Roy Fielding has issued an
ID on the topic; Jeff Mogul intends to issue a draft as
***************
*** 400,406 ****
14.33 Proxy-Authenticate ..............................141
14.34 Proxy-Authorization .............................142
- 14.35 Public ..........................................142
14.36 Range ...........................................143
14.36.1 ...............................Byte Ranges 143
14.36.2 ..................Range Retrieval Requests 144
--- 400,405 ----
***************
*** 2251,2259 ****
status code 405 (Method Not Allowed) if the method is known
by the server but not allowed for the requested resource,
and 501 (Not Implemented) if the method is unrecognized or
! not implemented by the server. The list of methods known by
! a server can be listed in a Public response-header field
! (section 14.35).
The methods GET and HEAD MUST be supported by all general-
purpose servers. All other methods are optional; however, if
--- 2250,2256 ----
status code 405 (Method Not Allowed) if the method is known
by the server but not allowed for the requested resource,
and 501 (Not Implemented) if the method is unrecognized or
! not implemented by the server.
The methods GET and HEAD MUST be supported by all general-
purpose servers. All other methods are optional; however, if
***************
*** 2320,2346 ****
absolute path cannot be empty; if none is present in the
original URI, it MUST be given as "/" (the server root).
- Editorial note: The proposed changes to OPTIONS will remove
- the following down to ***END***. See draft-ietf-http-options-00.txt
-
- 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:8001
-
- after connecting to port 8001 of host "www.ics.uci.edu".
-
- ***END***
-
The Request-URI is transmitted in the format specified in
section 3.2.1. The origin server MUST decode the Request-URI
in order to properly interpret the request. Servers SHOULD
--- 2317,2322 ----
***************
*** 2627,2633 ****
| Age ; Section 14.6
| Location ; Section 14.30
| Proxy-Authenticate ; Section 14.33
- | Public ; Section 14.35
| Retry-After ; Section 14.38
| Server ; Section 14.39
| Set-Proxy ; Section 14.48
--- 2603,2608 ----
***************
*** 3308,3348 ****
requirements associated with a resource, or the capabilities
of a server, without implying a resource action or
initiating a resource retrieval.
! Editorial note: The proposed changes to OPTIONS will change
! the following down to ***END***. See draft-ietf-http-
! options-00.txt.
!
! 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.
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.
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.
- ***END***
9.3 GET
--- 3283,3334 ----
requirements associated with a resource, or the capabilities
of a server, without implying a resource action or
initiating a resource retrieval.
+ Responses to this method are not cachable.
! If the OPTIONS request includes an entity-body (as indicated
! by the presence of Content-Length or Transfer-Encoding), then
! the media type MUST be indicated by a Content-Type field.
! Although this specification does not define any use for such
! a body, future extensions to HTTP may use the OPTIONS body to
! make more detailed queries on the server. A server that does not
! support such an extension MAY discard the request body.
If the Request-URI 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
! compliance (or lack thereof).
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 that indicate
! optional features implemented by the server and applicable to
! that resource (e.g., Allow), possibly including extensions not
! defined by this specification. The response body, if any,
! SHOULD also include information about the communication options.
! The format for such a body is not defined by this specification,
! but may be defined by future extensions to HTTP. Content
! negotiation MAY be used to select the appropriate response format.
! If no response body is included, the response MUST include a
! Content-Length field with a field-value of "0".
!
! The Max-Forwards request-header field MAY be used to target a
! specific proxy in the request chain. When a proxy receives an
! OPTIONS request on an absoluteURI for which request forwarding
! is permitted, the proxy MUST check for a Max-Forwards field.
! If the Max-Forwards field-value is zero ("0"), the proxy
! MUST NOT forward the message; instead, the proxy SHOULD respond
! with its own commmunication options. If the Max-Forwards
! field-value is an integer greater than zero, the proxy MUST
! decrement the field-value when it forwards the request.
! If no Max-Forwards field is present in the request, then the
! forwarded request MUST NOT include a Max-Forwards field.
9.3 GET
***************
*** 5913,5919 ****
. Connection
. Keep-Alive
- . Public
. Proxy-Authenticate
. Transfer-Encoding
. Upgrade
--- 5899,5904 ----
***************
*** 6750,6759 ****
14.7 Allow
- Editors Note: The OPTIONS changes would cause possible
- changes to Allow and/or Public for consistency with each
- other and with section 9.2 (OPTIONS).
-
The Allow entity-header field lists the set of methods
supported by the resource identified by the Request-URI. The
purpose of this field is strictly to inform the recipient of
--- 6735,6740 ----
***************
*** 6768,6774 ****
INTERNET-DRAFT HTTP/1.1 Wednesday, July 30, 1997
! Allow = "Allow" ":" 1#method
Example of use:
--- 6749,6755 ----
INTERNET-DRAFT HTTP/1.1 Wednesday, July 30, 1997
! Allow = "Allow" ":" #method
Example of use:
***************
*** 6791,6801 ****
user agent MAY have other means of communicating with the
origin server.
- The Allow header field does not indicate what methods are
- implemented at the server level. Servers MAY use the Public
- response-header field (section 14.35) to describe what
- methods are implemented on the server as a whole.
-
14.8 Authorization
--- 6772,6777 ----
***************
*** 8513,8523 ****
14.31 Max-Forwards
- Editor's note: The OPTIONS changes would allow Max-Forward
- with OPTIONS, not just with TRACE.
-
The Max-Forwards request-header field may be used with the
! TRACE method (section 14.31) to limit the number of proxies
or gateways that can forward the request to the next inbound
server. This can be useful when the client is attempting to
trace a request chain which appears to be failing or looping
--- 8489,8497 ----
14.31 Max-Forwards
The Max-Forwards request-header field may be used with the
! TRACE (section 9.8) and OPTIONS (section 9.2) methods to limit
! the number of proxies
or gateways that can forward the request to the next inbound
server. This can be useful when the client is attempting to
trace a request chain which appears to be failing or looping
***************
*** 8529,8547 ****
remaining number of times this request message may be
forwarded.
! 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. If the
! received value is zero (0), the recipient SHOULD NOT forward
! the request; instead, it SHOULD respond as the final
! recipient with a 200 (OK) response containing the received
! request message as the response entity-body (as described in
! section 9.8). If the received Max-Forwards value is greater
! than zero, then the forwarded message SHOULD contain an
! updated Max-Forwards field with a value decremented by one
! (1).
! The Max-Forwards header field SHOULD be ignored for all
other methods defined by this specification and for any
extension methods for which it is not explicitly referred to
as part of that method definition.
--- 8503,8518 ----
remaining number of times this request message may be
forwarded.
! Each proxy or gateway recipient of a TRACE or OPTIONS request
! containing a Max-Forwards header field MUST check and
update its value prior to forwarding the request. If the
! received value is zero (0), the recipient MUST NOT forward
! the request; instead, it MUST respond as the final recipient.
! If the received Max-Forwards value is greater than zero, then
! the forwarded message MUST contain an updated Max-Forwards
! field with a value decremented by one (1).
! The Max-Forwards header field MAY be ignored for all
other methods defined by this specification and for any
extension methods for which it is not explicitly referred to
as part of that method definition.
***************
*** 8650,8693 ****
cooperatively authenticate a given request.
- 14.35 Public
-
- Editors Note: The OPTIONS changes would cause possible
- changes to Allow and/or Public for consistency with each
- other and with section 9.2 (OPTIONS )
-
- The Public response-header field lists the set of methods
- supported by the server. The purpose of this field is
- strictly to inform the recipient of the capabilities of the
- server regarding unusual methods. The methods listed may or
- may not be applicable to the Request-URI; the Allow header
- field (section 14.7) MAY be used to indicate methods allowed
- for a particular URI.
-
- Public = "Public" ":" 1#method
-
- Example of use:
-
- Public: OPTIONS, MGET, MHEAD, GET, HEAD
-
- 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.
-
-
-
-
-
-
- Fielding, et al [Page 142]
-
-
-
- INTERNET-DRAFT HTTP/1.1 Wednesday, July 30, 1997
-
-
14.36 Range
--- 8621,8626 ----
***************
*** 9576,9594 ****
setting remains in effect for `integer' transactions.
- 14.49 Compliance
-
- Editor's note: The OPTIONS changes would introduce a new
- "Compliance" header.
-
-
- 14.50 Non-Compliance
-
- Editor's note: The OPTIONS changes would introduce a new
- "Compliance" header.
-
-
-
15 Security Considerations
--- 9509,9514 ----
***************
*** 10053,10062 ****
with which it is directly communicating is HTTP/1.1 and if
it supports the Set-Proxy header. To determine this, the
client or proxy should use the OPTIONS method to make a
! request check for this feature. The extension string should
! be HDR='set-proxy', or, should this be defined in the
! Standard RFC for HTTP/1.1, then the string should be
! RFC='rfcXXXX' in the OPTIONS request.
Great care should be taken when implementing client side
actions based on the 305 or 306. Since older proxies may
--- 9973,9979 ----
with which it is directly communicating is HTTP/1.1 and if
it supports the Set-Proxy header. To determine this, the
client or proxy should use the OPTIONS method to make a
! request check for this feature.
Great care should be taken when implementing client side
actions based on the 305 or 306. Since older proxies may
Received on Sunday, 16 November 1997 23:49:28 UTC