Subject: Why responses to the HTTP OPTIONS are uncachable ?

From: Filippos Vasilakis <[email-masked]>
Date: Fri, 29 Dec 2017 15:38:17 +0100

Hi my name is Filippos Vasilakis and I have a question. It's the first time
I email to this emailing list and I hope I am doing it in a correct way  in
the correct list.

According to RFC 7231: "Responses to the OPTIONS method are not cacheable."
What is the reasoning behind that statement ? Unfortunately that makes this
HTTP method pretty useless.

If we could lift this limitation, we could exploit this little method for
many cool things. Specifically by the same RFC:
"The OPTIONS method requests information about the communication options
available for the target resource, at either the origin server or an
intervening intermediary. This 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."

That makes it PERFECT way for exposing the capabilities of our resources,
regardless the action. There are some APIs that work like that (by exposing
their schemas through HTTP OPTIONS requests) but that's not ideal because
in theory clients shouldn't cache those responses.

Also in the same RFC:
"An OPTIONS request with an asterisk (“*”) as the request-target (Section
5.3 of [RFC7230]) applies to the server in general rather than to a
specific resource."

This could also be ideal for ideas like JSON Home (
https://tools.ietf.org/html/draft-nottingham-json-home).

All I am saying is that although the HTTP OPTIONS sounds (according to the
RFC 7231) like perfect for resource description/schemas/further resource
information yet the caching limitation makes it unusable, forcing API
designers to figure out different ways to serve these meta-information. Is
there any benefit to that limitation ? If no, would you consider lifting
that limitation, given that it's not a breaking change ?

Best,
Filippos

---

From: Mark Nottingham <[email-masked]>
Date: Sun, 31 Dec 2017 15:23:31 +0100

> On 29 Dec 2017, at 3:38 pm, Filippos Vasilakis <[email-masked]> wrote:
> 
> Hi my name is Filippos Vasilakis and I have a question. It's the first time I email to this emailing list and I hope I am doing it in a correct way  in the correct list.
> 
> What is the reasoning behind that statement?

Because HTTP caching stores representations of the state of the identified resource, and OPTIONS doesn't retrieve that state. 

> Unfortunately that makes this HTTP method pretty useless.

Yep. I wrote about this a while back:
  https://www.mnot.net/blog/2012/10/29/NO_OPTIONS

> If we could lift this limitation, we could exploit this little method for many cool things. Specifically by the same RFC:
> "The OPTIONS method requests information about the communication options available for the target resource, at either the origin server or an intervening intermediary. This 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."
> 
> That makes it PERFECT way for exposing the capabilities of our resources, regardless the action. There are some APIs that work like that (by exposing their schemas through HTTP OPTIONS requests) but that's not ideal because in theory clients shouldn't cache those responses.

Most people I know of are just putting that information at a separate URL, and either linking to that URL from the representation(s) of resource in question, or defining some way of discovering that URL (e.g., a site-wide mapping) given another URL.

That way, you get caching and everything else that GET gives you for free.

> Also in the same RFC:
> "An OPTIONS request with an asterisk (“*”) as the request-target (Section 5.3 of [RFC7230]) applies to the server in general rather than to a specific resource."
> 
> This could also be ideal for ideas like JSON Home (https://tools.ietf.org/html/draft-nottingham-json-home).

We have well-known URIs for that use case now:
  https://tools.ietf.org/html/rfc5785

> All I am saying is that although the HTTP OPTIONS sounds (according to the RFC 7231) like perfect for resource description/schemas/further resource information yet the caching limitation makes it unusable, forcing API designers to figure out different ways to serve these meta-information. Is there any benefit to that limitation ? If no, would you consider lifting that limitation, given that it's not a breaking change ?

That would require a pretty significant re-working of the caching specification to account for a third cache key (the method). Not impossible, but I think there'd need to be significant interest from cache implementers to do it. Using separate URLs is a *lot* easier.

Cheers,

--
Mark Nottingham   https://www.mnot.net/

---

From: Filippos Vasilakis <[email-masked]>
Date: Sun, 31 Dec 2017 19:48:17 +0100

I think by looking the protocol/RFC in a post-mortem way I can say that it
would have been better to let the server decide and denote the caching
properties of HTTP OPTIONS response body using the regular caching headers
of HTTP rather than completely disallow caching on that method. The RFC
could only advice against it. I understand that any changes would require
more people asking for it so I didn't have much hope :P In any case thanks
for the answer.

Best,
Filippos

On Sun, Dec 31, 2017 at 3:23 PM, Mark Nottingham <[email-masked]> wrote:

> > Hi my name is Filippos Vasilakis and I have a question. It's the first
> time I email to this emailing list and I hope I am doing it in a correct
> way  in the correct list.
> >
> Because HTTP caching stores representations of the state of the identified
> resource, and OPTIONS doesn't retrieve that state.
>
> > If we could lift this limitation, we could exploit this little method
> for many cool things. Specifically by the same RFC:
> > That makes it PERFECT way for exposing the capabilities of our
> resources, regardless the action. There are some APIs that work like that
> (by exposing their schemas through HTTP OPTIONS requests) but that's not
> ideal because in theory clients shouldn't cache those responses.
>
> Most people I know of are just putting that information at a separate URL,
> and either linking to that URL from the representation(s) of resource in
> question, or defining some way of discovering that URL (e.g., a site-wide
> mapping) given another URL.
>
> > "An OPTIONS request with an asterisk (“*”) as the request-target
> (Section 5.3 of [RFC7230]) applies to the server in general rather than to
> a specific resource."
> >
> > All I am saying is that although the HTTP OPTIONS sounds (according to
> the RFC 7231) like perfect for resource description/schemas/further
> resource information yet the caching limitation makes it unusable, forcing
> API designers to figure out different ways to serve these meta-information.
> Is there any benefit to that limitation ? If no, would you consider lifting
> That would require a pretty significant re-working of the caching
> specification to account for a third cache key (the method). Not
> impossible, but I think there'd need to be significant interest from cache
> implementers to do it. Using separate URLs is a *lot* easier.
>
> Cheers,
>
> --