Could __og_image__ be a route instead of a middleware?

[dargmuesli]

Details

Currently, /__og_image__'s content is set by a middleware. As this middleware returns content, I think other modules' middlewares cannot modify the returned content, e.g. nuxt-security adding a nonce.

How would it be possible for other middleware to modify that page? Should the linked middleware be implemented as a nitro route instead maybe?

[harlan-zw]

Yes, this would be ideal, when I implemented the module there wasn't support for registrating routes as /**/__og_image__/og.png.

Afaik this still isn't supporting but something that would be good to solve upstream for use-cases like this.

[dargmuesli]

Couldn't the route be restructured so that https://example.com/legal-notice/__og_image__/og.png is under https://example.com/__og_image__/legal-notice/og.png (or similar) instead? But I'm sure you have a very valid reason to append __og_image__, most likely related to static output I can imagine 😉

I want to ask still because I can imagine that there are difficulties in how to map /**/__og_image__/og.png using the current route match algorithm. So maybe there could be a different route layout which complies with the existing algorithm. Just thinking out loud here.

[dargmuesli]

Or maybe .../__og_image__/ must be added algorithmically for every existing page route in a loop or such?

[harlan-zw]

Couldn't the route be restructured so that https://example.com/legal-notice/__og_image__/og.png is under https://example.com/__og_image__/legal-notice/og.png (or similar) instead? But I'm sure you have a very valid reason to append __og_image__, most likely related to static output I can imagine 😉

I want to ask still because I can imagine that there are difficulties in how to map /**/__og_image__/og.png using the current route match algorithm. So maybe there could be a different route layout which complies with the existing algorithm. Just thinking out loud here.

Could be worth exploring 👍 I had planned to add support for customising the endpoint so can explore when I do that.

[harlan-zw]

Or maybe .../__og_image__/ must be added algorithmically for every existing page route in a loop or such?

What about dynamic routes 😅

[dargmuesli]

Wasn't sure if the syntax supports that case. Tried the following: https://paths.esm.dev/?p=AAMeJSyAwR4UbFDAFxAcAGAIJnP6oEV7Ap7NWgS8QAEAHQLUgFOnUYGTAIk.&t=/some/page/__og_image__#

Does that look right to you? Haven't played with vue-router much yet 🙌

Edit: and it must be configurable for nitro right? Which != vue-router I guess. But maybe the syntax works for both, not sure rn.

[harlan-zw]

Yes, nitro only, unfortunately. It uses radix3 https://github.com/unjs/radix3

[dargmuesli]

@KyleSmith0905 was quick: unjs/radix3#68

[KyleSmith0905]

If you'll want a temporary solution: I've added this to my routeRules:

      ...[0, 1, 2, 3, 4, 5].reduce<Record<string, Partial<NitroRouteConfig>>>((acc, cur) => {
			acc[Array(cur).fill('/*').join('') + '/__og_image__/og.png'] = {
				headers: {
					'Cross-Origin-Resource-Policy': 'cross-origin'
				}
			}
			return acc
		}, {})

This would give the following routes a certain header:
/__og_image__/og.png
/*/__og_image__/og.png
/*/*/__og_image__/og.png
/*/*/*/__og_image__/og.png
/*/*/*/*/__og_image__/og.png

So it should match any route that is 4 levels deep. (I hope)

[harlan-zw]

Will be fixed in the next update, see #114