CF-Cache-Status "Bypass" - Why?

[jalalio]

I have set up a Caching Rule to cache requests from an (authenticated) endpoint:

but the status keeps being “Bypass”:

• No cookies are set from the server

I also tried it via Page Rules (1st rule). Same issue. I don’t know anymore how to continue…

[smitchell]

Hey @jalalio,

I believe it is because you are using the “URI Full” field which also filters by parameters passed in the get request, try using “URI Path”

Best,
Sean

[jalalio]

Thanks, @smitchell. The rule has the operator “starts_with” so I guess that should be fine as well. Tried “URI Path” as well now, same issue.

For other domains, “Page Rules” for caching worked, but cannot get it done with this one somehow.

[jalalio]

Here are the origin headers:

[simon]

You say “cache requests from an authenticated endpoint” - how is the authentication done for each request? BYPASS typically means your origin is either returning instructions not to cache (via cache-control or expires) or is returning cookies implying a dynamic response.

Sometimes its useful to use cURL just to send the request direct to your origin:

curl https://example.com/my-url --compressed --silent --verbose --output /dev/null --connect-to ::1.2.3.4

And replace the URL with your URL and 1.2.3.4 with your origin IP.

[jalalio]

Thanks @simon.taylor

The authentication is done via the authorization header and a Bearer token.

Here is the curl output:

* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*  CAfile: /etc/ssl/cert.pem
*  CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
} [232 bytes data]
* TLSv1.2 (IN), TLS handshake, Server hello (2):
{ [104 bytes data]
* TLSv1.2 (IN), TLS handshake, Certificate (11):
{ [4028 bytes data]
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
{ [300 bytes data]
* TLSv1.2 (IN), TLS handshake, Server finished (14):
{ [4 bytes data]
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
} [37 bytes data]
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
} [1 bytes data]
* TLSv1.2 (OUT), TLS handshake, Finished (20):
} [16 bytes data]
* TLSv1.2 (IN), TLS change cipher, Change cipher spec (1):
{ [1 bytes data]
* TLSv1.2 (IN), TLS handshake, Finished (20):
{ [16 bytes data]
* SSL connection using TLSv1.2 / ECDHE-RSA-CHACHA20-POLY1305
* ALPN, server accepted to use http/1.1
* Server certificate:
*  subject: CN=mydomain.com
*  start date: Dec 11 12:33:26 2022 GMT
*  expire date: Mar 11 12:33:25 2023 GMT
*  subjectAltName: host "mydomain.com" matched cert's "mydomain.com"
*  issuer: C=US; O=Let's Encrypt; CN=R3
*  SSL certificate verify ok.
> GET /indexes/feeds/search?attributesToCrop=description&attributesToHighlight=*&cropMarker=[...]&q=teds HTTP/1.1
> Host: smydomain.com
> Accept-Encoding: deflate, gzip
> authority: mydomain.com
> accept: application/json, text/plain, */*
> accept-language: en-GB,en-US;q=0.9,en;q=0.8
> authorization: Bearer MY_TOKEN
> origin: https://mydomain.com
> referer: https://mydomain.com/
> sec-fetch-dest: empty
> sec-fetch-mode: cors
> sec-fetch-site: same-site
> sec-gpc: 1
> user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/108.0.0.0 Safari/537.36
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Server: nginx/1.14.2
< Date: Sat, 31 Dec 2022 14:01:16 GMT
< Content-Type: application/json
< Transfer-Encoding: chunked
< Connection: keep-alive
< access-control-allow-origin: *
< vary: Origin, Access-Control-Request-Method, Access-Control-Request-Headers
< vary: accept-encoding
< content-encoding: deflate
<
{ [107 bytes data]
* Connection #0 to host MY_IP left intact

[simon]

I think the authorisation part is causing the BYPASS here:

"authorization" header causes "cf-cache-status: BYPASS" regardless of "cacheEverything"

I’d like to cache a response from authentication-required server. However, setting “authorization” header interferes cache: the result will always be “BYPASS” (without the header, it can be “MISS” or “HIT”). Setting cacheEverything option does not solve the issue. Here is the simple example. addEventListener('fetch', event => { event.respondWith(handleRequest(event)) }) async function handleRequest(event) { const headers = new Headers(); // Comment out this line solves the issue. he…

From our docs on Origin cache-control:

Origin Cache Control · Cloudflare Cache (CDN) docs

Condition	Origin Cache-control disabled behavior	Origin Cache-control enabled behavior
Presence of Authorization header	Content may be cached	Content is cached only if must-revalidate, public, or s-maxage is also present

So you either would need to disable Origin Cache Control as well or set the specified cache-control headers along with the response.

[jalalio]

Thanks @simon.

The origin does not send any cache control headers.

Doesn’t below disable/override the cache control of the origin?:

[jalalio]

Found it via “Page Rules”. It works via those settings:

PLUS “Cache Rules” (doesn’t work without it):

Many thanks @simon!

[simon]

Glad you found it - disabling Origin Cache Control is risky because that setting ensures we respect the origins cache instructions. So if you can modify your origin response headers so you don’t need to disable, I would recommend that.