Re: Re: Quick review for draft-svirid-websocket2-over-http2 (Was: Re: Draft HTTPbis Agenda For Seoul IETF 97)

Van Catha <vans554@gmail.com> Thu, 20 October 2016 19:22 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 170801296B3 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 20 Oct 2016 12:22:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.931
X-Spam-Level:
X-Spam-Status: No, score=-6.931 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.431, 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 IjDu0rC0SubY for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 20 Oct 2016 12:22:47 -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 BAE711296BF for <httpbisa-archive-bis2Juki@lists.ietf.org>; Thu, 20 Oct 2016 12:22:46 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1bxIr9-0005x3-UZ for ietf-http-wg-dist@listhub.w3.org; Thu, 20 Oct 2016 19:18:24 +0000
Resent-Date: Thu, 20 Oct 2016 19:18:23 +0000
Resent-Message-Id: <E1bxIr9-0005x3-UZ@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <vans554@gmail.com>) id 1bxIr4-0005vx-PS for ietf-http-wg@listhub.w3.org; Thu, 20 Oct 2016 19:18:18 +0000
Received: from mail-qk0-f170.google.com ([209.85.220.170]) by lisa.w3.org with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <vans554@gmail.com>) id 1bxIr2-0008L3-9Y for ietf-http-wg@w3.org; Thu, 20 Oct 2016 19:18:17 +0000
Received: by mail-qk0-f170.google.com with SMTP id n189so113403431qke.0 for <ietf-http-wg@w3.org>; Thu, 20 Oct 2016 12:17:56 -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=cRa0j5CQP2bWRsK3AVdcnkkVsZiPCTVGyP1EkI/ssCs=; b=Wsz7M9zZBMCsEF5duJ25CFZFulAzxl+ZIb1/sK2f+YBwzEkA7llUiAQu9HaYloLZsW SdP5tIp2CZhJWoygm7uP6u5eUz+L3klHvCfhqGLx/tRtUzlrlf6aGGGiiWnDuDVCZHGQ XndnWrkXMRKQHCEvMVX8bTjq9fVGosyfXQQ1jC9O3Nj8cfyJo9Fr/u2ZFtHBYVaMcswF nsvYDp6nS1eBUb/SIIwdSczELSlARFn7juT4izryZN4c5VbXV5U4kDUkUWiU93vITRZ1 SOVh9L1dtATUUGI7qFVwUlwhpgb2eecLDuoAqDp2zMsjajqz54xw3a6cz6ldivyFgr2p IJoA==
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=cRa0j5CQP2bWRsK3AVdcnkkVsZiPCTVGyP1EkI/ssCs=; b=cevcSXlmxVsG6Fw89kYjahe9Y3bBva2HTg0Ltma4CTR3hYk9q/SYs1mQ/ppSA2qWbz +Yl5jK2PUCkire5NVYYgxn4Sb256Qv1QC58vY13FKHMWTihfvaZag3FBLpzYRyFAhg8j AsSG2GY6HyrCp08SPEZYVR1P775apBbtpK3rEZ0gsk+Fmo9g10khZm5uVP1aKl8hw1Di HhAuuiJ8ik/E1hy8ge9DHi878/fl1IgS3L8KHd+5RsiVd83topT+DMGpGnkHDFjPPxvV v5nL/mUfKdV1w03zON3REsnWktqa9qHIPRe6Sw8TAwF8WiOUgPQLLyWoGrPvZiohFMVs 43nw==
X-Gm-Message-State: ABUngvdBjW3dAIqDcplwYuxG7vJocDMtf9Fxi9hsnrHaoIKeTvG8EIJ6LnHcd4BfdcBUL2Huq4aiYXSptZRdnQ==
X-Received: by 10.55.76.138 with SMTP id z132mr1842929qka.194.1476991070309; Thu, 20 Oct 2016 12:17:50 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.55.209.66 with HTTP; Thu, 20 Oct 2016 12:17:49 -0700 (PDT)
In-Reply-To: <20161020093357.AB25113BFC@welho-filter2.welho.com>
References: <CANatvzx0+6P8+SifWY=4uFJUZg5mTKsjEeQgn2=w+huPEa9kyQ@mail.gmail.com> <20161020093357.AB25113BFC@welho-filter2.welho.com>
From: Van Catha <vans554@gmail.com>
Date: Thu, 20 Oct 2016 15:17:49 -0400
Message-ID: <CAG-EYCjJB4MAiqDiogxLTyNpCtWcCH68T3sfKfjWNi6W=39R2w@mail.gmail.com>
To: Kari Hurtta <hurtta-ietf@elmme-mailer.org>
Cc: HTTP working group mailing list <ietf-http-wg@w3.org>, Kazuho Oku <kazuhooku@gmail.com>, Tom Bergan <tombergan@chromium.org>, Ilari Liusvaara <ilariliusvaara@welho.com>
Content-Type: multipart/alternative; boundary="001a114a22f4153841053f50c8c7"
Received-SPF: pass client-ip=209.85.220.170; envelope-from=vans554@gmail.com; helo=mail-qk0-f170.google.com
X-W3C-Hub-Spam-Status: No, score=-4.5
X-W3C-Hub-Spam-Report: AWL=-0.569, 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: lisa.w3.org 1bxIr2-0008L3-9Y ca272353e602165ce78f90e417e49f10
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Re: Quick review for draft-svirid-websocket2-over-http2 (Was: Re: Draft HTTPbis Agenda For Seoul IETF 97)
Archived-At: <http://www.w3.org/mid/CAG-EYCjJB4MAiqDiogxLTyNpCtWcCH68T3sfKfjWNi6W=39R2w@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/32658
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>

> Some quick review comments:

>- The handshake seems to negotiate compression and then the frames
> contain compression method indicator. Are there really multiple
>  compression methods available on per-frame basis, or should the
>  compression just be 1 bit (compressed or not)?

The use case for this is that when using lz4, small frames under 20 octets
in size often end up being larger after compression.
This way the server can have more control of what it sends to client.

The reason for having different types of compression is to support a broad
range of data being transmitted. especially for all the
new custom protocol we have popping up.

>- The abbrevations in frame diagram are bit difficult to understand
>  (have those be expanded in above text?).

I agree on this. It is hard to draw up the frames and represent everything.
But rough idea when parsing is (everything is unsigned):

InnerFrame = case (Length = recv(1)):
  255:
    Length = recv(4)
  254:
    Length = recv(2)
  finally:
    recv(Length)

FrameHeader = InnerFrame[0]
FrameBody = InnerFrame[1,]
... continue

At first I had static sizes instead of the variable size, but the static
sizes produce extra bytes on the wire which can be reduces by introducing
some complexity. For example before a 100 octet sized frame length would
take 4 octets on the wire, now it just takes 1.

> - Somebody needs to try what this does against many HTTP/2 origins
>  that don't support WebSockets2 and against intermediaries with
>  custom server that actually supports it. Just to see what the
>  heck happens (if it is nasty, one might need to use SETTINGS to
>  signal support, either for WebSockets directly or for some sort
>  of strict scheme).

I think settings maybe the way to go at this point.  It seems to be quite
well received.

- What is "valid UTF-8" exactly? E.g. does it contain encodings for
  Unicode noncharacters?

It would be scanning over the string and validating every code point.    The
only reason this is included is to be backward compatible with WebSocket.

Ideally I just wanted to have binary frames, then when you receive them you
can
cast them to strings.


>  4.3.1.  GET
> https://tools.ietf.org/html/rfc7231#section-4.3.1
>
> |   A payload within a GET request message has no defined semantics;
> |   sending a payload body on a GET request might cause some existing
> |   implementations to reject the request.
> |
> |   The response to a GET request is cacheable; a cache MAY use it to
> |   satisfy subsequent GET and HEAD requests unless otherwise indicated
> |   by the Cache-Control header field (Section 5.2 of [RFC7234]).

> Changing of scheme does not change semantic of methods.

It seems that sending a Cache-Control header to indicate no caching would
work then?

I thought that a middlebox cannot cache ANYTHING unless the response
contains headers to allow caching.
It seems the opposite, anything can be cached unless strictly told not to.

The problem with CONNECT method is it seems to be used now for establishing
tunneling between middleboxes.

Introducing a custom method like WS2 also seems a little out of place.  But
a custom method method like
UPGRADE or something to indicate something is going on could work.



On Thu, Oct 20, 2016 at 5:33 AM, Kari Hurtta <hurtta-ietf@elmme-mailer.org>
wrote:

> > This could be the case for any HTTP/2 gateway that translates incoming
> > requests to HTTP/1, that does not reject unknown schemes. And whether
> > such gateway needs to reject schemes that do not match to the
> > request-response model of HTTP seems to be vague in reading RFC 7540.
> > Section 8.1.2.3 states that:
> >
> >       ":scheme" is not restricted to "http" and "https" schemed URIs.  A
> >       proxy or gateway can translate requests for non-HTTP schemes,
> >       enabling the use of HTTP to interact with non-HTTP services.
> >
> > My interpretation of this paragraph would be that it is permitted for
> > an HTTP/2 intermediary to transmit requests with schemes other than
> > "http" or "https", expecting that an upstream server would process the
> > request according to the scheme, considering the fact that (per my
> > understanding) such action is permitted in HTTP/1.1.
>
> Yes. HTTP/2 explicitly uses HTTP/1.1 semantic.
>
> 8.  HTTP Message Exchanges
> https://tools.ietf.org/html/rfc7540#section-8
>
> |   Thus, the specification and requirements of HTTP/1.1 Semantics and
> |   Content [RFC7231], Conditional Requests [RFC7232], Range Requests
> |   [RFC7233], Caching [RFC7234], and Authentication [RFC7235] are
> |   applicable to HTTP/2.  Selected portions of HTTP/1.1 Message Syntax
> |   and Routing [RFC7230], such as the HTTP and HTTPS URI schemes, are
> |   also applicable in HTTP/2, but the expression of those semantics for
> |   this protocol are defined in the sections below.
>
> 3.1.  Client Handshake Request
> https://tools.ietf.org/html/draft-svirid-websocket2-over-
> http2-00#section-3.1
>
> | 3.1.  Client Handshake Request
> |
> |    The client MUST use the :method GET.
> |
> |    The client MUST send a sec-ws2-version header that MUST specify the
> |    websocket2 version being used.
> |
> |    The client MAY send a sec-ws2-compression header that advertises the
> |    compression methods the client supports.  Valid key value pairs
> |   include:
>
> ↡
>
> | The client MUST NOT set the END_STREAM flag when sending the headers.
>
>
> Note however that this apply:
>
> 4.3.1.  GET
> https://tools.ietf.org/html/rfc7231#section-4.3.1
>
> |   A payload within a GET request message has no defined semantics;
> |   sending a payload body on a GET request might cause some existing
> |   implementations to reject the request.
> |
> |   The response to a GET request is cacheable; a cache MAY use it to
> |   satisfy subsequent GET and HEAD requests unless otherwise indicated
> |   by the Cache-Control header field (Section 5.2 of [RFC7234]).
>
>
> Changing of scheme does not change semantic of methods.
>
> 2.  Resources
> https://tools.ietf.org/html/rfc7231#section-2
>
> |   One design goal of HTTP is to separate resource identification from
> |   request semantics, which is made possible by vesting the request
> |   semantics in the request method (Section 4) and a few
> |   request-modifying header fields (Section 5).  If there is a conflict
> |   between the method semantics and any semantic implied by the URI
> |   itself, as described in Section 4.2.1, the method semantics take
> |   precedence.
>
> ( scheme is part of URI )
>
> 2.7.  Uniform Resource Identifiers
> https://tools.ietf.org/html/rfc7230#section-2.7
>
> |   Uniform Resource Identifiers (URIs) [RFC3986] are used throughout
> |   HTTP as the means for identifying resources (Section 2 of [RFC7231]).
> |   URI references are used to target requests, indicate redirects, and
> |   define relationships.
>
>
> / Kari Hurtta
>