W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2010

workability (or otherwise) of HTTP upgrade

From: Greg Wilkins <gregw@webtide.com>
Date: Fri, 26 Nov 2010 16:06:41 +1100
Message-ID: <AANLkTin6=8_Bhn2YseoSHGh1OSkQzsYrTW=fMiPvYps1@mail.gmail.com>
To: HTTP Working Group <ietf-http-wg@w3.org>, hybi <hybi@ietf.org>
I'm cross posting this message to both the hybi (websockets) and
http-bis mailing list as I think this is an issue that is very
relevant to both groups.

The hybi/websocket protocol, as currently proposed, has a handshake
mechanism that is roughly based on the HTTP upgrade mechanism.
Progress in the hybi/websocket mailing has ground to a halt because we
appear unable to get a clear consensus between the two advocated ways
forward:

 1) Make the "roughly based" HTTP upgrade mechanism a fully compliant
HTTP upgrade.
 2) Move away from HTTP upgrade and use another mechanism (potentially
CONNECT or SSL extensions)

To paraphrase the arguments against 1), there are some that are
concerned that an Upgrade based handshake will never be able to be
adequately secured against cross protocol attacks from ws-browsers to
non ws-servers. Also there is some concern that intermediaries might
not well support Upgrade and that other mechanisms might have a higher
success rate.

So I thought that it would be good to move that discussion from hybi
to HTTP-bis so we can stall progress here.... no I mean so that we can
get a wider view on the capabilities and vulnerabilities that might
apply to Upgrade.

My understanding is that Upgrade was included in HTTP for precisely
the reason that Websocket wishes to use it - ie to take an existing
HTTP connection and to upgrade the protocol run over the connection to
something with different capabilities than HTTP.
I would also expect that if there are problems with lack of Upgrade
support in intermediaries, then it would be easier to get
intermediaries to be updated to a standard generic HTTP mechanism
rather than some special purpose usage of CONNECT.

If websocket is unable to securely use Upgrade, then there must be
some fundamental flaw in Upgrade that should either be fixed in
httpbis (if allowed by the charter).   If Upgrade cannot be fixed,
then perhaps httpbis needs to somehow deprecate the mechanism and we
can look together for alternatives?

So I'd ask the httpbis readers, are there any reasons you know of that
would prevent Upgrade being used for websocket?
And I'd ask the hybi upgrade sceptics if they could perhaps voice
their concerns about Upgrade in more detail than my paraphrasing
above.

regards
Received on Friday, 26 November 2010 05:07:18 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:33 GMT