[Bug 14474] New: Make it possible to close a connection in such a manner that all subsequent events are surpressed

http://www.w3.org/Bugs/Public/show_bug.cgi?id=14474

           Summary: Make it possible to close a connection in such a
                    manner that all subsequent events are surpressed
           Product: WebAppsWG
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: WebSocket API (editor: Ian Hickson)
        AssignedTo: ian@hixie.ch
        ReportedBy: jonas@sicking.cc
         QAContact: member-webapi-cvs@w3.org
                CC: mike@w3.org, public-webapps@w3.org


According to bug 14331 comment 8, the protocol requires that a connection can
be closed while still allowing incoming events.

At the same time, I suspect that many web developers expect that if you call
.close on a connection, no more "message" events will be fired.

Consider for example a chat application based on HTML/JS which uses websockets
to receive incoming messages as well as send outgoing messages. The chat
application has a [X] icon in the corner which allows the user to close the
chat.

When the user closes the chat, the webpage calls socket.close() on the
websocket connection. It then simply drops its references to the socket without
making any further modifications to it.

This means that the onmessage event handler still remains active. If a incoming
message is received, that means that the page might create UI and display where
the chat application used to be before it was closed. This is ugly and
unexpected.

This is of course fixable from a webpage point of view. However since it seems
like a rare condition, it's likely that the developer won't detect this during
development, resulting in bugs for users which is bad.

To fix this, while still conforming to the websocket protocol, I propose that
we make it possible to close the connection in such a manner that it allows
additional incoming message, or close it in such a manner that any incoming
messages as suppressed.

I can think of at least two ways of accomplishing this:
1. Add a optional boolean argument to close.
2. Add a new function which takes the same arguments as close.

The default behavior can be debated in either solution, but I propose that the
default should be to suppress additional messages as that seems like the safer
path which will generate fewer bugs.

If we go with 2 I therefor suggest that we make .close suppress messages, but
.closeAllowIncoming allows additional incoming messages.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

Received on Friday, 14 October 2011 23:01:51 UTC