Re: [hybi] #1: HTTP Compliance

[John Tamplin <[e-mail]>]

On Thu, Jul 22, 2010 at 2:32 AM, Ian Hickson <[e-mail]> wrote:

> > I disagree completely -- there is going to be a web server involved in
> > delivering the web application, and I think the more usual scenario is
> > that web server also implements the WebSocket server.  Why would someone
> > prefer to deploy two servers rather than one, except in the case where
> > their web server doesn't yet support WebSocket?  If this protocol is
> > successful, over time that will drop to 0.
>
> I see no advantage in the common case to using the same software for both.
> It's far easier to just host them separately.
>
> Why don't people use the same software for HTTP and DNS? Or IMAP and SMTP?
> Or IRC and FTP? Why would they act differently for HTTP and WebSocket?


Few people serve their web apps from a DNS server.  Initially, virtually all
WebSocket clients are going to be JS applications downloaded via HTTP.  If I
am writing a JS game to be run in the browser, why would I want to maintain
two servers instead of one?  Using Jetty (and I would expect most other
servers to add support once the protocol is standardized), I can just add
another method on my servlet and presto, I have WebSocket support.  This is
especially important if the fallback is going to be hanging gets or polling
via HTTP -- I can have common code for either solution, rather than
duplicating code that runs in two separate servers, and it gets me the
ability to more easily share state between HTTP requests and WebSocket
messages, such as authentication credentials.

On Thu, 22 Jul 2010, Greg Wilkins wrote:
> >
> > Currently the WS handshake can only be rejected by closing the
> > connection and discarding any potential HTTP response.  Thus a webapp
> > that wishes to fall back to a non-ws transport will have to establish a
> > new connection, maybe negotiate TLS, then handshake the new transport.
> > Thus there will be an extra 2 or 3 round trips to establish the
> > fall-back transport.
>
> The only time this would be useful is when the script doesn't know ahead
> of time which host it will be connecting to, and doesn't know ahead of
> time what protocols that host will support, but where it does know that it
> will support either a Web Socket server or an HTTP-based mechanism. This
> will only occur during the transition period where some sites provide an
> HTTP-based protocol but not a Web Socket version, but where other sites
> provide Web Socket equivalents.
>

Or if it doesn't know that it can actually speak WebSocket all the way to
the server because of potentially interfering intermediaries.

-- 
John A. Tamplin
Software Engineer (GWT), Google