[Bug 13984] New: Need a way to object detect binary support before connecting

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

           Summary: Need a way to object detect binary support before
                    connecting
           Product: WebAppsWG
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: WebSocket API (editor: Ian Hickson)
        AssignedTo: ian@hixie.ch
        ReportedBy: w3.org@martintribe.org
         QAContact: member-webapi-cvs@w3.org
                CC: mike@w3.org, public-webapps@w3.org


The API needs to define a way for Javascript to object detect whether the
WebSocket API supports sending and receiving of binary data and this needs to
be exposed prior to initiating a connection (e.g. because sub-protocol and
extension settings may depend on whether binary data can be sent or not).

Chrome 14 and 15 and Firefox 6/7 support the new protocol and other updates to
the new API but don't actually support binary data sending/receiving yet.

Until the object is instantiated, the WebSocket objects looks the same for the
old API as for the new API.

I tried the following hack:

    var wstest = new WebSocket('ws://localhost:57111');
    if (typeof(wstest.binaryType) !== "undefined") {
        ...  // binary
    } else {
        ...  // text only
    }
    wstest.close();
    wstest = null;

However, that is insufficient for a few reasons:

- the spec allows for the UA to initiate a connection immediately in the
background (e.g. Chrome does this) which means an async error is trigger by
failure to connect.

- the spec is not crystal clear about what the behavior of binaryType is in the
case where binary data is not in fact supported. For example, in Chrome 14 and
15 binaryType is visible and set to "blob" by default and can be set to
"arraybuffer". However, binary data is not in fact supported.

- it's just plain hideous.

My suggestions:

- In addition to the readyState constants (CLOSED, CLOSING, etc), the
uninstantiated WebSocket object should also have the following constants: BLOB
and ARRAYBUFFER which are equal to "blob" and "arraybuffer" respectively. These
should only appear in the WebSocket object if those data types are actually
supported for sending and receiving. This is backwards compatible with the
current definition (i.e. you can do ws.binaryType = "blob"; or ws.binaryType =
WebSocket.BLOB);

- The spec should clarify that the binaryType field should only appear if
binary data is in fact supported (or alternately, it is there but should be
empty and throw an error if an attempt is made to set it).

-- 
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 Wednesday, 31 August 2011 23:50:43 UTC