Treat HTTP 202 as a failure and retry

[priyajeet]

if (target.status >= 200 && target.status <= 299) {
        // All 2xx HTTP codes are success cases.
        ...
}

https://github.com/google/shaka-player/blob/18da8e04dc629ef059ec157587c21d21ce122103/lib/net/http_plugin.js#L47

Currently the player assumes that everything 2xx is a success. However 202 is generally used when the server hasn't finished processing and wants the client to try again later. From the documentation:

The request has been accepted for processing, but the processing has not been completed.

Should that if condition above be changed to filter 202? Or some new configuration parameter added such that clients can choose what constitutes a success.

[joeyparrish]

Good question. I've never seen a 202 in the wild.

What should the behavior be? Fail and retry?

Can you give an example of when a 202 response might occur in a streaming media scenario?

[priyajeet]

Our rest endpoint for serving a dash segment (or any content type for that matter) returns a 202 to tell the client that the requested representation is still being processed. Search for 202 here https://docs.box.com/reference#download-a-file

In our use case (Box), a user uploads their media file and then clicks the file right after upload. At this point some segments may have been converted, while others are still being processed. We start the video stream as soon as the MPD file is ready + moov atom segments are ready (1st two segments typically). At this point, making a request to a non-converted future segment will return a 202. Ideally this should be considered not a success (similar to 404) and the client should just retry with some backOffFactor.

I am not sure if there are other people with similar examples. Currently we modified the shaka player (v1) locally to add special case for 202. So just wondering if something can be implemented at the shaka player level to prevent a local modification on our end. Thanks.

http://stackoverflow.com/questions/9794696/how-do-i-choose-a-http-status-code-in-rest-api-for-not-ready-yet-try-again-lat

[joeyparrish]

Yes, that sounds reasonable. I'll add an exception for HTTP 202.

[joeyparrish]

The fix for this has just been released in v2.0.3.