feat: new middleware redirect_as2

[kwaa]

Description

This is an updated version of the same middleware in Aoba.

Check List

• Have you read the
  CODE OF CONDUCT
• Have you read the document
  CONTRIBUTING
  • One pull request per feature. If you want to do more than one thing,
    send multiple pull request.
  • Write tests.
  • Run deno fmt to fix the code format before commit.
  • Document any change in the CHANGELOG.md.

[kwaa]

@oscarotero For this middleware, what do you think about renaming it to redirect_as2 (redirectAS2) and providing the following options?

export type Options = (url: URL) => Promise<URL> | URL | undefined

export default (options: Options): Middleware => async (req, next) => {
  if (req.headers.get('accept')?.includes("application/activity+json")) {
    const dest = await options(req.url)
    if (dest) return Response.redirect(dest);
  }
  return await next(req);
};

// manual
server.use(redirectAS2(url => new URL(url.href, 'https://hatsu.local/posts/')))

// hatsu preset
export const hatsu = (instance: string) => (url: URL) => new URL(`${url.origin}${url.pathname}`, `https://${instance}/posts/`)

import Server from 'lume/core/server.ts'
import redirectAS2, { hatsu } from 'lume/middlewares/redirect_as2.ts'
const server = new Server()
server.use(redirectAS2(hatsu('hatsu.local')))

This would also be compatible with Bridgy Fed (not sure of the effect since I'm not currently using it):

// bridgy-fed preset
export const bridgyFed = () => (url: URL) => new URL(`${url.origin}${url.pathname}`, 'https://fed.brid.gy/r/')

import Server from 'lume/core/server.ts'
import redirectAS2, { bridgyFed } from 'lume/middlewares/redirect_as2.ts'
const server = new Server()
server.use(redirectAS2(bridgyFed()))

[oscarotero]

Yep, I like the idea!
BTW, what does as2 mean? 😄

For consistency with other middlewares, I'd use an options object as the first argument, instead a function.
Also, why don't simply pass the url, instead of a function? something like:

server.use(redirectAS2({
  dest: new URL("https://hatsu.local/posts/"),
}));

If the logic for calculate the final destination is different for hatsu and bridgy, maybe it can be configured in the mode option (name may change). For example:

server.use(redirectAS2({
  dest: new URL("https://hatsu.local/posts/"),
  mode: "hatsu"
}));

(or automatically detect it from the domain name).
What do you think?

[kwaa]

Yep, I like the idea! BTW, what does as2 mean? 😄

Activity Streams 2.0

Also, why don't simply pass the url, instead of a function?

Using functions allows users who need it to write custom logic, for example:

server.use(redirectAS2(url => {
  const { origin, pathname } = new URL(URL)
  if (pathname === '/') return new URL('https:/hatsu.local/users/example.com')
  else if (pathname.includes('/posts/') return new URL(`${origin}${pathname}`, 'https://hatsu.local/posts/')
}))

[oscarotero]

Using functions allows users who need it to write custom logic

Yes, I know. My only concern is about the value provided by this middleware. Internally, it only has an if to check if the request is an activity stream request. That's why I was thinking of something more straightforward.
Maybe something like? url: URL | (url: URL) => URL (allowing to provide a url or a function returning an url).

[kwaa]

Maybe something like? url: URL | (url: URL) => URL (allowing to provide a url or a function returning an URL).

If the URL is provided directly, options like instance and mode must also be included. I think this might be more cumbersome than using functions.

[oscarotero]

Okay, let's start with the function and we can see later if an url option makes sense.

[kwaa]

Okay, let's start with the function and we can see later if an url option makes sense.

I have updated PR.

[oscarotero]

Great.
Thanks for your patience in the back and forth 🙌