Build and release container directly from master / release (docker/Dockerfile.arm64, ARM64, ubuntu-24.04-arm, linux/arm64/v8, -arm64) (push) Has been cancelled
* Allow downloading via companion
* post request where not proxied for the download companion which made
it impossible to download with the companion enabled
* Re-apply Channel to Channels rename which was pulled in
* Update src/invidious/routes/companion.cr
* doc: better comments for each route
---------
Co-authored-by: Fijxu <fijxu@nadeko.net>
Co-authored-by: Émilien (perso) <4016501+unixfox@users.noreply.github.com>
* Replace deprecated `blocking` property of `Socket`
This replaces the deprecated argument `blocking` and uses
`Socket.set_blocking(fd, value)` instead.
Fixes a warning in the compiler
https://github.com/crystal-lang/crystal/pull/16033
* Upgrade to upstream
* chore: only Socket.set_blocking for > 1.18
---------
Co-authored-by: Emilien <4016501+unixfox@users.noreply.github.com>
Summing the sizes of each cached file every time is very inefficient.
Instead we can simply store the cache size in an constant and increase
it everytime a file is added into the cache.
Running `crystal spec` without a file argument essentially produces one
big program that combines every single spec file, their imports, and
the files that those imports themselves depend on. Most of the types
within this combined program will get ignored by the compiler due to a
lack of any calls to them from the spec files.
But for some types, partially the HTTP module ones, using them within
the spec files will suddenly make the compiler enable a bunch of
previously ignored code. And those code will suddenly require the
presence of additional types, constants, etc. This not only make it
annoying for getting the specs working but also makes it difficult to
isolate behaviors for testing.
The `static_assets_handler_spec.cr` causes this issue and so will be
marked as an isolated spec for now. In the future all of the tests
should be organized into independent groupings similar to how the
Crystal compiler splits their tests into std, compiler, primitives and
interpreter.
Overriding `#call` or patching out `serve_file_compressed` provides
only minimal benefits over the ease of maintenance granted by only
overriding what we need to for the caching behavior.
Kemal's subclass of the stdlib `HTTP::StaticFileHandler` is not as
maintained as its parent, and so misses out on many enhancements and bug
fixes from upstream, which unfortunately also includes the patches for
security vulnerabilities...
Though this isn't necessarily Kemal's fault since the bulk of the stdlib
handler's logic was done in a single big method, making any changes hard
to maintain. This was fixed in Crystal 1.17.0 where the handler
was refactored into many private methods, making it easier for an
inheriting type to implement custom behaviors while still leveraging
much of the pre-existing code.
Since we don't actually use any of the Kemal specific features added by
`Kemal::StaticFileHandler`, there really isn't a reason to not just
create a new handler based upon the stdlib implementation instead which
will address the problems mentioned above.
This PR implements a new handler which inherits from the stdlib variant
and overrides the helper methods added in Crystal 1.17.0 to add the
caching behavior with minimal code changes. Since this new handler
depends on the code in Crystal 1.17.0, it will only be applied on
versions greater than or equal to 1.17.0. On older versions we'll
fallback to the current monkey patched `Kemal::StaticFileHandler`
* dockerfile: compile openssl instead of using the one bundled on the crystal alpine image.
* fix formatting
* CI: add --no-cache to openssl-builder
* CI: add Dockerfile.arm64 version
* add comment why we compile openssl ourselves
* fix wrong position of comment
* oopsie
* verify openssl checksums
* set nproc for openssl make
* use ARG for openssl sha256 checksum
* feat: Add configurable max_request_line_size to handle long URLs
This commit adds a new configuration option `max_request_line_size` that allows
users to increase the HTTP request line size limit. This is particularly useful
for handling very long continuation tokens that can cause 414 (URI Too Long) errors.
Changes:
- Add `max_request_line_size` property to Config class
- Configure Kemal server to use the custom limit if specified
- Document the option in config.example.yml with recommendations
- Add examples in docker-compose.yml for both YAML and env var configuration
The default behavior remains unchanged (8KB limit) unless explicitly configured.
This provides a solution for users experiencing 414 errors without affecting
existing installations.
* Hardcode max_request_line_size to 16384
---------
Co-authored-by: Sunghyun Kim <hello@sunghyun.me>
Build and release container directly from master / release (docker/Dockerfile.arm64, ARM64, ubuntu-24.04-arm, linux/arm64/v8, -arm64) (push) Has been cancelled
Build and release container directly from master / release (docker/Dockerfile.arm64, ARM64, ubuntu-24.04-arm, linux/arm64/v8, -arm64) (push) Has been cancelled
This PR contains the following updates:
| Package | Type | Update | Change |
|---|---|---|---|
| alpine | final | minor | `3.22` -> `3.23` |
| alpine | stage | minor | `3.22` -> `3.23` |
---
### Configuration
📅 **Schedule**: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).
🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied.
♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 **Ignore**: Close this PR and you won't be reminded about these updates again.
---
- [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check this box
---
This PR has been generated by [Renovate Bot](https://github.com/renovatebot/renovate).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiI0Mi40Mi4wIiwidXBkYXRlZEluVmVyIjoiNDIuNDIuMCIsInRhcmdldEJyYW5jaCI6Im1hc3RlciIsImxhYmVscyI6W119-->
Reviewed-on: https://git.nadeko.net/Fijxu/invidious/pulls/326
Co-authored-by: Renovate Bot <git@nadeko.net>
Co-committed-by: Renovate Bot <git@nadeko.net>
Build and release container directly from master / release (docker/Dockerfile.arm64, ARM64, ubuntu-24.04-arm, linux/arm64/v8, -arm64) (push) Has been cancelled
* fix: restore dmca_content functionality
This restores (or adds) the functionality of the `dmca_content` config
option that at this date, has been unused and makes no effect.
* only disable download widget for dmca video ids
* Remove signature helper completely from Invidious
The official way to reproduce video with Invidious now is by using
Invidious Companion which uses Youtube.JS with a Javascript Interpreter
that can successfully decrypt youtube video URLs.
Sig helper has not been used for a long time, is beyond broken and no
one has plans to fix it and maintain it.
* Remove DECRYPT_FUNCTION and shrink player function
* remove `sp = cfr[sp]`
* Improve message
Posts with a video that has been removed returned
`ProblematicTimelineItem` type which was not taken in account for
community posts.
Now community posts with a broken video will not display an embedded
video.
Build and release container directly from master / release (docker/Dockerfile.arm64, ARM64, ubuntu-24.04-arm, linux/arm64/v8, -arm64) (push) Has been cancelled
Build and release container directly from master / release (docker/Dockerfile.arm64, ARM64, ubuntu-24.04-arm, linux/arm64/v8, -arm64) (push) Has been cancelled
* Fix 0 view count on related videos
* Remove view_count variable since it's unused by Innertube
* Remove view_count from specs and API
---------
Co-authored-by: Fijxu <fijxu@nadeko.net>
Video information from youtube always weight about ~60KB uncompressed.
When using Deflate to compress that information, it gets compressed down
to ~15KB, so now you will be able to store up to 4x entries more with
caching enabled.
For context, nadeko.net Invidious instance stores 54.7k keys, since we
also store the `time` in a different key associated to the video ID, the
real count of videos cached would be 27.3k. With compression enabled,
the Redis database will be able to store up to 4 times more videos in
cache, which is 109.2k videos cached.
Pretty cool huh.
Build and release container directly from master / release (docker/Dockerfile.arm64, ARM64, ubuntu-24.04-arm, linux/arm64/v8, -arm64) (push) Has been cancelled
