Re: Last Call: <draft-ietf-httpbis-http2-16.txt> (Hypertext Transfer Protocol version 2) to Proposed Standard

Delan Azabani <> Sat, 03 January 2015 17:06 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 5D6941A9041 for <>; Sat, 3 Jan 2015 09:06:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.779
X-Spam-Status: No, score=-0.779 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_37=0.6, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0sxreeyd8IOY for <>; Sat, 3 Jan 2015 09:06:56 -0800 (PST)
Received: from ( [IPv6:2a00:1450:400c:c00::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 683471A9026 for <>; Sat, 3 Jan 2015 09:06:56 -0800 (PST)
Received: by with SMTP id b13so25413213wgh.4 for <>; Sat, 03 Jan 2015 09:06:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=WuuUbU87fThLn8Ed425VglxHP0rlZNRIdLTx7+F4lrU=; b=g9JsR0ie2xP4/Wrdx0b3P3mjbpvVMqFW0VjWFyp4SRicxe/xqFYjr7uQtZ45pNBDJg rjc35YBOUbycFeHkPHwoMBd3nTkNhgNTLofD+MQ2aI729F8SnbCH4t6D6gU9+TGTyfWa DvKYY02okpi/PJ0lBOQgrWwNIF6LB6gFw57ok=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=WuuUbU87fThLn8Ed425VglxHP0rlZNRIdLTx7+F4lrU=; b=Sm33VlAq4tZvx+4rGvTGvvi2R+qEOgURRpnJhnYZMuyhnJAlD6RnRTYv00A8IXyEQe zEl6LYfyo8ApoFnYN11cAvjO1A/VHS6SVq21Nn3LwnyUKlHsYri5sRNQFxQEgOkGRkyC P+DHFiU78fiAx2mn6YTZBXtlgAxLSL82EzDC8M+CR8ZFUhsUIRTF4sp2hZ1TqsrTI3By HLUf/VDpIGEnGS1mfr4MgAzifbvZEAZyMm+frRr3S6lh2dm4HK6eF59TZVKOUea2IU35 EU7Us/j+m+AYpYqACZQMnGTBRd2MVzvOGaUcM2x1EAsA1L+XpelaWDnkfjyokSAheD76 Xr0w==
X-Gm-Message-State: ALoCoQkfpHrwHfwXanDW191bVrzqvME6xSec5b2w0viqG63eHJUzhkEMRjOybdNO/kis+YfAJHcx
MIME-Version: 1.0
X-Received: by with SMTP id p6mr8777523wia.72.1420304815156; Sat, 03 Jan 2015 09:06:55 -0800 (PST)
Received: by with HTTP; Sat, 3 Jan 2015 09:06:55 -0800 (PST)
In-Reply-To: <AEE3A9C73AC6A1C6D6BFAD95@P5>
References: <> <> <AEE3A9C73AC6A1C6D6BFAD95@P5>
Date: Sun, 4 Jan 2015 01:06:55 +0800
Message-ID: <>
Subject: Re: Last Call: <draft-ietf-httpbis-http2-16.txt> (Hypertext Transfer Protocol version 2) to Proposed Standard
From: Delan Azabani <>
To: John C Klensin <>,,
Content-Type: text/plain; charset=UTF-8
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 03 Jan 2015 17:06:58 -0000

Without immediately addressing what has later been discussed in this
thread, I should probably clarify what I meant in my original post.

On Sat, Jan 3, 2015 at 10:12 PM, John C Klensin <> wrote:
> If I understand the above part of your comments correctly, "one
> A/AAAA record..." hasn't been necessary since HTTP 1.1
> introduced the HTTP "host" verb.  That was a lesson we learned
> from SMTP, FTP, and elsewhere -- virtual hosts should not
> require separate (either physical or virtual) interfaces and
> addresses.

With the introduction of the Host header, virtual hosts indeed do not
require new interfaces or addresses, be they physical or virtual.

Regardless of this, if I was to request <http://foo.example/> using a
current HTTP/1.1 user agent, the AAAA and/or A records for foo.example.
would be queried, potentially using the Happy Eyeballs algorithm.

If the entity behind foo.example. wanted to run their primary HTTP
service on a host other than the one indicated by the AAAA or A
records, the closest solutions now would be to configure the host on
the bare domain to either route or reverse proxy to the real server.

This may occur for example if foo.example. uses a shared web hosting
provider, while wanting to serve HTTP as well as other protocols
directly on their bare domain.

The ability to use SRV records would eliminate the additional traffic
and computational overhead required for routing or reverse proxying.