Onebox failed for videos >5MB: Servers returning 200 OK instead of 206 Partial Content

AI-generated summary

copymonopoly reports that Onebox previews for videos over 5MB fail on their Discourse instance, despite working on others. The issue stems from the server receiving a 200 OK instead of a 206 Partial Content response when fetching the video, causing the download to exceed the 5MB limit. Manual tests with Net::HTTP show a successful 206 response, but Discourse’s FinalDestination fails to negotiate the Range header, resulting in a full download. Despite trying various configurations—like setting onebox_user_agent, adding the domain to force_custom_user_agent_hosts, and verifying no proxy is in use—the problem persists. The user is seeking insight into why their instance behaves differently from others, suspecting possible internal configuration, security middleware, or FinalDestination logic interfering with Range requests.

Hi everyone,

I’m running into a specific issue where videos larger than 5MB fail to generate Onebox previews on my Discourse instance (standard Docker install), whereas the same video links work perfectly on other Discourse sites.

The Problem:
When I post a video link (e.g., a 5.1MB .webm file), the Onebox fails. I’ve isolated the issue to a failure in Range request negotiation.

Debugging results from the Rails console:

  • Manual Ruby Test (Success): Using standard Net::HTTP and manually setting the Range: bytes=0-10 header, I successfully get a 206 Partial Content from the source server.
  • Discourse System Test (Failure): When Discourse attempts to fetch the same URL via FinalDestination.new(url).get, it receives a 200 OK (Net::HTTPOK) instead of a 206. Consequently, it attempts to download the entire file, hits the 5MB MAX_REQUEST_SIZE_BYTES limit, and the Onebox fails with a “size too big” error.

I have already tested the following configurations, but the issue persists:

  1. Set a browser-like string in onebox_user_agent.
  2. Added the source domain to force_custom_user_agent_hosts.
  3. Verified the server has no global proxy configured (env | grep -i proxy is empty).
  4. Tested the same URL on other Discourse instances, where it Oneboxes perfectly.

The Question:
Why would one Discourse instance fail to negotiate a Range request (206) while another instance, pointing to the exact same URL, succeeds on the same network?

Is there any specific internal configuration, security middleware, or FinalDestination logic that might be stripping the Range headers or causing the remote server to fallback to a full 200 response?

Any insights or pointers on where to look next would be greatly appreciated!