Added notes for cache request hostnames

[ToriLindsay]

Added notes - Do not use dynamic or invalid hostnames in cache requests. This can cause DNS cache failures and latency.

[cloudflare-workers-and-pages]

Deploying cloudflare-docs with    Cloudflare Pages

Latest commit:	077b5f7
Status:	✅  Deploy successful!
Preview URL:	https://c8cc55dd.cloudflare-docs-7ou.pages.dev
Branch Preview URL:	https://tori-pcx6484-cache-hostname.cloudflare-docs-7ou.pages.dev

View logs

[github-actions]

Files with changes (up to 15)

Original Link	Updated Link
https://developers.cloudflare.com/workers/runtime-apis/cache/	https://tori-pcx6484-cache-hostname.cloudflare-docs-7ou.pages.dev/workers/runtime-apis/cache/

[mikenomitch]

I think we should be more explicit. We should say that the hostname used in the cache request should match your hostname.

And then instead of "DNS cache failures" I'd say "a DNS lookup" which will significantly increase latency.

[mikenomitch]

I think if they use "request.headers.host" that'd be the correct hostname to use in all cases? I could be wrong about this though

EDIT: Err... we don't need to specify this since they'll just be passing the whole request object in.

I might say "Do not override the hostname in the request or use a hostname that differs from your own"?

[irvinebroque]

Needs more context — show vs. just tell

[ToriLindsay]

@mikenomitch @irvinebroque Thank you for the feedback! I updated the note with the details from Mike. An example could also be included if you think that's necessary to show it more explicitly? Let me know your thoughts.

[irvinebroque]

Same feedback as previously — show vs. tell

[mikenomitch]

Indentation on this JS is a bit off. Everything within the brackets should be indented once.

Though actually, this also isn't valid fetch code. You would need to return the response from myCache.match(request) in order for it to be valid.

But... that doesn't really make sense because you might have a cache miss and you'd have to handle that (see this full code - https://developers.cloudflare.com/workers/examples/cache-api/)

I think since we don't want to show all of that code in here, what we should do is just drop the fetch() bits completely? It might be a tad less clear where request is coming from in this case, but I think it's fine.

So I'd just do

// avoid overriding the URL in request or passing a new request into the cache API
request.url = "https://some-overridden-value.com/";

let myCache = await caches.open('custom:cache');
let response = await myCache.match(request);

If it'll never work then I'd add this above the last line "// will never work because URL doesn't match Worker's domain"

[mikenomitch]

Looks good!

[ToriLindsay]

@irvinebroque Ready for your re-review. I believe I need your approval as well for this to be unblocked. Thank you!

[irvinebroque]

Seems like we should suggest what people should do instead?

[hyperlint-ai]

Howdy and thanks for contributing to our repo. The Cloudflare team reviews new, external PRs within two (2) weeks. If it's been two weeks or longer without any movement, please tag the PR Assignees in a comment.

We review internal PRs within 1 week. If it's something urgent or has been sitting without a comment, start a thread in the Developer Docs space internally.

---

PR Change Summary

Added notes regarding the use of valid hostnames in cache requests to prevent DNS cache failures and latency issues.

• Introduced a note advising against the use of dynamic or invalid hostnames in cache requests.
• Provided an example demonstrating the incorrect use of overridden hostnames.
• Clarified the importance of using hostnames that match the domain associated with the Worker.

Modified Files

• src/content/docs/workers/runtime-apis/cache.mdx

---

How can I customize these reviews?

Check out the Hyperlint AI Reviewer docs for more information on how to customize the review.

If you just want to ignore it on this PR, you can add the hyperlint-ignore label to the PR. Future changes won't trigger a Hyperlint review.

Note specifically for link checks, we only check the first 30 links in a file and we cache the results for several hours (for instance, if you just added a page, you might experience this). Our recommendation is to add hyperlint-ignore to the PR to ignore the link check for this PR.

[ToriLindsay]

Seems like we should suggest what people should do instead?

@irvinebroque Makes sense. I updated it again. Ready for your review when you have a chance. Thank you!