W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2017

Re: Why responses to the HTTP OPTIONS are uncachable ?

From: Mark Nottingham <mnot@mnot.net>
Date: Sun, 31 Dec 2017 15:23:31 +0100
Cc: ietf-http-wg@w3.org
Message-Id: <A3E0F282-1353-487F-9AAA-7E7636F14B3A@mnot.net>
To: Filippos Vasilakis <vasilakisfil@gmail.com>


> On 29 Dec 2017, at 3:38 pm, Filippos Vasilakis <vasilakisfil@gmail.com> 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.
> 
> According to RFC 7231: "Responses to the OPTIONS method are not cacheable."
> 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/
Received on Sunday, 31 December 2017 14:23:59 UTC

This archive was generated by hypermail 2.3.1 : Sunday, 31 December 2017 14:24:07 UTC