Subject: Re: [hybi] Reducing the constraints on the HTTP part of WebSockets

From: Willy Tarreau <[email-masked]>
Date: Tue, 23 Feb 2010 13:11:31 +0100

Hello Greg,

I hope you don't mind me joining the discussion.

> > * It has also been suggested that using GET with an Upgrade is harder to 
> > implement on existing HTTP stacks than CONNECT would be.
> 
> Where did this suggestion come from?
>
> CONNECT is a method that is intended to be used for opening proxied
> connections.   Servers will either not support it or have it wired up
> to some proxy code.    Subverting this for a protocol upgrade is
> highly undesirable.
> 
> The GET with upgrade header is very much the appropriate mechanism to
> use.   Servers will either already support Upgrade - in which case ws
> should be easy, or they will not - in which case they can simply
> implement the mechanism as specified by RFC2616.

I was one of those suggesting to Ian to use the CONNECT in complement
of the existing method. While this can look strange at first, it is
not that stupid because of existing products : a wide variety of
HTTP gateways (reverse-proxies, load balancers, ...) are compatible
with proxies. Typically, most if not all HTTP load balancers can be
installed in front of HTTP proxies. As such, they already *do* support
the CONNECT method without doing anything specific. Some commercial
products such as Alteon, as well as some open source software such as
Pound and Haproxy come to mind.

However, most of these products will not handle the specific case of
the 101 status code. The reason is that 1) nobody uses it right now,
and 2) the way it's defined in RFC2616 lets the reader think that if
they don't explcitly need to implement it, they can process it as a
100 response :

RFC2616 page 40 #6.1 :
   "HTTP applications are not required
    to understand the meaning of all registered status codes, though such
    understanding is obviously desirable. However, applications MUST
    understand the class of any status code, as indicated by the first
    digit, and treat any unrecognized response as being equivalent to the
    x00 status code of that class"

But the 100 is just an informational response which can safely be
ignored, leaving the gateway waiting for the next non-1xx response.
Until very recently (discussions with Ian in fact), haproxy did not
support 101 and considered it as 100. Pound does not support 101
either. And to the best of my knowledge, Alteon does not support it
either. Some products will simply consider that the 101 preceeds
another response (=100), others (products grown from HTTP/1.0) will
take it as any definitive status code and will expect a new HTTP
request after the first GET.

Concerning possible issues with the CONNECT method when handled by
an origin server, it was already suggested in RFC2817 that an origin
server might handle it by itself :

RFC2817 page 6 #5.3 :
  "An origin server which receives a CONNECT request for itself MAY
   respond with a 2xx status code to indicate that a connection is
   established."

Also, some servers also support being used as proxies (eg: apache),
so making them support the CONNECT method would probably not be a
big deal.

At first when I discussed with Ian, I really was in favor of using
CONNECT *instead of* the 101+upgrade scheme. Now after some discussion
with him as well as some deeper reading of various docs, I think it
would be very nice to mimmic what was done for TLSv1 (RFC2817) and
suggest that both methods could be supported. Some it might be easier
for some servers to implement the CONNECT method, while for other
ones the 101 might be better. However, when having to deal with large
infrastructures, it is likely that the CONNECT will be able to pass
through multiple equipment without being degraded, while the GET+101
may be stopped by some IPS, firewalls, load balancers, accelerators
or web application firewalls.

I'm not saying that the 101 is not in the spec, it's just that the
spec is a bit fuzzy on how it may be handled if unused and has made
it possible for many equipments not to specifically implement it due
to lack of users.

I don't know what's your opinion on this.

Best regards,
Willy