Crystal 1.16.0 fixed the parsing of some weird-looking paths meaning
that `//api/v1/storyboards/sb/i/...` will no longer get parsed into a
request target of `/v1/storyboards/sb/i/...` within requests.
But the fix is a bit more convoluted than just changing a path. The new
presence of double slash means that `StaticFileHandler` will process and
redirect the request to a normalized path with only a single slash.
This redirect however does not preserve url query parameters which are
needed to request storyboards from YouTube.
Then there's the fact that the status code error handlers are disabled
for the API routes, meaning that there is no handler to actually process
the request with.
This PR patches Kemal's `StaticFileHandler` to preserve query parameters
when redirecting, and adds the `/api/v1/storyboard/sb/*` ->
`/sb/i/*/` redirect directly into Kemal's `ExceptionHandler` for now.
In the future a dedicated handler should be created to properly handle
http status code conditions on the API routes.
textcaptcha.com seems to be down since April and it does not appear that
service will be restored.
Text captchas can be easily automated using free LLMs, so keeping the
text captcha is more like a gate to create accounts in mass on public
Invidious instances.
It also gives headaches like bots automating account creation to modify
the videos that appear popular page of each instance (since the popular
page is based on the subscriptions of the registered users).
Fixes https://github.com/iv-org/invidious/issues/5295
textcaptcha.com seems to be down since April and it does not appear that service will be restored.
Text captchas can be easily automated using free LLMs, so keeping the text captcha is more like a gate to create accounts in mass on public Invidious instances.
It also gives headaches like bots automating account creation to modify the videos that appear popular page of each instance (since the popular page is based on the subscriptions of the registered users).
Currently, Invidious uses QEMU to build it's ARM64 Invidious image,
which is slow (since we are basically using a virtual machine).
This helps with the speed of building ARM64 binaries for Invidious
on each release/commit.
More information about the public ARM64 runners here:
https://github.com/orgs/community/discussions/148648
CI: Use ARM64 compose file for build-docker-arm64