a9da585f45
Root cause found live: eporner's CDN mp4 URLs enforce a Referer check
independent of the hash/xhr resolution — a request with no Referer or
one pointing at eporner.com gets the real file, but any other Referer
gets a 302 to a static .../na.mp4 ("not available") decoy. Since our
VideoFormat entries declared no http_headers at all, playback fell
through to whatever default Referer the client happened to send,
occasionally tripping this check and showing the short "this video is
only available at eporner.com" clip.
Verified against a live video: fetching a resolved format URL with an
unrelated Referer reproduces the exact na.mp4 redirect; with the
correct Referer it serves the full file. Each format now explicitly
declares Referer: https://www.eporner.com/ so client-side defaults
can't trip the check.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QTqf6orbHZ9rFFpVpcgzcR
Hottub Docs
This folder is the fastest handoff path for anyone adding or repairing a channel.
Start here:
- Read
architecture.mdfor the server flow, request lifecycle, and core types. - Read
provider-playbook.md— its top "Best Practices (Living)" section is the cross-cutting rule set to internalize first, then follow the rest of the playbook for the exact process to add a new provider or proxy. - Use
provider-catalog.mdto find the closest existing implementation to copy. - Use
docs/hottubapp/*.htmlwhen you need the client-facing API contract for status, videos, or uploaders. - Only then touch
prompts/new-channel.md; it assumes the docs above exist.
Recommended local workflow:
cargo check -q
HOT_TUB_PROVIDER=<channel_id> cargo check -q
HOT_TUB_PROVIDER=<channel_id> cargo run --features debug
Useful runtime baseline:
DATABASE_URL=hottub.db
RUST_LOG=info
PROXY=0
BURP_URL=http://127.0.0.1:8081
FLARE_URL=http://127.0.0.1:8191/v1
DOMAIN=127.0.0.1:18080
DISCORD_WEBHOOK=
Key facts:
- Hottub is a Rust
ntexserver with providers undersrc/providers/. build.rscontrols compile-time provider registration./api/videosis the main provider execution path./proxy/...exists for sites whose direct media or thumbnails need a redirect/proxy layer.- Only three providers currently implement
/api/uploaders:hsex,omgxxx, andvjav. - Uploader IDs should be namespaced like
<channel>:<site-local-id>so/api/uploaderscan route directly.