Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Question: Can Shaka player ignore the retry parameters on 401/403 status codes. #620

Closed
londonshliach opened this issue Dec 4, 2016 · 5 comments
Assignees
Labels
status: archived Archived and locked; will not be updated type: enhancement New feature or request
Milestone

Comments

@londonshliach
Copy link

Is there a way for me to tell Shaka player to ignore the retry parameters, and throw and Error, if it receives a 401 / 403 status code?

I host my videos on Amazon CloudFront and the files are private. My manifest URL is an API endpoint that generates temporary signed URLs for all the video segments.

The signed URLs expire after an hour and once that happens I will have to reload the manifest and get new signed URLs.

Some of my users will not have very good internet connections so I want to set the retry parameters so that Shaka player will retry a few times if there is a problem with the internet connection.
However, I don't want Shaka player to retry the download if it receives a response with a 401 / 403 status code (as retrying those requests will certainly fail). In that case, I want Shaka player to reload the manifest and get new URLs for the video segments.

So is there a way to tell Shaka player to retry the download if there is a network problem, but to restart (or just throw an error,) if it receives a 401 / 403 response?
Is there a way for me to pass a function to Shaka player that will get the response and decide whether to retry or not?

Thanks for the help.

@joeyparrish joeyparrish added the type: enhancement New feature or request label Dec 6, 2016
@joeyparrish joeyparrish added this to the v2.1.0 milestone Dec 6, 2016
@joeyparrish
Copy link
Member

That's a great question. I'm sure we could come up with a way to skip retries. I'll have to think about the design a little.

@TheModMaker TheModMaker self-assigned this Jan 3, 2017
shaka-bot pushed a commit that referenced this issue Apr 5, 2017
Issue #620

Change-Id: I6b659acdccf5d893022f3474b45020482f543550
@TheModMaker
Copy link
Contributor

The new design is for networking scheme plugins to return a RECOVERABLE severity when it should retry and CRITICAL severity when it shouldn't. So you can either write your own HTTP plugin or modify the existing one to do this.

Another option would be to write a shim between the HttpPlugin and the NetworkingEngine. You would do this by registering your own http(s) plugin that forwards to the HttpPlugin for the request and filters errors. When you get a BAD_HTTP_STATUS error, you can look at error.data[1] for the status and change the error severity to CRITICAL.

For example:

function MyHttpPlugin(uri, request, requestType) {
  return shaka.net.HttpPlugin(uri, request, requestType).catch(function(error) {
    if (error.code == shaka.util.Error.Code.BAD_HTTP_STATUS &&
        (error.data[1] == 401 || error.data[1] == 403)) {
      // NetworkingEngine should not retry the request.
      error.severity = shaka.util.Error.Severity.CRITICAL;
    }
    throw error;
  });
}

shaka.net.NetworkingEngine.registerScheme('http', MyHttpPlugin);
shaka.net.NetworkingEngine.registerScheme('https', MyHttpPlugin);

@joeyparrish
Copy link
Member

@TheModMaker, I recommend we do this directly in the standard HTTP plugin. It would not make sense to retry on a 401 or 403, so we should return CRITICAL for that.

@TheModMaker
Copy link
Contributor

@londonshliach So now we will not retry for 401/403.

If you want a more general filtering logic, you can still do what I described above.

@londonshliach
Copy link
Author

Great.
Thank you very much.

@shaka-project shaka-project locked and limited conversation to collaborators Mar 22, 2018
@shaka-bot shaka-bot added the status: archived Archived and locked; will not be updated label Apr 15, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
status: archived Archived and locked; will not be updated type: enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

4 participants