Re: [presentation-api] Would a "closing" connection state be of any use?

@tomoyukilabs Thanks, your example works fine now!

I realize that I misread the the WebSocket interface spec and that it 
explicitly instructs user agents to discard messages received after a 
call to `close`:

> When a WebSocket message has been received with type type and data 
data, the user agent must queue a task to follow these steps: [WSP]
> 1.If the readyState attribute's value is not OPEN (1), then abort 
these steps.
> 
https://html.spec.whatwg.org/multipage/comms.html#feedback-from-the-protocol

(Calling `close` sets `readyState` to `CLOSING`, so it's not `OPEN` 
anymore when the message is received).

Thus I was wrong: your tests suggest that all tested Web browsers 
behave according to spec, except Safari.

I also misread the WebSocket protocol as it does not suggest that an 
on-going transmission should be finished but rather says "An endpoint 
MAY delay sending a Close frame until its current message is sent 
[...] However, there is no guarantee that the endpoint that has 
already sent a Close frame will continue to process data":
https://tools.ietf.org/html/rfc6455#section-5.5.1

The initial questions remain, though:

1. why expose the `closing` state to Web applications?
2. why expose the closing duration to Web applications in the first 
place?

Running your example clearly shows that user agents wait for the 
server ack before they transition the WebSocket connection to "closed"
 (as specified). Knowing that there is still a pending connection 
encourages the app to wait in situations where it wants to re-connect 
to the WebSocket server, perhaps?

-- 
GitHub Notification of comment by tidoust
Please view or discuss this issue at 
https://github.com/w3c/presentation-api/issues/240#issuecomment-173542127
 using your GitHub account

Received on Thursday, 21 January 2016 11:22:16 UTC