<Image> in SSR page response 404 when deploy Cloudflare Works

[sgalcheung]

Astro Info

Astro                    v5.6.1
Node                     v18.20.3
System                   macOS (x64)
Package Manager          pnpm
Output                   static
Adapter                  @astrojs/cloudflare
Integrations             astro-icon
                         set-prerender

If this issue only occurs in one browser, which browser is a problem?

No response

Describe the Bug

The image configuration is here

image: {
    service: passthroughImageService(),
  },
  adapter: cloudflare({
    imageService: "passthrough",
  }),

The image display is right in the dev.
Deploy page also works well: https://develop.balanced-chef.pages.dev/
But have trouble with CF works: https://balanced-chef.sgalwork.workers.dev/

for example fetch image: howm.Dr0NQRDu.jpg
The image URL is here: https://balanced-chef.sgalwork.workers.dev/_astro/howm.Dr0NQRDu.jpg
But _image endpoint return Not Found 404

What's the expected result?

Resolved the image.

Link to Minimal Reproducible Example

https://github.com/sgalcheung/balanced-chef

Participation

• I am willing to submit a pull request for this issue.

[ascorbic]

Hi. Can you provide a minimal repro. Using a full site like the one you provided makes it hard for us to isolate the source of a problem.

[github-actions]

Hello @sgalcheung. Please provide a minimal reproduction using a GitHub repository or StackBlitz. Issues marked with needs repro will be closed if they have no activity within 3 days.

[sgalcheung]

I tried this React demo, still have this problem.

I also created an issue to Cloudflare Support: https://community.cloudflare.com/t/cant-fetch-self-assert-in-workers/800037

This fetch method is here:

astro/packages/astro/src/assets/endpoint/generic.ts

Line 12 in dde8fd9

const res = await fetch(src, {

We try to fetch the image(https://balanced-chef.sgalwork.workers.dev/_astro/howm.Dr0NQRDu.jpg), but this is not successful. I guess this is a CF gateway problem; they can't fetch the self-hosted app assert.

[sgalcheung]

@ascorbic But this seems to be a Cloudflare Workers design feature; they need to use the env.ASSET.fetch() method instead. @alexanderniebuhr

export default {
  async fetch(request, env) {
    // Wrong approach: Direct access via URL
    // const response = await fetch('https://your-worker.workers.dev/asset.png');
    
    // Correct approach: Use env.ASSET.fetch()
    const response = await env.ASSET.fetch(new Request('https://your-worker.workers.dev/asset.png'));
    
    return response;
  }
}

Therefore, we shouldn't use passthroughImageService; we should use a custom handler with env.ASSET.fetch().

[alexanderniebuhr]

I need to look at the example to fully understand the issue, but using internal bindings is always the better approach anyways.

[sgalcheung]

Hello, I added a mini-repo: astro-cloudflare-workers-demo.

[sgalcheung]

I have just created a Cloudflare Astro framework demo using npm create cloudflare@latest, and I noticed the wrangler.jsonc file has a flag global_fetch_strictly_public in compatibility_flags, I reference this doc:

When the global_fetch_strictly_public compatibility flag is enabled, the global fetch() function will strictly route requests as if they were made on the public Internet.

This means requests to a Worker's own zone will loop back to the "front door" of Cloudflare and will be treated like a request from the Internet, possibly even looping back to the same Worker again.

When the global_fetch_strictly_public is not enabled, such requests are routed to the zone's origin server, ignoring any Workers mapped to the URL and also bypassing Cloudflare security settings.

reference Global fetch() strictly public

Then, I added the flag to astro-cloudflare-workers-demo, now it works well at /hello.

Enable this feature, and the app will force all fetch() calls to go through the public network, which ensures security but may introduce loops or delays.

Or should we write code Astro.locals.runtime.env.ASSETS.fetch(request.url); for passthrough?

[alexanderniebuhr]

Interesting. That flag seems to be new. I still haven't had time to look into your code, sorry.

[Baraban511]

I had the same problem before adding the flag global_fetch_strictly_public. It looks like prerendered images /_astro/ works correctly, but on-demand rendered images /_images doesn't. Even for cloudflare own image resizing tool it wasn't woking (404).
I've seen the 1042 error code referring to same worker fetching on on-demand rendered images. Any progress?