Re: [hybi] WebSocket handshake (HTTP and SSO)

Greg Wilkins <gregw@webtide.com> Mon, 30 August 2010 00:43 UTC

Return-Path: <gregw@webtide.com>
X-Original-To: hybi@core3.amsl.com
Delivered-To: hybi@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA8F63A659B for <hybi@core3.amsl.com>; Sun, 29 Aug 2010 17:43:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.824
X-Spam-Level:
X-Spam-Status: No, score=-0.824 tagged_above=-999 required=5 tests=[AWL=-0.706, BAYES_20=-0.74, FM_FORGED_GMAIL=0.622]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H48W85uekwYG for <hybi@core3.amsl.com>; Sun, 29 Aug 2010 17:43:42 -0700 (PDT)
Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id 61A613A63CB for <hybi@ietf.org>; Sun, 29 Aug 2010 17:43:42 -0700 (PDT)
Received: by gxk20 with SMTP id 20so2189836gxk.31 for <hybi@ietf.org>; Sun, 29 Aug 2010 17:44:13 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.101.69.4 with SMTP id w4mr3769906ank.5.1283129053199; Sun, 29 Aug 2010 17:44:13 -0700 (PDT)
Received: by 10.100.248.12 with HTTP; Sun, 29 Aug 2010 17:44:13 -0700 (PDT)
In-Reply-To: <4C7A269F.8020306@gmail.com>
References: <4C7A269F.8020306@gmail.com>
Date: Mon, 30 Aug 2010 10:44:13 +1000
Message-ID: <AANLkTinqJ+K-pqm7p7S+aviWVY==S0mJ9RBvNfpnTa02@mail.gmail.com>
From: Greg Wilkins <gregw@webtide.com>
To: Brodie Thiesfield <brodie@jellycan.com>
Content-Type: text/plain; charset="UTF-8"
Cc: hybi <hybi@ietf.org>
Subject: Re: [hybi] WebSocket handshake (HTTP and SSO)
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/hybi>, <mailto:hybi-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/hybi>
List-Post: <mailto:hybi@ietf.org>
List-Help: <mailto:hybi-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hybi>, <mailto:hybi-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 30 Aug 2010 00:43:44 -0000

Brodie,

I definitely would like to see the use-case that you describe supported.

It is true  that the -76/-00 drafts do not allow any other status
returns for a handshake, however I believe there is now consensus that
the handshake prior to the 101 response must be HTTP compliant.  Thus
I believe this implies that it will no longer be possible for the
websocket specification to disallow:

 + A HTTP persistent connection being used for HTTP and then being
upgraded to a websocket connection
 + A websocket server responding to a websocket handshake with a non
101 response code.
 + A websocket client acting reasonably when it receives a non 101
response to a websocket handshake.

I would hope to see this reflected in a draft  soon and this should at
least remove the prohibition on such use-cases.

However, removing the prohibition is not sufficient to make it a
supported use-case, as you will need buy in from servers and clients.

I do not think servers will be a problem, since if you use a HTTP
server that supports websockets, then it is very likely to just allow
arbitrary HTTP conversations to take place before the upgrade (as you
would have to do actual work to prevent that). Jetty certainly
supports this.

The problem will be the clients.  There is nothing compelling the
clients to open websocket connections using their HTTP stacks, which
may be capable of handling redirections, 401's, set-cookies and other
HTTP stuff commonly used for authentication and authorization. Even if
the clients do use their HTTP stacks for the websocket handshake,
there are problems with some features (eg 401's) which need
interaction from a user, as their may not be appropriate UI mechanisms
associated with websocket.  So either you will need to develop your
own client that you know will support the features that you want, or
their has to be a commonly accepted set of HTTP features that commonly
deployed websocket capable browsers will accept.

My feeling is that the browsers vendors are less keen on supporting
HTTP features on websocket handshakes, while the server vendors are
very keen.  I think some time and experience with real deployments is
needed for those two positions to converge.  Thus I think at this
stage having the prohibition on such features removed is the best we
can expect and that will allows  servers/browsers to experiment with
supporting HTTP features.

cheers






On 29 August 2010 19:21, Brodie Thiesfield <brodie@jellycan.com> wrote:
> Hi,
>
> I would like to request a clarification of the current thinking of the
> working group.
>
> I am a developer keen to use WebSocket for its ability to have multiple
> simultaneous outstanding requests from our clients over a single socket. My
> company's product currently uses SOAP over HTTP, however we are currently
> experimenting with existing browser implementations of WebSocket (+ flash
> where not supported). We are now sending the same SOAP requests over
> WebSocket and having some good results in our trials.
>
> However, we need to support this product in corporate networks, and for this
> reason one of our biggest requirements is to be able to support single sign
> on from the desktop.
>
> Prior to the server allowing the WebSocket upgrade request with a 101
> header, will it be valid to require authentication via standard HTTP 401
> authorization required dialog? (i.e. via Microsoft negotiate, basic, digest,
> etc). Only after the client is successfully authorized would we want to
> accept the Upgrade and change to WebSocket.
>
> The -76/-00 protocol would not permit this (due to the extra bytes in the
> Upgrade request) however the document
> https://datatracker.ietf.org/doc/draft-ietf-hybi-websocket-requirements/
> (REQ 8) states that connections must be HTTP up to the acceptance of the
> Upgrade, and (REQ 9) that existing HTTP components should be able to be
> reused.
>
> Is this document the latest thoughts of the WG? Should I continue with the
> assumption that it is likely that this style of WebSocket handshake would be
> supported?
>
> Regards,
> Brodie
>
> _______________________________________________
> hybi mailing list
> hybi@ietf.org
> https://www.ietf.org/mailman/listinfo/hybi
>