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
- [hybi] #1: HTTP Compliance hybi issue tracker
- Re: [hybi] #1: HTTP Compliance Greg Wilkins
- Re: [hybi] #1: HTTP Compliance Maciej Stachowiak
- Re: [hybi] #1: HTTP Compliance Ian Hickson
- Re: [hybi] #1: HTTP Compliance Vladimir Katardjiev
- Re: [hybi] #1: HTTP Compliance Greg Wilkins
- Re: [hybi] #1: HTTP Compliance Greg Wilkins
- Re: [hybi] #1: HTTP Compliance Maciej Stachowiak
- Re: [hybi] #1: HTTP Compliance Ian Hickson
- Re: [hybi] #1: HTTP Compliance Greg Wilkins
- Re: [hybi] #1: HTTP Compliance Julian Reschke
- Re: [hybi] #1: HTTP Compliance Greg Wilkins
- Re: [hybi] #1: HTTP Compliance Greg Wilkins
- Re: [hybi] #1: HTTP Compliance Salvatore Loreto
- Re: [hybi] #1: HTTP Compliance Dave Cridland
- Re: [hybi] #1: HTTP Compliance Scott Ferguson
- Re: [hybi] #1: HTTP Compliance Maciej Stachowiak
- Re: [hybi] #1: HTTP Compliance Maciej Stachowiak
- Re: [hybi] #1: HTTP Compliance Greg Wilkins
- Re: [hybi] #1: HTTP Compliance Daniel Stenberg
- Re: [hybi] #1: HTTP Compliance Jamie Lokier
- Re: [hybi] #1: HTTP Compliance Bjoern Hoehrmann
- Re: [hybi] #1: HTTP Compliance Bjoern Hoehrmann
- Re: [hybi] #1: HTTP Compliance Ian Hickson
- Re: [hybi] #1: HTTP Compliance Jamie Lokier
- Re: [hybi] #1: HTTP Compliance Ian Hickson
- Re: [hybi] #1: HTTP Compliance Greg Wilkins
- Re: [hybi] #1: HTTP Compliance Jamie Lokier
- Re: [hybi] #1: HTTP Compliance Jamie Lokier
- Re: [hybi] #1: HTTP Compliance Greg Wilkins
- Re: [hybi] #1: HTTP Compliance Pieter Hintjens
- Re: [hybi] #1: HTTP Compliance Roberto Peon
- Re: [hybi] #1: HTTP Compliance Ian Hickson
- Re: [hybi] #1: HTTP Compliance Greg Wilkins
- Re: [hybi] #1: HTTP Compliance Jamie Lokier
- Re: [hybi] #1: HTTP Compliance Jamie Lokier
- Re: [hybi] #1: HTTP Compliance Scott Ferguson
- Re: [hybi] #1: HTTP Compliance Roberto Peon
- Re: [hybi] #1: HTTP Compliance Ian Hickson
- Re: [hybi] #1: HTTP Compliance John Tamplin
- Re: [hybi] #1: HTTP Compliance John Tamplin
- Re: [hybi] #1: HTTP Compliance Willy Tarreau
- Re: [hybi] #1: HTTP Compliance Roberto Peon
- Re: [hybi] #1: HTTP Compliance John Tamplin
- Re: [hybi] #1: HTTP Compliance Roberto Peon
- Re: [hybi] #1: HTTP Compliance Willy Tarreau
- Re: [hybi] #1: HTTP Compliance Roberto Peon
- Re: [hybi] #1: HTTP Compliance Willy Tarreau
- Re: [hybi] #1: HTTP Compliance Ian Hickson
- Re: [hybi] #1: HTTP Compliance Willy Tarreau
- Re: [hybi] #1: HTTP Compliance Greg Wilkins
- Re: [hybi] #1: HTTP Compliance Jamie Lokier
- Re: [hybi] #1: HTTP Compliance Jamie Lokier
- Re: [hybi] #1: HTTP Compliance Willy Tarreau
- Re: [hybi] #1: HTTP Compliance Jamie Lokier
- Re: [hybi] #1: HTTP Compliance Jamie Lokier
- Re: [hybi] #1: HTTP Compliance Willy Tarreau
- Re: [hybi] #1: HTTP Compliance Willy Tarreau
- Re: [hybi] #1: HTTP Compliance Greg Wilkins
- Re: [hybi] #1: HTTP Compliance Willy Tarreau
- Re: [hybi] #1: HTTP Compliance Ian Hickson
- Re: [hybi] #1: HTTP Compliance John Tamplin
- Re: [hybi] #1: HTTP Compliance Julian Reschke
- Re: [hybi] #1: HTTP Compliance Greg Wilkins
- Re: [hybi] #1: HTTP Compliance Willy Tarreau
- Re: [hybi] #1: HTTP Compliance Roberto Peon
- Re: [hybi] #1: HTTP Compliance Julian Reschke
- Re: [hybi] #1: HTTP Compliance Willy Tarreau
- [hybi] An input document (was: #1: HTTP Complianc… S Moonesamy
- Re: [hybi] #1: HTTP Compliance Shelby Moore
- Re: [hybi] #1: HTTP Compliance Willy Tarreau
- Re: [hybi] #1: HTTP Compliance gustav trede
- Re: [hybi] #1: HTTP Compliance Willy Tarreau
- Re: [hybi] #1: HTTP Compliance Shelby Moore
- Re: [hybi] #1: HTTP Compliance gustav trede
- Re: [hybi] #1: HTTP Compliance Daniel Stenberg
- Re: [hybi] #1: HTTP Compliance Willy Tarreau
- Re: [hybi] #1: HTTP Compliance Shelby Moore
- Re: [hybi] #1: HTTP Compliance Willy Tarreau
- Re: [hybi] #1: HTTP Compliance Shelby Moore
- Re: [hybi] #1: HTTP Compliance Shelby Moore
- Re: [hybi] #1: HTTP Compliance Willy Tarreau
- Re: [hybi] #1: HTTP Compliance Shelby Moore
- Re: [hybi] #1: HTTP Compliance Adam Barth
- Re: [hybi] #1: HTTP Compliance L.Wood
- Re: [hybi] #1: HTTP Compliance Adam Barth
- Re: [hybi] #1: HTTP Compliance Julian Reschke
- [hybi] Objections (was: #1: HTTP Compliance) S Moonesamy
- Re: [hybi] #1: HTTP Compliance Willy Tarreau
- Re: [hybi] #1: HTTP Compliance Shelby Moore
- Re: [hybi] #1: HTTP Compliance Willy Tarreau
- Re: [hybi] #1: HTTP Compliance Shelby Moore
- Re: [hybi] #1: HTTP Compliance Greg Wilkins