fix: accept HEAD requests on the playback endpoint - #631
Conversation
FastAPI's APIRoute does not add HEAD to a route's methods the way Starlette's Route does, so the playback endpoint answered 405 Method Not Allowed to any HEAD probe. Some clients (reported on Stremio for Android TV / ExoPlayer) probe a stream URL with HEAD before opening it. Register the route with api_route(methods=["GET", "HEAD"]). No handler changes are needed: request.method is already forwarded to custom_handle_stream_request, mediaflow_proxy's handle_stream_request has an explicit HEAD branch that closes the streamer and returns headers only, and combined_background_tasks already tolerates the resulting None close task. Starlette's FileResponse and RedirectResponse both handle HEAD by sending headers without a body. Verified against v2.58.0: HEAD now returns 200 with a zero-byte body and the same content-type GET serves.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
WalkthroughThe playback endpoint now accepts both ChangesPlayback route
Mergeability Score: ⚪ Minimal · up to This localized change enables HEAD requests on the playback endpoint without changing GET behavior or handler logic, and no actionable merge-blocking risk remains after normal checks and review. 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
Note - the user who reported this issue claimed that it was "fixed", but in retrospect, the updated container hadn't rolled out to them yet, so IDK whether this was the root cause of their exoplayer problem or not 🤷🏻 |
|
+1 — independently confirmed in production. We’ve been running this exact approach since 2026-06-24 (HEAD handler delegating to the playback logic, body-stripped response preserving the 302 Location) on a custom image. Without it, Stremio’s HEAD probe gets 405 and playback fails with “Loading Failed”. Just re-applied it on top of v2.58.0 — HEAD returns 302, playback works. Would be great to get this merged so the custom build can be dropped. |
2 participants
Problem
/{b64config}/playback/...is registered with@router.get(...), so it answers 405 Method Not Allowed toHEAD.This is easy to miss because Starlette's
Routeauto-addsHEADwheneverGETis present, but FastAPI'sAPIRoutedoes not — it takesmethodsverbatim. So a plain@router.getroute is GET-only.Reported by a user on Stremio for Android TV (ExoPlayer), which probes the stream URL with
HEADbefore opening it. Desktop players don't, which is why this only shows up on some clients.Fix
Register the route with
api_route(..., methods=["GET", "HEAD"]). One line plus the decorator swap; no handler changes.The handler was already HEAD-ready:
request.methodis already forwarded tocustom_handle_stream_requestmediaflow_proxy.handlers.handle_stream_requesthas an explicitHEADbranch that closes the streamer and returns headers without a bodycombined_background_tasksalready tolerates theNoneclose-task that the HEAD branch produces, so theactive_connectionsrow is still releasedFileResponse(status videos) andRedirectResponseboth handle HEAD by sending headers onlyVerification
Against
v2.58.0, on the playback route:HEADcontent-type: video/mp4GETNote (not in this PR)
/{b64config}/debrid-sync/{service_index}is also handed to players as a stream URL and is likewise GET-only, so it 405s on HEAD too. I left it out because it is a side-effecting trigger — making it accept HEAD would mean a probe fires an account sync. Happy to follow up if you'd like it handled.Summary by CodeRabbit
GETandHEADmethods.