rdutton
rdutton
CDCloudflare Developers
Created by codebam on 2/13/2025 in #workers-help
`wrangler dev --local` says I don't have a scheduled() function but I clearly have one
Reading the docs they mention running: npx wrangler dev --test-scheduled to test crons.
6 replies
CDCloudflare Developers
Created by Gusttavo13 on 2/4/2025 in #workers-help
I can't use fetch in workers
Should the line return new Response(JSON.stringify(response.json()), { be return new Response(JSON.stringify(await response.json()), { ?
2 replies
CDCloudflare Developers
Created by xeon06 on 2/4/2025 in #workers-help
Build timeout at npm install?
I assume that if you build locally it doesn't timeout at npm install? Also, are you checking in your package-lock.json? If not, what happens if you delete that file locally (back up first) then npm install?
6 replies
CDCloudflare Developers
Created by Sergey A on 2/4/2025 in #workers-help
The response of a fetch() request in worker is different from same request in any other environment
I don't know of any programmatic way to get the IP actually used by the fetch() .. I get the following headers on the 403 response panel: hpanel platform: hostinger so it does seem to be a hostinger server responding. Are you able to see the successful/failed requests in Hostinger's access logs? https://support.hostinger.com/en/articles/5650167-how-to-use-the-analytics-section-on-hpanel#h_0060feb18e
15 replies
CDCloudflare Developers
Created by Sergey A on 2/4/2025 in #workers-help
The response of a fetch() request in worker is different from same request in any other environment
I see what you mean, I created a basic test and when I run it locally or with --remote I get "PHP test 45.80.182.143". As soon as I deploy it onto Cloudflare. I get the 403 Forbidden page. As per Hard@Work | R2's comment, the Hostinger server is selectively blocking Cloudflare addresses. Is your Hostinger account a VPS, if so can you try this : https://support.hostinger.com/en/articles/4805502-how-to-set-up-a-firewall-at-vps#h_2a7483333c . Otherwise, I would reach out to their support.
15 replies
CDCloudflare Developers
Created by Sergey A on 2/4/2025 in #workers-help
The response of a fetch() request in worker is different from same request in any other environment
When i run dig a blog.xolotto.com @1.1.1.1 i get an A record with 104.22.52.117 (and 2 other results) which looks like you are proxying blog.xolotto behind Cloudflare. Is there anything in your Analytics / Security logs area in Cloudflare? You could temporarily try modifying the 'security level' or turn off proxying.
15 replies
CDCloudflare Developers
Created by TheLegendVibes on 2/1/2025 in #workers-help
POST method is not working in fetch inside Queue Handler
You are awaiting the individual requests, but I think you also need to await the 'queueHandler' function itself. Try changing queueHandler(batch, c) to await queueHandler(batch, c)
5 replies
CDCloudflare Developers
Created by psps on 2/1/2025 in #workers-help
White label my app/service workers.
I think what you are suggesting is a 'single tenant' approach where each domain (customer?) has their own deployment. This would allow for each deployment to have it's own env vars. In order to do this and make it automated, you would need a management system that dynamically creates multiple workers using Cloudflare API. Note that there is a 500 worker limit for the paid workers plans so you will eventually hit a limit. Not trivial IMO. I don't think there is any other way to do this .. can someone confirm? There may be good reasons why it's not feasible (e.g. different code versions per deployment), but I would consider a 'multi tenant' approach if you can. This would mean one deployment. a.com and b.com just need to be a cname that points to your designated worker domain. The initial code could detect the incoming domain requested and retrieve the appropriate env data from a central data-source, rather than from the standard worker env.
6 replies
CDCloudflare Developers
Created by veeque on 1/29/2025 in #pages-help
What's the difference between Cloudflare Pages and Workers Frameworks?
I have a monolithic (Remix framework) app that is in production on Pages. Because Pages lacks certain things like queue consumption I've had to supplement my app with workers to fill in these gaps. This kind of ruins the goal of keeping everything in one deployment. It's now possible to run Remix on workers, most likely due to the addition of static assets support, so I'm looking to switch from pages to workers. IMO unless there is something you absolutely need that pages provides, use workers.
14 replies
CDCloudflare Developers
Created by Rick on 1/24/2025 in #workers-help
unable to lazy load images
Did you manage to work out what was going on? To me it sounds like a front-end issue rather than a workers one, particularly since there is nothing in the network tab. Please note, when loading="lazy" is specified on an image element, the browser only loads the resource if the element is 'in view' and this includes if the element has no natural height or width. Given your example code it's indeterminate whether the images have any width/height allocated to them, so try setting the height and width on them and see what happens. e.g. <img src="/avatars/32606955_7942348.jpg" alt="logo" loading="lazy" height="100" width="100"/>
4 replies
CDCloudflare Developers
Created by UfoX1 on 1/23/2025 in #workers-help
Images on CF
No probs at all. Been meaning to research the cache myself, looks to be quite useful.
16 replies
CDCloudflare Developers
Created by UfoX1 on 1/23/2025 in #workers-help
Images on CF
Noting that you need to specify a cache-control header on the response stored using caches.default.put
16 replies
CDCloudflare Developers
Created by UfoX1 on 1/23/2025 in #workers-help
Images on CF
const html_form = "<form method=post action='/' enctype='multipart/form-data'>Image Attachment<br/><input name='upload' type='file' accept='image/png'/><br/><button type=submit>Upload</button></form>"; export default { async fetch(request, env, ctx) { const url = new URL(request.url); if (url.pathname === '/test.png') { let cache = caches.default; const cache_response = await caches.default.match(request); if (cache_response) { return cache_response; } const response = new Response(await env.TESTKV.get("test.png", "arrayBuffer"), { headers: { 'content-type': 'image/png', 'Cache-Control': 's-maxage=10' }, }); await caches.default.put(request, response.clone()); console.log("Cache updated"); return response; } let upload_detail = ""; if (request.method === 'POST') { const form = await request.formData(); const file = form.get('upload'); let value = await env.TESTKV.put("test.png", await file.arrayBuffer()); upload_detail = "File uploaded successfully<br/><img src='test.png'/>"; } return new Response(upload_detail + html_form, { headers: { 'content-type': 'text/html' }, }); } };
16 replies
CDCloudflare Developers
Created by UfoX1 on 1/23/2025 in #workers-help
Images on CF
The 2nd example avoids base64, so that is better and more efficient, however every request is still going to read from KV and incur cost in high volumes. To avoid that you will need utilise the Cloudflare cache. I haven't used it, but from what I can tell the cache is effectively a CDN you can manipulate via a worker.
16 replies
CDCloudflare Developers
Created by UfoX1 on 1/23/2025 in #workers-help
Images on CF
No probs 🙂
16 replies
CDCloudflare Developers
Created by AI on 1/21/2025 in #workers-help
browser rendering api pricing
Agree the cost is high, so is the convenience. Building your own stable Puppeteer/Playwright service that also scales can be tricky.
3 replies