Re: [hybi] Additional HTTP headers on upgrade request?

Greg Wilkins <gregw@webtide.com> Wed, 21 July 2010 01:49 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 8C26E3A6A79 for <hybi@core3.amsl.com>; Tue, 20 Jul 2010 18:49:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.682
X-Spam-Level:
X-Spam-Status: No, score=-1.682 tagged_above=-999 required=5 tests=[AWL=0.294, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=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 1h2GCmi7IUoF for <hybi@core3.amsl.com>; Tue, 20 Jul 2010 18:49:14 -0700 (PDT)
Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 486993A65A6 for <hybi@ietf.org>; Tue, 20 Jul 2010 18:49:12 -0700 (PDT)
Received: by fxm1 with SMTP id 1so3566650fxm.31 for <hybi@ietf.org>; Tue, 20 Jul 2010 18:49:27 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.122.146 with SMTP id l18mr6120764far.82.1279676967532; Tue, 20 Jul 2010 18:49:27 -0700 (PDT)
Received: by 10.223.112.129 with HTTP; Tue, 20 Jul 2010 18:49:27 -0700 (PDT)
In-Reply-To: <AANLkTinGz6pUxxMMohgQJQIWY3YWLKhO2K5YtAR8Hf39@mail.gmail.com>
References: <n2s188fcbce1005071111kd19e6f41m861eaeb593d88475@mail.gmail.com> <4BE5994E.4010701@webtide.com> <u2n188fcbce1005092125veaf94306u249a225bdd3925ca@mail.gmail.com> <B8058102-9589-4663-976D-217B939667DD@apple.com> <Pine.LNX.4.64.1007210038520.7242@ps20323.dreamhostps.com> <AANLkTinGz6pUxxMMohgQJQIWY3YWLKhO2K5YtAR8Hf39@mail.gmail.com>
Date: Wed, 21 Jul 2010 11:49:27 +1000
Message-ID: <AANLkTinNG2fHAQaZdEfuQeN2pEVNQRNSCP1AwDpinFm0@mail.gmail.com>
From: Greg Wilkins <gregw@webtide.com>
To: hybi@ietf.org
Content-Type: multipart/alternative; boundary="001636c5a78f13b950048bdc0309"
Subject: Re: [hybi] Additional HTTP headers on upgrade request?
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 01:49:18 -0000

I'll try writing that again in fully formed English sentences this time
(sorry too much in a rush):


Ian,

it is a little disingenuous of you to fall back on the "what's the use
case?" stone wall
on topics like this that have been long discussed and people have given many
use
cases at length.   You might not understand and/or agree with the use cases
presented,
but that is entirely different to pretending that others have not motivated
their contributions
to the discussion with good reasoning.

The result of continually asking "what is the use-case" when it has already
been explained
many times, is that the list just goes around and around in endless circles.

In this particular case, it has been long argued that arbitrary headers
should be allowed in
the handshake for flexibility and anticipation of future needs.   You've
refuted the need for
generally extensible header.  Now  Doug motivated his comment with the
specific
use-case of using user-agent for dealing with browser quirks.

Let's flip this around the otherway... because allowing arbitrary headers is
not really
a feature to be added to  websocket  because before the upgrade the
connection
is HTTP and thus arbitrary headers are by default allowed.

In essence, you are trying to add a "feature" to the websocket handshake to
prevent
the addition of arbitrary headers.

So what is the use-case for that?  I know you have previously argued that
somehow it
would be easier for amateurs not to have to write code to ignore headers
(surely they
just don't write code to handle them?), but the amateur programmer
requirement has been
widely rejected.     Is there any other use-case that motivates the
rejection of websocket
handshakes due to the presence of additional ignorable headers?

regards





On 21 July 2010 11:38, Greg Wilkins <gregw@webtide.com> wrote:

>
>
> On 21 July 2010 10:57, Ian Hickson <ian@hixie.ch> wrote:
>
>> On Fri, 7 May 2010, Doug Simpkinson wrote:
>> >
>> > In draft 76, the upgrade request is said to include cookies that may be
>> > relevant, but no mention of other HTTP headers is made.
>> >
>> > What about other relevant HTTP headers such as User-Agent and
>> > Accept-Language?  Shouldn't these also be sent?
>>
>> What's the use case?
>>
>
> Ian,
>
> it is a little disingenuous of you to fall back on the "what's the use
> case?" stone wall
> on topics like this that have been long discussed and people have given
> many use
> cases at length.   You might not understand and/or agree with the use cases
> presented,
> but that is entirely different to pretending that others have not motivated
> their contributions
> to the discussion with good reasoning.
>
> The result of continually asking "what is the use-case" when it has already
> been explained
> many times, is that the list just goes around and around in endless
> circles.
>
> In this particular case, it has been long argued that arbitrary headers
> should be allowed in
> the handshake for flexibility and anticipation of future needs.   You've
> refuted the need for
> generally extensible header.  Now  Doug motivated his comment with the
> specific
> use-case of using user-agent for dealing with browser quirks.
>
>
> Let's flip this around the otherway... because allowing arbitrary headers
> is not really
> a feature of websocket is not really a feature because before the upgrade
> the connection
> is HTTP and thus arbitrary headers is allowed.
>
> In essence, you should be making the use-case for adding a "feature" to the
> websocket
> handshake to prevent the addition of arbitrary headers.
>
> So what is the use-case for that?  I know you have previously argued that
> somehow it
> would be easier for amateur not to have to write code to ignore headers
> (surely they
> just don't write code to handle them?), but the amateur programmer
> requirement has been
> widely rejected.     Is there any other use-case that motivates the
> rejection of websocket
> handshakes due to the presence of additional ignorable headers?
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>