All, I'd like to add a use-case to this thread:
"We have a video streaming service available to paying subscribers. Users navigate to our page and choose a video they would like to watch. A Javascript application on the page contacts an application server to authenticate and authorize the user. The application server provides the script with information needed to stream the video and then the video is streamed using the <video> element. The video content is stored on standard web servers, so video streaming can continue without further interaction with the application server. For various business reasons we need to know, at any given time and as far as possible, which subscribers are streaming. So we need to know when the user stops streaming the video." That's the use case. It's easy to solve in the case that the user simply stops the video and remains on our page. The problem is when the user closes the page or browser during streaming. Clearly, we cannot know 100% when users stop streaming, due to events like browser crashes or sudden loss of power. It is sufficient for us to know most of the time. It would be insufficient, however, if we could not cover the case of users closing windows or the browser. Also, we would like to receive confirmation at the client that the server has received the final message before deleting state on the client. This is so that, if this confirmation is not received, we can resend the final message next time we have a chance. Also, we've considered "heartbeat" type solutions, which whilst better than nothing are vulnerable to an attack in which the heartbeat messages are blocked. We have been thinking of solutions along the lines of using XHR during in an onclose handler. With current browser implementations we would need to use XHR in synchronous mode. We would also need any operations we need to prepare the request to be synchronous (for example WebCrypto operations we plan to use for security). It would simplify things if we were able to use the normal async operations - that is, if processing could continue after onclose for sufficient time to complete the operations we need. I'd be very happy to hear what people on this list think of the problem and how we might solve it. Thanks, Mark Watson On May 7, 2012, at 11:25 PM, Jonas Sicking wrote: > On Mon, May 7, 2012 at 12:30 PM, Tab Atkins Jr. <[email protected]> wrote: >> On Mon, May 7, 2012 at 9:05 PM, Jonas Sicking <[email protected]> wrote: >>> On Mon, May 7, 2012 at 8:59 AM, Boris Zbarsky <[email protected]> wrote: >>>> On 5/7/12 11:53 AM, Tab Atkins Jr. wrote: >>>>> Yes, definitely (unless you set .withCredentials on it or something, >>>>> like the XHR attribute). >>>> >>>> Hold on. If you _do_ set withCredentials, you should be required to pass >>>> the credentials in or something. Under no circumstances would prompting >>>> for >>>> credentials for a request associated with an already-unloaded page be OK >>>> from my point of view.... >>> >>> There seems to be some confusion here regarding how withCredentials >>> works. First of all withCredentials is a CORS thing. CORS requests >>> *never* pop up an authentication dialog. (There is also the question >>> of if we want to support CORS here, I suspect we do). >>> >>> But I totally agree with Boris that we can't ever pop up security >>> dialogs for a site that the user has left. >> >> I definitely agree that we never pop up an auth dialog for an >> unloadHandler request. That's just silly. >> >> If I'm understanding XHR's withCredentials flag, it just sends the >> *existing* ambient credentials, to apply against HTTP auth (along with >> cookies and such). It doesn't prompt you for anything if you don't >> already have ambient credentials for a given site, right? > > Correct. > > / Jonas >
