IETF Logo Mail Archive

RE: Questions on HTTP URI schemes and QUIC

Lucas Pardue <Lucas.Pardue@bbc.co.uk> Wed, 18 July 2018 13:52 UTC

Return-Path: <Lucas.Pardue@bbc.co.uk>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA5E4130DD7 for <quic@ietfa.amsl.com>; Wed, 18 Jul 2018 06:52:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 sIJQToybGHt7 for <quic@ietfa.amsl.com>; Wed, 18 Jul 2018 06:52:23 -0700 (PDT)
Received: from mailout0.telhc.bbc.co.uk (mailout0.telhc.bbc.co.uk [132.185.161.179]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64C16126DBF for <quic@ietf.org>; Wed, 18 Jul 2018 06:52:23 -0700 (PDT)
Received: from BGB01XI1012.national.core.bbc.co.uk (bgb01xi1012.national.core.bbc.co.uk [10.161.14.16]) by mailout0.telhc.bbc.co.uk (8.15.2/8.15.2) with ESMTP id w6IDqIwN001682; Wed, 18 Jul 2018 14:52:18 +0100 (BST)
Received: from BGB01XUD1012.national.core.bbc.co.uk ([10.161.14.10]) by BGB01XI1012.national.core.bbc.co.uk ([10.161.14.16]) with mapi id 14.03.0389.001; Wed, 18 Jul 2018 14:52:18 +0100
From: Lucas Pardue <Lucas.Pardue@bbc.co.uk>
To: Sridhar Bhaskaran <sridhar.bhaskaran@huawei.com>, IETF QUIC WG <quic@ietf.org>
Subject: RE: Questions on HTTP URI schemes and QUIC
Thread-Topic: Questions on HTTP URI schemes and QUIC
Thread-Index: AdQehQaTzEsbGZZvQ4ml64uCil/3zQAGQAMg
Date: Wed, 18 Jul 2018 13:52:17 +0000
Message-ID: <7CF7F94CB496BF4FAB1676F375F9666A3BB77BFA@bgb01xud1012>
References: <0E42DD26875E1748992B1E3F732A36AE0129BCBA@BLREML503-MBX.china.huawei.com>
In-Reply-To: <0E42DD26875E1748992B1E3F732A36AE0129BCBA@BLREML503-MBX.china.huawei.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [172.19.161.213]
x-exclaimer-md-config: c91d45b2-6e10-4209-9543-d9970fac71b7
x-tm-as-product-ver: SMEX-12.5.0.1300-8.2.1013-23976.006
x-tm-as-result: No-1.001300-8.000000-10
x-tmase-matchedrid: byfwvk+IcRm7lpQUW6Uvz7iMC5wdwKqdwZLXS0hN8p3b6Y+fnTZUL3V8 6ck2cnUP7UIY7FTQEq2Xo+LdDt/YJs4MEMpuYr2lpvwZ9GmdwDP4qCLIu0mtIIzZ6FNX6KaLozk GjKWy0ilNYvDaO9t+nCgYXq4u0oay+dVjQNaxOresDodw9yUkxpnZ3QZNYH8lFlEHrMSBTX++8x ACKN6zGIfhK4s3hzbmECTq1hdYNfFNTwBwYO28L/p1plqEbuqxeFyzQYzPQ+TIvQIyugvKdZUgS Lx++MHyn/3mwgykHMD1kO5kGLTAx9b7UmjtI1CSX39j8VcpJxEHdYH++bm0GEmVes1pwna567zK QiK/wKzDzL4vreNXHbBMgJuhfWMiQgUInkqQBs9kiLB9qoJwH30tCKdnhB581B0Hk1Q1KyJXaDn 6DhA2Ao2j49Ftap9ExlblqLlYqXLjuiF7ro3IQ7hNCgyyTm7VvyRdTjpwY9ovtWLkGpUIs5tFFh Ww9ee1ELkzJvIsnr5fjlAWuVH+tCF9eE/0RdtqjECEHl6HMMPIKX8H5ZJqUCmvpvEsYCZa+dHcz GoifKaUJgj59gJblQ5uHRe1kWVm
x-tm-as-user-approved-sender: Yes
x-tm-as-user-blocked-sender: No
x-tmase-result: 10--1.001300-8.000000
x-tmase-version: SMEX-12.5.0.1300-8.2.1013-23976.006
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/mQIacnaM8a1-FW-eNWVAmoHisXs>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 18 Jul 2018 13:52:26 -0000

Hi Sridhar,

I presented some slides [1] about HTTP proxying (including HTTP over QUIC) at the IETF 102 HTTPbis session this week. I'm not sure if your questions are motivated by that session, or if it is coincidence. There are some visualisations of the various tunnelling options (as I understand them) across the main slides and backup slides.

Regards
Lucas

[1] - https://github.com/httpwg/wg-materials/blob/gh-pages/ietf102/hint-helium.pdf

>-----Original Message-----
>From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Sridhar Bhaskaran
>Sent: 18 July 2018 11:50
>To: IETF QUIC WG <quic@ietf.org>
>Subject: Questions on HTTP URI schemes and QUIC
>
>Dear Quic experts,
>
>I am Sridhar Bhaskaran from Huawei. Going through the drafts on QUIC
>transport and HTTP over QUIC, I have the following queries
>
>1. If a HTTP URI uses http:// scheme and the origin server advertises alternate
>service via QUIC, can a HTTP client use QUIC to connect to the origin server
>and still use the http:// scheme URI?
>2. If a HTTP URI uses https:// scheme and the HTTP client is configured to
>connect to a HTTP proxy and if the HTTP proxy supports QUIC, my
>understanding is the following sequence of events
>	a. HTTP client to HTTP proxy QUIC connection is setup
>	b. HTTP client issues a HTTP CONNECT request to the proxy with the
>":authority" HTTP/2 pseudo header pointing to the origin server
>	c. HTTP proxy upon getting the CONNECT request sets up a TCP
>connection with the origin server
>	d. HTTP proxy sends HTTP CONNECT response to the client
>	e. HTTP client then initiates a TLS connection towards the origin server
>via the proxy and the proxy simply tunnels it.
>	f. Actual HTTP traffic happens between client and origin server
>
>Is this correct?
>
>Where I am not clear is whether step /e/ actually happens. If it does, then for
>step /f/ is the client required to do ciphering 2 times - one for the TLS and
>other for the QUIC connection to proxy itself.
>
>Could you please clarify?
>
>Thanks
>Sridhar

v2.23.0 | Report a Bug | By Email