24016 2013-12-06 01:32:24 +0000 Multiple outstanding key requests allowed 2013-12-09 15:45:31 +0000 1 1 1 Unclassified HTML WG Encrypted Media Extensions unspecified PC All RESOLVED LATER P2 normal --- 1 steele adrianba ddorwin mike public-html-media watsonm public-html-bugzilla oldest_to_newest 97228 0 steele 2013-12-06 01:32:24 +0000 It is possible for the browser get into a situation where multiple EME key requests are outstanding at the same time. Since they are asynchronous, the order the responses are received in is indeterminate. However there is no way to directly associate a response with its request today. Example: An application is playing back a video stream which makes frequent key requests (e.g. heart beat testing). If the delay between sending the request and receiving the response is longer than the heart beat interval, you are now in this situation. This could be addressed in a variety of ways: * We could explicitly say that no additional key requests may be sent for a given key session until the outstanding request has been completed. * We could require a URL to be passed in with the update() call which the CDM could match against the outstanding requests. * others? 97229 1 ddorwin 2013-12-06 02:07:43 +0000 What specifically is the problem with such outstanding requests that you're trying to address? In other words, why do the requests and responses need to be associated (other than perhaps within the server-CDM protocol)? 97253 2 adrianba 2013-12-06 17:37:56 +0000 (In reply to Joe Steele from comment #0) > * We could require a URL to be passed in with the update() call which the > CDM could match against the outstanding requests. Presumably any value that could be passed into the update() call as an additional parameter could also be included in the response from the server for those CDMs that need this? 97254 3 steele 2013-12-06 17:53:52 +0000 (In reply to David Dorwin from comment #1) > What specifically is the problem with such outstanding requests that you're > trying to address? In other words, why do the requests and responses need to > be associated (other than perhaps within the server-CDM protocol)? The requests may need to be processed in serial order. For example if request N+1 relies on information provided in response N. If the responses arrive in the wrong order, the processing could fail, even though the correct responses are all available. (In reply to Adrian Bateman from comment #2) > Presumably any value that could be passed into the update() call as an > additional parameter could also be included in the response from the server > for those CDMs that need this? True - however that would not allow supporting existing servers and content tied to those servers. This could also be handled in the app by tracking all the outstanding requests and sending the responses down in serial order. I guess we could write some boilerplate code for that and post it somewhere? 97256 4 adrianba 2013-12-06 18:10:41 +0000 (In reply to Joe Steele from comment #3) > This could also be handled in the app by tracking all the outstanding > requests and sending the responses down in serial order. I guess we could > write some boilerplate code for that and post it somewhere? Can't the CDM cache or drop out of order responses? Presumably if this is common (because the requests are taking too long) then sooner or later playback is going to fail because the license service isn't keeping up with the media? 97259 5 steele 2013-12-06 18:29:13 +0000 (In reply to Adrian Bateman [MSFT] from comment #4) > (In reply to Joe Steele from comment #3) > > This could also be handled in the app by tracking all the outstanding > > requests and sending the responses down in serial order. I guess we could > > write some boilerplate code for that and post it somewhere? > > Can't the CDM cache or drop out of order responses? Presumably if this is > common (because the requests are taking too long) then sooner or later > playback is going to fail because the license service isn't keeping up with > the media? It may be impossible for the CDM to distinguish between a response received out of order and a corrupted response, if the responses are encrypted. If the server lag is long-term, playback *is* going to start failing and it probably doesn't matter if the CDM fails because of out of order responses or because it can't get the keys fast enough. If the server lag is momentary, playback could start failing but might be able to continue if it receives responses in the right order. I think we can probably wait to see whether this is a problem in the real world. After some research into real-world heartbeat usage I don't think this scenario is common enough to worry about at this point. I will go ahead and close this. 97260 6 steele 2013-12-06 18:30:24 +0000 We should wait for implementation experience before we do anything here. 97334 7 watsonm 2013-12-09 15:45:31 +0000 I would expect a CDM that can generate multiple outstanding requests would need its own (secure) method to associate requests and responses, for example by including a sequence number in the protected part of the message.