Re: Handling HTTP errors resulting from key requests

What other errors are you thinking of? How is this different from such
errors on any other XHR?

>From the spec, "A Key Session... represents the lifetime of the key(s) it
contains and *associates all messages* related to them." If there are
alternate servers that have knowledge of the session, then you could
continue using the same session. This seems unlikely, though, in such
failure scenarios. In the specific case you mentioned, the first message
failed, so there is probably no existing state but it depends on the error
and where it occurred in the server. (If you get a 404, it's safe to try
another server, but it might not be safe to re-send after a 500.)

The safest thing to do in this hopefully rare case would be to close the
session and start over, especially if it's the first message.

The CDM almost certainly won't have alternative requests URLs, and if it
could, the application should have them as well. The CDM obtains
destinationURL in two ways:

   - From the initData's default URL, where I believe generally only one is
   supported.
   - From server responses provided to update().
      - These are more likely to be URLs for a heartbeat server or
      something like that.
      - I think the main use case for this would be to send different
      messages to different servers.
      - If backup URLs were needed, the application could have mappings
      from primary to backup.


The alternative would be to call update() with a message indicating the
request failed, but we don't want to concern the CDM with such issues or
use it as a repository of information like URLs.

David

On Thu, Dec 5, 2013 at 12:48 PM, Joe Steele <steele@adobe.com> wrote:

> I am running into this case while debugging and it is not clear from the
> spec how to handle this.
>
> Here is the use case I am thinking about —
> * Application starts playback of encrypted stream
> * UA sends needKey to app - app responds by creating a session
> * CDM sends key request to app
> * App forwards key request to server via XMLHttpRequest
> * Server responds with something other than HTTP/200
> * *App does what exactly?*
>
> At this point we are in a grey area — if the error is something related to
> auth, the handling is probably straight-forward and the EME philosophy
> indicates the app should handle it. But if the error is anything else, the
> only option I see is closing the session and opening a new one.  Does this
> sound correct to everyone?
>
> I am concerned that the CDM is *only* notified in the success case. The
> CDM might be able to offer an alternative request URL when errors are
> encountered, however there is no mechanism for this currently.
>
> Joe
>