Re: [hybi] #1: HTTP Compliance

Bjoern Hoehrmann <derhoermi@gmx.net> Mon, 17 May 2010 19:28 UTC

Return-Path: <derhoermi@gmx.net>
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 977683A6AD8 for <hybi@core3.amsl.com>; Mon, 17 May 2010 12:28:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Level:
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001]
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 EymFNIOSojJJ for <hybi@core3.amsl.com>; Mon, 17 May 2010 12:28:30 -0700 (PDT)
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 7BEBF3A6A5E for <hybi@ietf.org>; Mon, 17 May 2010 12:28:29 -0700 (PDT)
Received: (qmail invoked by alias); 17 May 2010 19:28:18 -0000
Received: from dslb-094-222-156-193.pools.arcor-ip.net (EHLO hive) [94.222.156.193] by mail.gmx.net (mp018) with SMTP; 17 May 2010 21:28:18 +0200
X-Authenticated: #723575
X-Provags-ID: V01U2FsdGVkX1+ZG6NtWWyZYzfjCUgT3+RE4R5eK1GrrL+iNMQIFB u4r7FSdQPfAdzc
From: Bjoern Hoehrmann <derhoermi@gmx.net>
To: Greg Wilkins <gregw@webtide.com>
Date: Mon, 17 May 2010 21:28:23 +0200
Message-ID: <3043v51hqi3qo6ed6d4qgk30epl89tgk0v@hive.bjoern.hoehrmann.de>
References: <068.d07026741c6694cd80652d2a7d34f236@tools.ietf.org> <4BF106AD.6020506@webtide.com> <Pine.LNX.4.64.1005170918310.25609@ps20323.dreamhostps.com> <4BF11920.2080307@webtide.com> <Pine.LNX.4.64.1005171039050.25609@ps20323.dreamhostps.com> <4BF12FF1.2020101@webtide.com>
In-Reply-To: <4BF12FF1.2020101@webtide.com>
X-Mailer: Forte Agent 3.3/32.846
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Y-GMX-Trusted: 0
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: Mon, 17 May 2010 19:28:31 -0000

* Greg Wilkins wrote:
>On 17/05/10 13:20, Ian Hickson wrote:
>> On Mon, 17 May 2010, Greg Wilkins wrote:
>>>
>>> The server is going to have to send responses and is currently faced 
>>> with a difficult (or impossible) choice between sending a HTTP compliant 
>>> or a websocket compliant response.
>> 
>> If the server is a Web Socket server, and it received a request from a 
>> Web Socket client, then why would it care about HTTP?
>> 
>> If the server is not a Web Socket server, then why would it ever consider 
>> sending a response back using Web Sockets?
>> 
>> If the server is aware of Web Sockets and HTTP, and gets a request from an 
>> HTTP client, then why would it respond with Web Sockets?
>> 
>> I really don't understand what the choice is. In every situation I can 
>> see, there's an unambiguous right response.
>
>This is not an exhaustive list and you left out the situation
>that I have been describing in my examples.
>
>   The server is aware of both web sockets and HTTP and
>   receives a request from a websocket client that is
>   to be rejected.
>
>For one of the many reasons I've outlined in my other email, that
>request is handled either by code that does not know about
>websockets, or is unable to act as the websocket spec requires
>(ie closing connection).
>
>Thus the only possible choice is for the server to send
>a compliant HTTP response, which is contrary to the websocket
>specification.

It seems to me Ian is saying a hybrid HTTP/Websocket server is required
to behave as mandated by the Websocket protocol only when it choses to
accept a Websocket connection request. If it decides to speak only HTTP
to some client, then it needs to conform only to the HTTP specification.
You on the other hand seem to be saying, because it is a hybrid, and be-
cause it is responding to a Websocket connection attempt, the Websocket
requirements do apply to the server.

It does seem clear to me that the Websocket specification cannot mandate
server behavior of any kind before the server decides to accept the re-
quest to switch the protocol to the Websocket protocol, which it would
signal by sending a 101 response as specified in the Websocket specifi-
cation. If it does not do so, the negotiation to switch protocol failed.

>Websocket clients are going to receive 404's, 503's etc.
>They are going to have to handle them sensibly and report
>reasonable errors to the user.

(I note that can lead to information disclosure problems.)
-- 
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/