Re: [hybi] #1: HTTP Compliance

Ian Hickson <ian@hixie.ch> Wed, 21 July 2010 22:54 UTC

Return-Path: <ian@hixie.ch>
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 16BA53A6863 for <hybi@core3.amsl.com>; Wed, 21 Jul 2010 15:54:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.461
X-Spam-Level:
X-Spam-Status: No, score=-2.461 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599]
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 hhSBjyYBT6qG for <hybi@core3.amsl.com>; Wed, 21 Jul 2010 15:54:31 -0700 (PDT)
Received: from looneymail-a1.g.dreamhost.com (caibbdcaaaaf.dreamhost.com [208.113.200.5]) by core3.amsl.com (Postfix) with ESMTP id 09A9B3A6857 for <hybi@ietf.org>; Wed, 21 Jul 2010 15:54:31 -0700 (PDT)
Received: from ps20323.dreamhostps.com (ps20323.dreamhost.com [69.163.222.251]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by looneymail-a1.g.dreamhost.com (Postfix) with ESMTP id DFC1315D577; Wed, 21 Jul 2010 15:54:47 -0700 (PDT)
Date: Wed, 21 Jul 2010 22:54:47 +0000
From: Ian Hickson <ian@hixie.ch>
To: John Tamplin <jat@google.com>
In-Reply-To: <AANLkTinorjXFsTH=TvhhF-+e3Eyen8EA2qL7wFCmqpYe@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1007212247590.7242@ps20323.dreamhostps.com>
References: <068.d07026741c6694cd80652d2a7d34f236@tools.ietf.org> <4BF106AD.6020506@webtide.com> <A42E692A-7210-4FF1-AB4F-CFB3E8C38756@apple.com> <AANLkTinorjXFsTH=TvhhF-+e3Eyen8EA2qL7wFCmqpYe@mail.gmail.com>
Content-Language: en-GB-hixie
Content-Style-Type: text/css
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
Cc: "hybi@ietf.org" <hybi@ietf.org>
Subject: Re: [hybi] #1: HTTP Compliance
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: Wed, 21 Jul 2010 22:54:32 -0000

On Wed, 21 Jul 2010, John Tamplin wrote:
> On Mon, May 17, 2010 at 5:29 AM, Maciej Stachowiak <mjs@apple.com> wrote:
> > 
> > Ian has claimed that the extra bytes after the request help WebSocket 
> > fail early in the face of unaware proxies, though we do not yet have 
> > data showing this to be the case. We do know that without this, often 
> > the handshake will appear to succeed but transmitting messages will 
> > fail, for the network setups of many users.
> >
> > I don't think anyone has indicated a practical problem caused by the 
> > extra bytes.
> 
> I believe we have already had a real-world practical case where they did 
> cause a problem:
> 
>    - client sends WebSocket request that goes through a proxy, random bytes
>    are not advertised in the Content-length
>    - proxy doesn't know WebSocket, passes along connection to real server
>    which does implement WebSocket
>    - server waits reading random bytes which were not forwarded
>    - server drops the connection after a timeout

Success! :-)


> Thus the random bytes did succeed in preventing a WebSocket connection 
> across a non-WS compliant proxy, but:
> 
>    1. the proxy was actually capable of forwarding the connection if the
>    server had completed the request

That's easy to resolve. The simplest solution that comes to mind is having 
the server send back the 101 straight away, and having the proxy send the 
bytes on as soon as it sees the 101.

(Note: from a conformance standpoint, the "server" includes the proxy.)


>    2. we had to wait for a timeout, so this was not a fast-fail situation

Fast-fail is ideal, but not really necessary (there's plenty of other 
situations that fail very slowly). We just don't want false positives. If 
there's a way of tweaking the protocol so we don't get false positives, 
and still fulfills our other requirements, but that fails faster, that 
would be great.


>    3. the same thing could have been more easily accomplished by having a WS
>    control frame exchanged at startup with similar results without
>    non-compliant random bytes on the wire

Wouldn't that increase the startup latency by another round-trip?

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'