Well-Known Resources for HTTP OPTIONS

HTTP says the OPTIONS method “allows a client to determine the options and/or requirements associated with a resource, or the capabilities of a server, without implying a resource action.” [RFC7231]

CORS [W3C.REC-cors-20140116] uses OPTIONS to perform a “pre-flight” request to determine whether a given resource will allow a state-changing cross-origin request.

This has some unfortunate deployment characteristics. In particular, because OPTIONS is not cacheable, an intermediary will forward each and every pre-flight request to the origin server, adding potentially substantial delay to interaction. For high-volume services, the bandwidth overhead can be more than trivial, since OPTIONS does not support conditional requests [RFC7232].

Furthermore, because OPTIONS responses don’t have distinct URLs, it’s difficult to incorporate them into the Web; for example, if they were to be cached, a cache invalidation mechanism would have to convey the method as well as the URL to be able to invalidate them separately.

This document defines a well-known URI [RFC5785] that “http://” and “https://” origin servers can use to assign distinct URLs for their OPTIONS responses, thereby making them fully available as resources on the Web, as well as cacheable.

1.1 Notational Conventions

The ‘options’ well-known URI [RFC5785] defines a space whereby an origin server exposes a set of options resources, each which operates in an identical fashion to the corresponding target resource on the origin server, except that they respond to GET requests as if the method had been OPTIONS.

http://example.com/ -> http://example.com/.well-known/options/
https://example.com/ -> https://example.com/.well-known/options/
http://example.org/foo -> http://example.org/.well-known/options/foo
http://example.org/?bar -> http://example.org/.well-known/options/?bar

OPTIONS /foo HTTP/1.1
Host: example.com

GET /.well-known/options/foo HTTP/1.1
Host: example.com

The well-known URI “/.well-known/options” (note the lack of a trailing “/”) itself is used as a resource for “OPTIONS *”.

2.1 Client Operation

2.2 Origin Server Operation

2.3 Intermediary Operation

This document registers the value “options” in the Well-Known URI Registry [RFC5785].

• URI suffix: options
• Change controller: Mark Nottingham mnot@mnot.net
• Specification document(s): [this document]
• Related information: Registered for “http” and “https” URI schemes.

Options URLs have similar security considerations to using OPTIONS on target URLs. However, because they can be cached, servers need to be careful to set appropriate caching policy.

The obvious benefit of deploying this specification is that it allows HTTP “reverse” proxies and Content Delivery Networks to cache and serve OPTIONS responses. However, this requires OPTIONS requests to be transformed into options URLs at some point.

This transformation can be done in user agents, intermediaries and origin servers.

For example, user agents can decide to use options URLs for internal caching purposes, and emit requests for them when they know the server supports this specification.

Intermediaries can translate incoming OPTIONS requests into options URLs when they know the origin server supports them, and can reason about OPTIONS requests using them internally.

Origin servers can translate options URLs into OPTIONS requests internally with a fairly simple modification.

These transformations need not be coordinated, and can happen concurrently as long as clients conform to the requirements upon them in Section 2.1.