Ian Hickson wrote: > On Mon, 1 Feb 2010, Maciej Stachowiak wrote: > > On Feb 1, 2010, at 4:00 PM, Ian Hickson wrote: > > > > > > On the client side, I agree in principle (at least to ensure that no > > > client-to-server data is lost in a case where the API is used to send > > > frames then immediately close the connection). However, what if the > > > server never closes its side of the connection, even after the client > > > initiates a close? Should we have some sort of timeout? > > > > > > On the server side, I don't think there's any point _requiring_ that > > > the server close gracefully. If the server really doesn't care if data > > > it just sent is received, e.g. because it knows the client side has > > > already GC'ed its WebSocket object, then it should just be able to > > > close abruptly. > > > > How can the server possibly know that the client has already GC'd its > > WebSocket object, if the server and not the client is the initiator of > > the close? (If the client initiates the close, then at least in my > > proposal there's no extra work for the server.) > > The server and the client are typically written by the same person. If the > client sends a message in the subprotocol saying "ok after this I'm > throwing away all references to the object", then the server can know that > there's no point sending further data. Isn't that the same as a close message with the same semantics? -- Jamie
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.