How do I avoid breaking the image resizer when running a Worker?

Developers Workers
1

I have URLs I want to use a worker on but it breaks the image resizer which I do not want to modify.

I can detect the page(s) I want to address, but how do I return from the worker and allow the image resizer to process the URL ?
If I just return or return true, it skips processing the resizer.

I have a page rule like this: *www.example.com/*.html which would work if the Worker route would accept the same match patterns as Page Rules, but it will only accept wildcards at the beginning and end.

So I need to either :

  1. have a wildcard in the middle of the Worker route pattern (ideal), or
  2. get the Worker return back in a way that would allow the regular process to continue as though the Worker never intercepted the call, and let the resizer do its job.
2

Just to be more clear, this is the starter code when you create a new Worker, this will break the image resizerā€¦

addEventListener('fetch', event => {
  event.respondWith(handleRequest(event.request))
})

/**
 * Fetch and log a request
 * @param {Request} request
 */
async function handleRequest(request) {
  console.log('Got request', request)
  const response = await fetch(request)
  console.log('Got response', response)
  return response
}
3

Hey @scott5, when you say ā€œimage resizerā€, do you mean Cloudflareā€™s image resizer product?

Assuming that youā€™re using the default URL format for the image resizer (docs here), you should still be able to proxy requests through a Workers script and basically do a pass-through:

async function handleRequest(request) {
  let response
  if (request.url.includes("/cdn-cgi/image/")) {
    // _should_ proxy to image resizer correctly
    response = await fetch(request)
  } else {
    // Make a new, non-image resizer request
  } 
  
  return response
}
4

Thank you for your response.

Yes I did try to just return when no processing was required however the Worker seems to return in such a way that is not compatible to the image resizer.

The returned image is just the original size image, so it works in that the request is still handled by the resizer (because that URL is not on my server obviously) but the parameters seem to be lost.

I tried your code:

async function handleRequest(request) {
  let response
  if (request.url.includes("/cdn-cgi/image/")) {
    response = await fetch(request)
  } else {
    response = await fetch(request)
  } 

  return response
}

which should do nothing, and indeed the site looks fine but the images are all large.

I only want the Worker to process files ending in ā€˜.htmlā€™ but the Route setting will only allow a wildcard at the beginning and end but not in the middle like a Page Rule.

Fixing the Worker to work with the resizer is not as good a solution as only calling the Worker when it is needed with a wildcard in the middle of the Route name.

  • Scott
5

interesting, @scott5! Iā€™ll ask the team and see if this is a known issue. thanks!

3 Likes
6

Btw a Logflare user reported this issue as well.

Anything I can do to not break Cloudflares image resizer?

7

This service (resizer) worked really well but due to the cost we have decided not to proceed.

We use the GD library in PHP for resizing and although the Coudflare resizer has more functionality and is 100x faster than GD it was only a convenience not a necessity. (Magento saves the GD result so it only fires once, ever)

I have switched back to GD so I can now use the Workers as I originally wanted to do which is good.

BTW, I get a 10ms quicker TTFB bypassing the resizer, probably not a big deal for most people, but worth a mention.

  • Scott
8

@signalnerve do you know if this is on their radar? Got a couple of reports of this with people using the image resizer and Logflare.