- From: Ian Hickson <ian@hixie.ch>
- Date: Wed, 8 Jun 2011 18:42:25 +0000 (UTC)
- To: Adrian Bateman <adrianba@microsoft.com>
- cc: "Web Applications Working Group WG (public-webapps@w3.org)" <public-webapps@w3.org>
On Wed, 8 Jun 2011, Adrian Bateman wrote: > On Tuesday, June 07, 2011 10:36 AM, Ian Hickson wrote: > > On Tue, 7 Jun 2011, Adrian Bateman wrote: > > > This check-in [1] reintroduces the onerror handler that was removed > > > previously [2]. Since, in general, WebSocket protocol errors are fatal > > > and result in onclose, what is the purpose of adding this back? > > > > Ian asked me to put it back so that authors can distinguish between a > > server closure and a client-initiated error-driven closure. > > What is the difference between these two cases? When would onerror fire > that wouldn't result in onclose with wasClean=false? Isn't the wasClean > flag sufficient? If the server screwed up the handshake, for instance, you'd get onerror. If the server just closed the connection, you wouldn't, but wasClean would be false. This should hopefully be clear once Ian publishes the latest draft (which he may already have done, I didn't check). HTH, -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Wednesday, 8 June 2011 18:42:49 UTC