Re: WebSocket2

Van Catha <vans554@gmail.com> Sat, 01 October 2016 19:23 UTC

Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3725812B059 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sat, 1 Oct 2016 12:23:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.616
X-Spam-Level:
X-Spam-Status: No, score=-7.616 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-2.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qgg0fDLlkEyL for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sat, 1 Oct 2016 12:23:23 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C7E612B02E for <httpbisa-archive-bis2Juki@lists.ietf.org>; Sat, 1 Oct 2016 12:23:23 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1bqPog-0003L7-3C for ietf-http-wg-dist@listhub.w3.org; Sat, 01 Oct 2016 19:19:22 +0000
Resent-Date: Sat, 01 Oct 2016 19:19:22 +0000
Resent-Message-Id: <E1bqPog-0003L7-3C@frink.w3.org>
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <vans554@gmail.com>) id 1bqPoc-0003KQ-4a for ietf-http-wg@listhub.w3.org; Sat, 01 Oct 2016 19:19:18 +0000
Received: from mail-qk0-f180.google.com ([209.85.220.180]) by maggie.w3.org with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <vans554@gmail.com>) id 1bqPoa-0004ZB-Ct for ietf-http-wg@w3.org; Sat, 01 Oct 2016 19:19:17 +0000
Received: by mail-qk0-f180.google.com with SMTP id t7so134753418qkh.2 for <ietf-http-wg@w3.org>; Sat, 01 Oct 2016 12:18:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=XIHFdmjVrdnamo2pgS2EHCSM1jdFs1tS7VOMvpp3ph0=; b=MxGSwI0++eGXDeRyQzRBZxuDuQVSnlj2j/qEyFqQHyYBNxUbhHzSDTH7MGprKF3R+V jc3Ou3KQvv6+fpkE2LXC04iSa04x0PCuZTKsD5RPn/zDZBf1PKRgHVaEVWRO2hA0ELO7 qlykD4dAIO9KmUhyZxf4IGcO2TqRFKvkDcEGYC8Vq62rlM3Q+eDGjxPnOFjGIdGn4gzc CUmosnIdnH4WXnjCkSzJo/qgIMJpIdkV3JU0dpkttZA2eooe3uArro0WKOVFjn4XdUtT HdeCuNoIpz/CjjP9oWFZHZUo1SZBe+jxRVy347L/+7MGYlBIWdCguyWxZah6wSb3lTna So7g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=XIHFdmjVrdnamo2pgS2EHCSM1jdFs1tS7VOMvpp3ph0=; b=eXYcoN2dhgCJ5wgKyXNz5N1w4Go5svaHGDcSVubA2wHJOffyOQks0IQZcSYoMvvBcd /3GUOk2hhBQwZJVs9Y3LmVy0erB1pHvdwXGKIizhbtWb6iNK1LZV3jAiiE3EiTMTw5Cx mewYtwPfSn8Mf1LB9Gj5+RbFW44YDz2u9Von7gSKqB+qKsSqUwNSmWjq7UnuK/ZGMIcG 9nV4ivSgs8NEW8ECZziu8sSPzJqd7eS/fHWAIDRhqW6mGnXyOs7JBjUl2Or+goYaNDxh IYEhRMiT8xWmU4lHtJwDpUtzAf5kHnNHCAfTdA+094qB1iIqC3zwWgJp0ztzUyubq5mZ AUjA==
X-Gm-Message-State: AA6/9Rkyxng5/OMzDAFUHisMbL9ZG6acrM6DdabhmE1fZfQxBgm+t76PfPm2wmKbMKm/kSD1XQHyvyfsAcauIw==
X-Received: by 10.55.101.71 with SMTP id z68mr12402286qkb.276.1475349529586; Sat, 01 Oct 2016 12:18:49 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.55.214.220 with HTTP; Sat, 1 Oct 2016 12:18:49 -0700 (PDT)
In-Reply-To: <20161001184730.GA8356@LK-Perkele-V2.elisa-laajakaista.fi>
References: <CAG-EYCjx5=tExsjOJ+_-5p95Vp=Wfaz8JihDAAykDQpL64T4TA@mail.gmail.com> <20161001051700.245FA10F65@welho-filter1.welho.com> <CAG-EYCiXDYjmZ4r_8q31-UKQBG5=U53xOh1vef3-TJCVuytmdw@mail.gmail.com> <20161001184730.GA8356@LK-Perkele-V2.elisa-laajakaista.fi>
From: Van Catha <vans554@gmail.com>
Date: Sat, 1 Oct 2016 15:18:49 -0400
Message-ID: <CAG-EYChPJpAzoEuNwY3cNz503d0FRbNnDx_9AsNsZyfb5nmN0g@mail.gmail.com>
To: Ilari Liusvaara <ilariliusvaara@welho.com>
Cc: HTTP working group mailing list <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary=94eb2c056f48a17080053dd294c8
Received-SPF: pass client-ip=209.85.220.180; envelope-from=vans554@gmail.com; helo=mail-qk0-f180.google.com
X-W3C-Hub-Spam-Status: No, score=-5.1
X-W3C-Hub-Spam-Report: AWL=-1.138, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: maggie.w3.org 1bqPoa-0004ZB-Ct e124db1b6f3513391c8df7052495a6ef
X-Original-To: ietf-http-wg@w3.org
Subject: Re: WebSocket2
Archived-At: <http://www.w3.org/mid/CAG-EYChPJpAzoEuNwY3cNz503d0FRbNnDx_9AsNsZyfb5nmN0g@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/32439
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

> Is there request header to request no caching? There is certainly a
> response header to request no caching.

I believe there is no request that can specify "don't cache", but I may be
wrong.

> Or perhaps use a dedicated method? It would seem pretty obivous that
> if you see a unknown method, you shouldn't assume very much about what
> it is.

I think adding/using an unconventional method will be way beyond the scope
of what
is presented.  I do not think anyone will implement that?

> Unfortunately, HTTP/2 does not have strict scheme handling like I
> proposed. With it, one could just have directly used the wss scheme
> (or ws for oppsec) and be done with it.

:scheme is perfect! Wow.  If we could pass ws/wss for example as the scheme
that
fits perfectly. Looking at https://tools.ietf.org/html/rfc3986#section-3.1
the spec for schemes
it seems ws and wss are perfectly valid schemes to use and are registered;
http://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml.

If we wanted to pass ws2, we would have to register the scheme which I think
should not be a problem.  As ws2 will not be backwards compatible with
ws/wss.  Would wss2 need to be included as well in this case?

So in the current state of affairs, using wss as the scheme over HTTP/2
will default to using
WebSocket2. Using ws as the scheme will default to WebSocket2 as well (for
backwards compat).
So if the client API uses WebSocket("ws://my-http2-server.com/channel") or
wss, both should
go to WebSocket2.

Where is the problem in HTTP/2 that would disallow schemes different from
http and https, I do not see
anything related to this?


> It seems to me that using https:// GET here is rather dangerous. Even with
> extra custom headers.

Any alternative suggestion?






On Sat, Oct 1, 2016 at 2:47 PM, Ilari Liusvaara <ilariliusvaara@welho.com>
wrote:

> On Sat, Oct 01, 2016 at 02:20:38PM -0400, Van Catha wrote:
>
> > The proxy problem circles around back to the implementation. Perhaps a
> > header in the request could be included saying to not cache anything, if
> > the proxy caches things well its the proxies fault.  Also if the proxy is
> > not aware of WebSocket2 this should not matter, the proxies job is to
> > forward everything as it came.  As long as the proxy would forward the
> > websocket2-[version|compression] headers to the server and forward what
> the
> > server replies with there should be no problems.  Again if the proxy is
> > "smart" and decides to cache the response (which did not specify any
> > headers related to caching) its the proxies fault.  To be more direct the
> > response may be forced to include headers specifically instructing
> nothing
> > should be cached.  Does this work?
>
> Is there request header to request no caching? There is certainly a
> response header to request no caching.
>
> Or perhaps use a dedicated method? It would seem pretty obivous that
> if you see a unknown method, you shouldn't assume very much about what
> it is.
>
> > I am thinking using SETTINGS frames would be too complex, as that would
> > require baking WebSocket2 directly into HTTP/2, the way it is now,
> > WebSocket2 should run over HTTP/2 with minimal resistance since we do not
> > introduce new settings or HTTP/2 frame types.  HTTP/2 was designed from
> the
> > very beginning to not support 2 way streaming like websocket provides
> > currently for HTTP/1.1.  I think the resistance would be great if adding
> > WebSocket2 requires adding to the actual HTTP/2 specification.
>
> Unfortunately, HTTP/2 does not have strict scheme handling like I
> proposed. With it, one could just have directly used the wss scheme
> (or ws for oppsec) and be done with it.
>
> > If origin server does not know about WebSocket2 and the request succeeds
> > that is indeed a problem.  Perhaps the server can reply with the error
> > header always like websocket2-error: okay; in the case when the
> WebSocket2
> > negotation was a success. This way an origin server without WebSocket2
> will
> > reply with 200, and the client will see there is no websocket2-error:
> okay;
> > header and promptly notify the client that WebSocket2 negotiation failed.
>
> It seems to me that using https:// GET here is rather dangerous. Even with
> extra custom headers.
>
>
> -Ilari
>