Re: [hybi] Multiplexing in WebSocket

[Greg Wilkins <[e-mail]>]

Ian Hickson wrote:

>>> The IETF is welcome to do whatever it likes. The only reason Web 
>>> Sockets is here is that the IETF wanted it here.
>> And since you have accepted the IETFs invitation to submit a draft, you 
>> should do so in good faith and not expect the IETF to rubber stamp what 
>> you've done simply because you have no intention of changing it.
> 
> I've made lots of changes to the WebSocket protocol -- heck, I've made so 
> many changes based on feedback here and elsewhere that people have started 
> complaining that I've made too many!

My comment was directed at your statement that the IETF can "do whatever
it likes" in response to my suggestion that there may be wider concerns
considered than just the narrow js case that you have considered in HTML5.


> Actually, as designed, WebSocket does an end-run around most of these. The 
> only case I'm aware of where WebSocket would need help is in environments 
> that do not even allow port 443 traffic to pass through unmolested.

And this is exactly the sort of wider concern that the IETF might want
to consider.

You can tunnel bidirectional traffic over DNS if you want, but that
does not mean the IETF will sanction such a protocol.
Having a long term solution that essentially misuses the CONNECT
mechanism of proxies is far from ideal.

Considering how intermediaries can interact with bidirectional
connections is extremely important - even if only at the level
of how to stop them closing what they think are idle connections.



> On Thu, 22 Oct 2009, Joshua Bell wrote:
>> * I seem to recall that one of the desires for sentinel-based frames was 
>> to allow octet streams for which the length was not known in advance. 
> 
> No; the only reason for sentinel-based frames was to not rely on authors 
> having to determine the length of their UTF-8-encoded strings, which in 
> many environments can be easy to get wrong.

Authors that can't determine the length of a UTF-8 string are not exactly
the sort of developers that should be implementing network protocols.

When sending this utf-8, buffers will be used and lengths must be
checked - else there will be buffer overruns and associated failures
and/or security issues.

It seams an entirely reasonable simplification of websocket to
use only length limited framing and to use the type byte to indicate
such things as content charset


regards