* 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>
* Add link to GitHub release/tag/commit in footer
* Only show tag if there is one
Co-authored-by: syeopite <70992037+syeopite@users.noreply.github.com>
---------
Co-authored-by: syeopite <70992037+syeopite@users.noreply.github.com>
* 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.
* 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>
* Prevent player microformat from being overwritten by the next microformat
Closes https://github.com/iv-org/invidious/issues/5443
The player microformat is what we need to get the published date,
premiere timestamp, allowed regions and more information of the video.
Youtube introduced a new `microformat.microformatDataRenderer` in the
next endpoint which overwrote the player microformat
`microformat.playerMicroformatRenderer` when merged
* Update src/invidious/videos/parser.cr
Co-authored-by: syeopite <70992037+syeopite@users.noreply.github.com>
---------
Co-authored-by: syeopite <70992037+syeopite@users.noreply.github.com>
This changes its behavior to align with the stdlib variant in that
compression is now delayed till the moment that the server begins to
send a response.
This allows the handler to avoid compressing empty responses,and
safeguards against any double compression of content that may occur
if another handler decides to compressi ts response.
This does however come at the drawback(?) of it now removing
`content-length` headers on requests if it exists; since compression
makes the value inaccurate anyway.
See: https://github.com/crystal-lang/crystal/pull/9625
The exception handling for database connections results in an
`ex` variable which Ameba sees as overshadowing the `ex` used by the
`ex` block arg used to define the HTTP status code 500 handler below.
Although this is a non-issue since the db connection exception handling
will cause Invidious to exit, Ameba's nature as a static checker means
that it isn't aware of this.
The simplest fix without a dirty ameba ignore comment is to rename `ex`
within the Kemal handler block below, since `ex` within a begin rescue
block is a Crystal convention that will also cause Ameba to raise when
not adhered to.
