The standard Crystal `HTTP::Client` creates a new SSL context for every
client/reconnection. This is not ideal because creating a new SSL
context is an incredibly slow operation.
The standard practice instead is to cache or use a single SSL CTX
throughout the lifetime of the application. The OpenSSL context has been
designed with this in mind, and even explicitly recommends it. It even
works concurrently across many threads.
Reusing a single SSL context significantly speeds up the process of
starting and restarting clients. Which is incredibly important in the
case of the Invidious connection pool where new clients are often spun
up.
The only caveat is that a cached SSL context may become out of sync with
the system ca store. But for an Invidious instance following the best
practices of frequent restarts this is an non-issue.
See https://github.com/crystal-lang/crystal/issues/15419
Implement force resolve via IO constructor
Use `DB::Pool#retry` in connection pool
`HTTP::Clients` created through its IO constructor cannot reconnect to
closed connections, and instead will result in an error on usage.
The `DB::Pool#retry` allows us to cycle until we find a client that
that still has an open connection, or to create a new one
if necessary. The poisoned clients are then removed once identified
by `#retry`'s internal logic
The fact that clients with closed connections will now be slowly removed
also means that Invidious will no longer use the same pattern of companion
connections within the pool; distributing routes more evenly.
Clients created when idle_capacity is reached but not max_capacity
are discarded as soon as the client is checked back into the pool,
not when the connection is closed.
This means that allowing idle_capacity to be lower than max_capacity
essentially just makes the remaining clients a checkout timeout
deterrent that gets thrown away as soon as it is used. Not useful
for reusing connections whatsoever during peak load times
Defaulting to the streaming api of `HTTP::Client` causes some issues
since the streaming respone content needs to be accessed
through #body_io rather than #body
The streaming API of HTTP::Client has an internal buffer
that will continue to persist onto the next request unless
the response is fully read.
This commit privatizes the #client method of Pool and instead
expose various HTTP request methods that will call and yield
the underlying request and response.
This way, we can ensure that the resposne is fully read before
the client is passed back into the pool for another request.
- Remove duplication between standard and companion pool
- Raises a wrapped exception on any DB:Error
- Don't use a non-pool client when client fails
- Ensure that client is always released
- Add documentation to various pool methods
* add support for invidious companion
* redirect latest_version and dash manifest to invidious companion
* fix Shadowing outer local variable `response`
* fixing condition for Content-Security-Policy
* throw error if inv_sig_helper and invidious_companion used same time
* Use sample instead of Random.rand
Co-authored-by: syeopite <70992037+syeopite@users.noreply.github.com>
* Remove debug puts functions
Co-authored-by: syeopite <70992037+syeopite@users.noreply.github.com>
* modify the description for config.example.yaml about invidious companion
* move config checks for invidious companion
* separate invidious_companion logic + better config.yaml config
* fixing "end" misplacement
* fix linting + use .empty?
* crystal handle decompression already by itself
* fix download function when invidious companion used
* fix linting
* invidious companion always used so always add CSP and redirect latest_version
* apply all the suggestions + rework invidious_companion parameter
* format watch.cr
* fix ameba Redundant use of `Object#to_s` in interpolation
* add ability for invidious companion to check request from invidious
* Better document private_url and public_url
* Better doc for invidious_companion_key
* !empty? to present?
* skip proxy for invidious companion
* fixing format
* missing ,
* add companion pooling http
* fix: don't use http proxy when sending requests to companion
* fix: logic where we want to have the invidious logic if companion is not used
* chore: remove baseurl usage from invidious companion
* chore: change from inv-sig-helper to companion for required playback
* fix: use puts + add warning for inv-sig-helper deprecated
---------
Co-authored-by: syeopite <70992037+syeopite@users.noreply.github.com>
Invidious does not currently support non-livestream hls playback
Originally, the HLS manifest check was essentially a boolean:
if the HLS manifest field was present, it was assumed to be a
livestream. Some videos include the HLS Manifest but aren't
livestreams.
In the case where they are livestreams, the video contains a videoType
field with the value "Livestream". In the case that they're normal
videos, the videoType is "Video". This is exposed via the
`video.live_now` property.
This commit just checks that `video.live_now` is true before treating
it as a livestream
The automatic instance redirection has the potential to pick
the same instance the user is currently on. This is especially
prevalent when the instance list is limited in number like how it is
today.
This PR checks the domain of the instance and ensures that it is not
the same as the current instane before redirecting the user to it.
Otherwise, it just sends the user to rediret.invidious.io
Originally, the HLS manifest check was essentially a boolean: if the HLS
manifest field was present, it was assumed to be a livestream. Some
videos include the HLS Manifest but aren't livestreams.
In the case where they are livestreams, the video contains a videoType
field with the value "Livestream". In the case that they're normal
videos, the videoType is "Video". This is exposed via the video.live_now
method.
This commit just checks that video.live_now is true before treating it
as a livestream
