Re: [quicwg/base-drafts] HTTP/QUIC without Alt-Svc? (#253)

Ryan Hamilton <notifications@github.com> Tue, 07 February 2017 16:48 UTC

Return-Path: <noreply@github.com>
X-Original-To: quic-issues@ietfa.amsl.com
Delivered-To: quic-issues@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1661129D6F for <quic-issues@ietfa.amsl.com>; Tue, 7 Feb 2017 08:48:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.886
X-Spam-Level:
X-Spam-Status: No, score=-8.886 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-1.887, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.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 BMAIKaLE3QXu for <quic-issues@ietfa.amsl.com>; Tue, 7 Feb 2017 08:48:10 -0800 (PST)
Received: from github-smtp2b-ext-cp1-prd.iad.github.net (github-smtp2-ext2.iad.github.net [192.30.252.193]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7359A129D6C for <quic-issues@ietf.org>; Tue, 7 Feb 2017 08:48:10 -0800 (PST)
Date: Tue, 07 Feb 2017 08:48:09 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1486486089; bh=m8/UEPjc91EFxWe6laBRMmlKWYUFNVoJJmpPF6d3vCg=; h=From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=qpEKDRj8774hSCDDBYF5xGILfti2veLdIgUL+Sh0ycBX7uASqVIoV43qEKMM5r1bp wC9RRADUVQptQdiQAApFe3BbZRO+7nBGlxl+duqaaaHsYGX/DYNXKc9JRLaKng46uX iBzQGFxRKMDnoous81TXzKf3L5YxcLLWZmGGSoC4=
From: Ryan Hamilton <notifications@github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/253/278060609@github.com>
In-Reply-To: <quicwg/base-drafts/issues/253@github.com>
References: <quicwg/base-drafts/issues/253@github.com>
Subject: Re: [quicwg/base-drafts] HTTP/QUIC without Alt-Svc? (#253)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5899fa4998c66_244a3fa48a2b71402724bc"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: RyanAtGoogle
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
X-GitHub-Recipient-Address: quic-issues@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/L206m4at3h2ndsuHHQ6j1rxa0QQ>
Cc: Subscribed <subscribed@noreply.github.com>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.17
Reply-To: quic@ietf.org
List-Id: Notification list for GitHub issues related to the QUIC WG <quic-issues.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic-issues/>
List-Post: <mailto:quic-issues@ietf.org>
List-Help: <mailto:quic-issues-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 07 Feb 2017 16:48:13 -0000

On Mon, Feb 6, 2017 at 8:12 PM, Martin Thomson <notifications@github.com>
wrote:

> Why don't you use ALTSVC at the proxy? It's not like proxy setup is a
> commonplace action. A new scheme isn't something one does lightly.
>
> (Perhaps I used scheme in the wrong way?) We have support for "proxy",
"socks", "socks5" proxy schemes, so adding "quic" was quite straightforward
and is not user visible (though it is visible in the pac file, of course).
In any case, it's not clear to me that Alt-Svc applies to proxies. As I
read the spec, Alt-Svc defines a mechanism for an origin to specify a
different server. I don't think of a proxy as an origin, though I guess one
could? I'd be curious to hear more about this! That being said, in the
context of proxies it seems desirable for users to be able to deploy a QUIC
proxy without needing to also deploy an https proxy.


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/253#issuecomment-278060609