Configuring Bring-Your-Own (BYO) CDN for Live 2.0 Playback

Prerequisites

• Shared BCOV token from Brightcove Support.
• Assigned hostname value that pairs with the token.
• Ability to configure your CDN/reverse proxy origin, request headers, and cache behavior.
• HTTPS/TLS enabled for origin fetches.

Quick start

1. Set the BYO origin to https://playback.live.brightcove.com.
2. Append an auth header on origin requests: BCOV-CDN-Auth: <token-shared-by-support>. Do not require clients to send this header and do not expose it downstream.
3. Set the forwarded host header on origin requests: X-Forwarded-Host: <hostname-assigned-to-token>. The value must exactly match the hostname provided by Support.
4. Respect origin caching: Honor Cache-Control, Expires, ETag, Last-Modified, and any relevant Vary directives. Do not override with more/less aggressive policies.
5. Deploy and validate using the checks below.

Validation & troubleshooting

Quick checks

• Confirm in CDN logs or origin debug tools that requests to Brightcove include both headers with expected values.
• Request a known live playback URL through your BYO edge and verify successful playback and expected cache behavior (e.g., presence of Cache-Control, ETag).
• Verify that private headers (BCOV-CDN-Auth, X-Forwarded-Host) are not exposed to clients.

Failure-path checks

• Missing token → Expect 401/403
• Bad token → Expect 401/403
• Wrong or mismatched X-Forwarded-Host → Expect 403

Cache behavior

• Verify Cache-Control headers from the origin are preserved.
• If ETag is present, confirm conditional requests return 304 Not Modified.
• Repeat requests should show increasing Age when served from cache.

Common pitfalls

• Adding headers to client responses instead of origin requests
• Enforcing a fixed CDN TTL that conflicts with origin Cache-Control
• Typos or case differences in X-Forwarded-Host vs. the Support-assigned hostname
• Leaking BCOV-CDN-Auth downstream to clients
• Overriding the Host header for origin fetches (unless instructed by Support)