Re: Handling HTTP errors resulting from key requests

On Dec 5, 2013, at 3:01 PM, David Dorwin <ddorwin@google.com> wrote:

> What other errors are you thinking of?

The cases where the application can re-send safely seem to be limited to: 3xx, 401, 402, 407 
I.e. the authentication related ones going back to the same server with new tokens

> How is this different from such errors on any other XHR?

These messages are likely to be encrypted and therefore the message may not be readable by any server other than the one the CDM indicated. 

> 
> 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.

This would be safe, but might not be optimal. I guess I was hoping for a way to avoid tearing down the key session when we don’t have to.

> 
> 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 initData can contain lots of things. It has keySystem specific information in it. This could easily include a list of URLs. Or the CDM itself could have a list of URLs baked in. Or a previous key response could have contained a list of alternate URLs to use in case the server the response came from goes down. In any event, the CDM is providing the defaultURL that the message is sent to and there are no constraints on what that URL is. Same-origin should prevent cross-origin leakage. 

> 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.

That would work for me. :-)

However I think a fix involving less work would be an informative note in the spec saying that only the HTTP errors listed above (3xx, 401, 402, 407) can be automatically re-sent by the application. All others should result in the session being closed.

> 
> 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
>