Snippets help
Only concern at the moment is exception handling in snippets, what’s the best way?
If any type of error occurs in the snippet how would I know and how should I handle it?
In workers, I’d either catch exceptions and log/report or use tail and send to sentry for example. Can also see error analytics in workers/etc but not for snippets.
8 Replies
(sorry, just saw your message in the channel)
cc @ncano :MeowHeartCloudflare:
For now I recommend putting a try/catch around your entire snippet - since it can have multiple subrequests now (yayy), what I've done is reserve one subrequest to logging everything from the snippet
Thank you! I’m finding that snippets are a good way to prevent unwanted traffic hitting workers and running up request count :).
for that, you can also look at waf rules and api shield, could help block invalid requests early
Do snippets not return CF-Cache-Status?
And managed transforms must run after snippets?
cf-cache-status is coming from Cache (Pingora), so if your snippet doesn't go to origin this header won't be present
managed transforms run before Snippets: https://developers.cloudflare.com/ruleset-engine/reference/phases-list/
Cloudflare Docs
Phases list | Cloudflare Ruleset Engine docs
The following tables list the phases of Cloudflare products powered by the Ruleset Engine, in the order those phases are executed. Some products such as the Cloudflare Web Application Firewall have more than one associated phase.
Thanks @ncano
With Managed Transforms -> Add security headers it appears that the x-frame-options header for example is still in the response. Should that be the case? If not, might be me.
Other question, I’m trying to set a unique request id header in a snippet then in a worker read that back and continue to pass it along to origin, however in the worker that header is not there. Am I missing something?
it's not you, managed transforms have two phases: request phase runs before Snippets, response phase runs after Snippets; x-frame-options is added in the response phase, hence you still see this header present
for Workers <> Snippets, i've tested it and i can access a header that is set by snippet from a worker and it is sent further down the stream to the origin
this is my simple snippet:
export default {
async fetch(request) {
// Get the current timestamp
const timestamp = Date.now();
// Convert the timestamp to hexadecimal format
const hexTimestamp = timestamp.toString(16);
// Clone the request and add the custom header
const modifiedRequest = new Request(request, {
headers: new Headers(request.headers)
});
modifiedRequest.headers.set("X-Hex-Timestamp", hexTimestamp);
// Log the custom header for debugging
console.log(X-Hex-Timestamp: ${hexTimestamp});
// Pass the modified request to the origin
const response = await fetch(modifiedRequest);
return response;
},
};
and then i have this worker reading this header, passing it to the origin and including it in response too:
export default {
async fetch(request) {
let u = new URL(request.url);
const response = await fetch("https://{redacted}/info.php", request);
// Clone the response so that it's no longer immutable
const newResponse = new Response(response.body, response);
var hexTimestamp = 'null';
try {
hexTimestamp = request.headers.get("X-Hex-Timestamp");
console.log(hexTimestamp)
}
catch(err) { console.log(err); }
newResponse.headers.set("X-Hex-Timestamp", hexTimestamp);
return newResponse;
}
}