OPTION call always returns cache status DYNAMIC

Website, Application, Performance
1

Hi Guys,

I need some help here, Ive a proxied dns, I have a page rule with settings:
Cache Level: Cache Everything, Edge Cache TTL: 30 minutes
BUT when my browser or curl executes an OPTION call, its always a cf-cache-status : DYNAMIC response. The real call has a cache HIT status, why is the OPTION call DYNAMIC and not covered by my page rule? Do you need a specific page rule for the options/preflight calls?

Cloudflare response:

curl 'xxx' -X 'OPTIONS' -i

HTTP/2 204 

**date** : Wed, 11 Nov 2020 16:34:43 GMT

**set-cookie** : __cfduid=dead61958d445e601ff2c7c24a9b9870a1605112483; expires=Fri, 11-Dec-20 16:34:43 GMT; path=/; domain=.spott.ai; HttpOnly; SameSite=Lax; Secure

**access-control-allow-origin** : *

**access-control-allow-methods** : POST, GET, OPTIONS, DELETE, PUT, PATCH

**access-control-allow-headers** : x-requested-with, Content-Type, Content-Length, Content-Range, Content-Encoding, origin, authorization, accept, client-security-token, authtoken, api_key, Accept-Language, device_type, application_id, custom_http_referer, client_id

**access-control-expose-headers** : Content-Type, Content-Length, Content-Range, Content-Encoding

**access-control-max-age** : 1728000

**cf-cache-status** : DYNAMIC

**cf-request-id** : xxx

**expect-ct** : max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"

**server** : cloudflare

**cf-ray** : xxx-AMS

Response of my origin server is:

HTTP/1.1 204 OK

**Content-Type** : text/plain charset=UTF-8

**Server** : nginx

**Access-Control-Allow-Origin** : *

**Access-Control-Allow-Methods** : POST, GET, OPTIONS, DELETE, PUT, PATCH

**Access-Control-Allow-Headers** : x-requested-with, Content-Type, Content-Length, Content-Range, Content-Encoding, origin, authorization, accept, client-security-token, authtoken, api_key, Accept-Language, device_type, application_id, custom_http_referer, client_id

**Access-Control-Expose-Headers** : Content-Type, Content-Length, Content-Range, Content-Encoding

**Access-Control-Max-Age** : 1728000

**Date** : Wed, 11 Nov 2020 18:25:13 GMT

**Content-Length** : 0

Thanks for your help!

2

Hi there,

Unfortunately OPTIONS requests (the pre-flight requests before API calls) aren’t cacheable per RFC (See 4.3.7 OPTIONS: RFC 7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content)

In case the customer’s origin is down - although the API response might be in Cloudflare’s cache - a browser would fail in receiving CORS headers from the OPTIONS request. Luckily responses to OPTIONS requests are simply some special CORS HTTP headers with no HTTP payload itself, so we can deliver those OPTIONS response(s) from a Worker script.

We have an example Worker script that can be used to handle OPTIONS requests separately from other methods CORS header proxy · Cloudflare Workers docs

You can also find additional documentation about the other CORS response headers, see The HTTP Response headers at Cross-Origin Resource Sharing (CORS) - HTTP | MDN

2 Likes