Re: [hybi] web socket protocol in "last call"?

I agree with Greg on this.

As another vendor of server software that could make use of this, in its
current form it would just be something we implement under the covers to
slightly improve things. However, if the solution to reverse proxies and
other such intermediaries causing issues is that they will block WebSockets
then we'd have to stick with our current 'comet hacks'.

We always advise our customers to put our servers Internet facing, but in
large organisations this isn't always possible - and thinking that anyone
wanting to run a WebSocket server will just have to get a proxy that
conforms or remove it all together is frankly naive.

On Wed, Oct 28, 2009 at 10:49 PM, Greg Wilkins <gregw@webtide.com> wrote:

> Infinity Linden (Meadhbh Hamrick) wrote:
> > WS is essentially unusable for me in it's current form. or rather, i
> > could use it, but why? my use case of establishing reverse
> > request-response semantic recognizable by intermediaries that supports
> > channel multiplexing is possible over WS, but then again, it's also
> > possible by extending HTTP, so why not just do that?
>
> I completely agree with this sentiment.   WS is usable, but provides
> no significant benefit over HTTP other than a warm philosophical
> feeling that you are not abusing HTTP, is a little more byte
> efficient and marginally better latency.
>
> But it is not going to scale for my use-cases because of the
> connection bloat.   It's going to break all the load balancers
> I work with, and the SSL offloaders and most other network
> infrastructure.
>
> I'll be interested to see what happens when intermediaries
> notice ws trying to run around them.  Will they support it or
> block it?   My money is on the later.
>
> If it becomes a standard as is, we will support it... but hide
> it in the basement, under the stairs behind a sign that says
> "beware of the leopard".    It will be a novelty like HTTP
> pipelining - you can turn it on and play with it, but will
> not seriously consider using it in deployment other than in
> very specific circumstances.
>
> Failing consensus on the protocol, I would have really liked the
> opportunity of having a service provider API in the browser - so
> I could intercept standard ws API and transport it over something
> that would work my use-cases, or inserting layers between
> app API and transport.
>
> Pity.  Opportunity lost.
>
> regards
>
>
>
>
>
>
>
>
> _______________________________________________
> hybi mailing list
> hybi@ietf.org
> https://www.ietf.org/mailman/listinfo/hybi
>