Subject: Re: [hybi] Generic WebSocket Subprotocol Close Code

From: Patrick Gansterer <[email-masked]>
Date: Tue, 4 Nov 2014 18:35:34 +0100

On 27.10.2014, at 14:33, Takeshi Yoshino <[email-masked]> wrote:

> So, two errors like this?
>  
> 3000 Generic subprotocol error
> 3001 Invalid subprotocol data

Yes, that's my current idea.

> BTW, what's the motivation? Providing default for convenience?

I need some possibility to inform the server about an error at the client side (browser) when invalid data has been received. Since I think this is a problem more people implementing subprotocols will have, I think that is a good idea to define generic errors, instead of having error codes for "subprotocol A invalid data", "subprotocol B invalid data", "subprotocol C invalid data" and so on.

The big question is if anybody else has a better approach for this problem or if there are other "generic errors" we might want to define for subprotocol implementors.

--
Patrick

---

From: Takeshi Yoshino <[email-masked]>
Date: Wed, 5 Nov 2014 17:20:55 +0900

On Wed, Nov 5, 2014 at 2:35 AM, Patrick Gansterer <[email-masked]> wrote:

> I need some possibility to inform the server about an error at the client
> side (browser) when invalid data has been received.

So, you need to inform the generic WebSocket protocol stack in the server,
not application layer code?

As the client received invalid application-level data, it's likely that the
application-level data it has sent to the server is also not understood by
the server correctly. So, it's not good to use the application layer
channel to inform the server of the error details. Sending error details
over closing handshake is more reliable than using the possibly-broken
application layer channel. From this point of view, it makes sense to
utilize closing handshake for this purpose.

If it's for debugging, just saying that something wrong happened on
subprotocol level sounds not so helpful information. Maybe you'll want to
report more details of invalidness using the reason part or define
application specific error code in the range of 4000-4999. But having a few
generic code defined doesn't sound bad.