Re: Why responses to the HTTP OPTIONS are uncachable ?

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 <mnot@mnot.net> wrote:

>
>
> > 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/
>
>
>