Re: [hybi] #1: HTTP Compliance

Greg Wilkins <gregw@webtide.com> Tue, 18 May 2010 07:48 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 AC1E83A67EF for <hybi@core3.amsl.com>; Tue, 18 May 2010 00:48:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.068
X-Spam-Level:
X-Spam-Status: No, score=0.068 tagged_above=-999 required=5 tests=[AWL=-0.555, BAYES_50=0.001, 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 DM3HgOuSDvuC for <hybi@core3.amsl.com>; Tue, 18 May 2010 00:48:45 -0700 (PDT)
Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 339F53A6839 for <hybi@ietf.org>; Tue, 18 May 2010 00:48:22 -0700 (PDT)
Received: by wyb42 with SMTP id 42so3243229wyb.31 for <hybi@ietf.org>; Tue, 18 May 2010 00:48:08 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.227.69.71 with SMTP id y7mr5905340wbi.123.1274168888280; Tue, 18 May 2010 00:48:08 -0700 (PDT)
Received: by 10.216.52.9 with HTTP; Tue, 18 May 2010 00:48:08 -0700 (PDT)
In-Reply-To: <Pine.LNX.4.64.1005172259030.22838@ps20323.dreamhostps.com>
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> <15307.1274106895.116423@Sputnik> <Pine.LNX.4.64.1005172259030.22838@ps20323.dreamhostps.com>
Date: Tue, 18 May 2010 09:48:08 +0200
Message-ID: <AANLkTimZ2VLRow7c4P94dLpSjduKuIPo-tUqPUZwV16x@mail.gmail.com>
From: Greg Wilkins <gregw@webtide.com>
To: hybi <hybi@ietf.org>
Content-Type: text/plain; charset="UTF-8"
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: Tue, 18 May 2010 07:48:46 -0000

On 18 May 2010 01:57, Ian Hickson <ian@hixie.ch> wrote:
>
> Again I don't see a problem here
>
Ian,

If you don't see a problem, and believe that combined servers can
respond as HTTP compliant servers, then why is the proposal to change
"compatible" to "compliant" is being opposed so vigorously? If there
is no problem for a combined server staying HTTP compliant if the
handshake is not accepted, then let's just say so.

For the most part, the only change in the specification that would
result from this is perhaps a change in language. So that for example
instead of saying the only *allowed* response code and headers are ...
the spec should say that the only *accepted* response code and headers
are ...

There is a separate debate regarding if the random bytes after the
request are HTTP compliant or not, but that is a different debate to
should we be compliant or not.

It is also a separate debate about what HTTP features a websocket
client *might* choose to respect or be compelled to reject. I do
understand that there may be problems using some HTTP features, but
they should be considered on a case by case basis and not broadly
ruled out by needless restrictions on headers and response codes. For
example:
+ user-agent headers can surely be allowed
+ some Via headers would be great to work out what intermediaries are
supporting websocket
+ I understand the problem of a 401 challenge collecting credentials
from the user, but in many/ most cases the browser will already have
collected credentials and have them available.
+ cross domain redirection might be a problem, but there are many use
cases for same domain redirection.
+ it may be unsafe to expose error details in the javascript API, but
that is an entirely different matter to having a protocol that can
understand errors, even if only to displayed them on the console of
the browser

Note that some client/servers might even choose to support features on
the HTTP handshake that are not even mentioned in any specification,
because it is the intent of HTTP to be openly extensible.

You might be opposed to the usage of all of such features, but please
make your case on the basis of a discussion about the features rather
than opposing the simple change of "compatible" to "compliant"
or the existence of blanket ban on the sending arbitrary headers or of
4xx or 5xx status codes etc.
If you think the handshake should not be openly extensible, then just
make that case, rather than try to force the result by a needlessly
restricted handshake.

regards