Workaround fix to handle 416

Environment Used:

• Media3: 1.1.1 / ExoPlayer: 2.19.1

Questions:

• The HttpDataSources handle 416 response code in this manner.
  • Does ExoPlayer expect clients to request for byte ranges out of bound implicitly?
  • If so, why does ExoPlayer expect that in first place?
    • It is reasonable to depend on header fields as based on HTTP semantics for 416, it SHOULD not MUST return ContentRange in header, however some endpoints do not respect the semantics.
  • It feels like depending on header fields for 416 is not an ideal way to handle and we are not fixing the root cause as to why even we encounter this state in the first place. Any insights on this would be greatly appreciated.

Background:

• Our app is getting 416 from CloudFront and CloudFront is not returning ContentRange in header.
  • Due to this, ExoPlayer code to handle 416 is not working and the end user is stuck in 416 state
  • Note: We are working with CloudFront to respect HTTP 416 semantics but would like to understand why ExoPlayer handles 416 the way it is currently
• We had created an issue (https://github.com/androidx/media/issues/1032) earlier:
  • Details about our original bug: When the 416 issue happens, we are seeing Request/Headers/Range=bytes=108421975-
    which doesn't contain length, and the position here 108421975 is one byte extra than it's actual total length. We had multiple records with 416 and they all have this same pattern.
  • TL;DR: Based on this comment, it was decided that it was a caching problem and server is misbehaving.
  • We agree with server misbehaving but don't understand what could lead to caching problem since we use CacheWriter and DefaultHttpDataSource provided by ExoPlayer
  • It could be our internal caching wrapper over SimpleCache problem but I see other clients also face a similar caching issue
    • https://github.com/google/ExoPlayer/issues/7326#issuecomment-783432655: This comment is very similar to our issue in terms of caching the last byte
    • Simple Cache Corruption issue is unrelated but found this commit that again deals with tightening caching to correctly handle cases where the request DataSpec extends beyond the end of the underlying resource.
    • https://github.com/google/ExoPlayer/issues/8474: This issue is very similar to our use case where the request that leads to 416 has startingByte as one byte extra than contentLength
      • Most importantly, this client was also not able to reproduce in-house and the timeout that they increased, we already use that timeout value 8s and still not able to repro 416.

Important Points to note:

• Based on multiple issues above, we believe there could (/might) be some caching problem in ExoPlayer and the workaround to handle 416 on ExoPlayer is hiding the actual root cause

Any help on this would be greatly appreciated since our bug is the top download error and users have a really bad experience of being stuck in 416 state