Wrong handling of .well-known

[SoniEx2]

💡 Summary

Misskey handles .well-known wrong. Despite having code to send 204, it never actually does so.

🥰 Expected Behavior

Misskey should return [404? 204?] for .well-known's it doesn't handle.

🤬 Actual Behavior

Misskey sends 200 for .well-known's it doesn't handle.

📝 Steps to Reproduce

Visit any .well-known like .well-known/doesntexist or the proposed .well-known/resource-that-should-not-exist-whose-status-code-should-not-be-200

📌 Environment

...

💻 Frontend

• Model and OS of the device(s):
• Browser:
• Server URL:
• Misskey:
  13.x.x

🛰 Backend (for server admin)

• Installation Method or Hosting Service:
• Misskey: 13.x.x
• Node: 18.x.x
• PostgreSQL: 15.x.x
• Redis: 7.x.x
• OS and Architecture:

[SoniEx2]

you should try to get this bug patched and the patch widely deployed before august, or you might get some very confused users.

[tamaina]

before august

Why?

[SoniEx2]

1. fedicraft
2. blanketcon

fedicraft's "does this support fedicraft" check is to probe status codes. since it's returning 200 when it shouldn't, fedicraft thinks misskey supports fedicraft.

which is a misskey bug.

[saschanaz]

I'm not convinced by that August thing but anyway this is a bug. Generally I'd be happier if Misskey binds to some valid list of foo/* rather than just *.

misskey/packages/backend/src/server/web/ClientServerService.ts

Lines 673 to 676 in f5dfb64

	// Render base html for all requests
	fastify.get('*', async (request, reply) => {
	return await renderBase(reply);
	});