Re: New Version Notification for draft-kazuho-early-hints-status-code-00.txt

Kazuho Oku <> Mon, 07 November 2016 09:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0A118129702 for <>; Mon, 7 Nov 2016 01:31:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.998
X-Spam-Status: No, score=-7.998 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, RCVD_IN_DNSWL_HI=-5, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id dFpTx-4wMWHC for <>; Mon, 7 Nov 2016 01:31:51 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 493AE1296E3 for <>; Mon, 7 Nov 2016 01:31:51 -0800 (PST)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1c3gDU-0002AP-90 for; Mon, 07 Nov 2016 09:27:48 +0000
Resent-Date: Mon, 07 Nov 2016 09:27:48 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1c3gDO-00029X-4U for; Mon, 07 Nov 2016 09:27:42 +0000
Received: from ([]) by with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <>) id 1c3gDH-0000rg-KY for; Mon, 07 Nov 2016 09:27:36 +0000
Received: by with SMTP id p190so169658298wmp.1 for <>; Mon, 07 Nov 2016 01:27:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=p5krONlZW+/JszoJKw95RhVcq4LjtDa0eKXvJLNQyGA=; b=L+6K6KeVhb0ZEZTrlPb1U1s+dBOXl1UOBclY5A3cdTvIHsgYMrHVORbj6V/+mTyWqo vpPr/ZgsNB+UhZ9E8TrJ3hwqrSVfXMPRTSlSVpY0eLp3LtTNJipiyqRCk4J+j9/+dN2k tAuZLWJ+KifXdVz3LXWyi+WmSvW2r1riQQGA6pKnK3LvIVdO8pWu90V2VkswWoxbn27o Dmqarg2LYyv0TBCEgunrJCNUWH+n1Fx05CvVUvObOQ1btHAxfiJKKHisBbJZM4qYKwuT rlZshgs3fHzt4MhWObY1OaUnBeVmt+15TWZ+znNF3LJTaz3mafPqkQ4DWL7z0xZ2Gfr+ UhTQ==
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:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=p5krONlZW+/JszoJKw95RhVcq4LjtDa0eKXvJLNQyGA=; b=L7QEEyrzOEzVM/Vsriwl5s7Ie0fBvbNpj4KNFN0uy3OIhrdikAxmVn5rVqzBAjD3aU /8wF0LhjajoiXvvf34Nhx4WKh/3a95F4X5o5uU3Mru+yQvMc84TG6QBgEyrL/3J/gWn8 +n1ayofDvB2QjJUoniTaBPsD9HEotly+bVxVywozxHsQk594rcDG0ScpRb76GH8H4sXJ Ny2eg+nXXKSGze7LnZa6tpGPha/Z0QCAw9zY7RwXaVwSxKi8D+Gn+CcGdLD7+sQK5sCp /UZIc0RgFVf38wo45x6W8MWlQmxapz7eE7TcTVt9s2onHUgd/x8gn3Ynn0czO1te2Aj5 QDhg==
X-Gm-Message-State: ABUngvcpJ0+TT1wDYXAnrvfFdNARY8IErkizqpwLmXaKj3356+k7yb4m8i7eVn64S2OJZbv0r+NJbYBpspw0Xg==
X-Received: by with SMTP id vt3mr4258110wjb.223.1478508924895; Mon, 07 Nov 2016 00:55:24 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Mon, 7 Nov 2016 00:55:23 -0800 (PST)
In-Reply-To: <>
References: <> <> <>
From: Kazuho Oku <>
Date: Mon, 07 Nov 2016 17:55:23 +0900
Message-ID: <>
To: Mark Nottingham <>
Cc: HTTP Working Group <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-4.5
X-W3C-Hub-Spam-Report: AWL=-0.984, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: 1c3gDH-0000rg-KY 466615faaa363519dae9e878d1916c10
Subject: Re: New Version Notification for draft-kazuho-early-hints-status-code-00.txt
Archived-At: <>
X-Mailing-List: <> archive/latest/32851
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

2016-11-07 16:40 GMT+09:00 Mark Nottingham <>:
> [ personal response ]
> Hey Kazuho,
> Interesting stuff, looks good to me. People have been asking for a facility to delay the status code for a while, but it's never happened, because that would require arbitrary buffering by clients (shifting it from the server). This is a nice compromise, at least for some use cases.
> Saying that the headers are going to also appear in the final response nicely sidesteps the question of how to combine the two, while taking advantage of HPACK.
> In retrospect, it's a bit of a shame that we have this requirement in H2: "All pseudo-header fields MUST appear in the header block before regular header fields." If not for that, we could send an "early" HEADERS followed by the :status etc. in a CONTINUATION.

Thank you for your comment.

Using CONTINUATION to split hints and actual headers sounds like an
interesting idea.

However, I am worried about the limits of the approach, due to the
fact that you cannot send any information related to a different
stream within a set of HEADERS frame and the following CONTINUATION

For example, you'd might want to send links of external resources
along with H2 pushes of resources belonging to the same origin. Such
combination is possible only by using an informational response.

> I suppose a SETTING could be used to turn that requirement off, but I'm not sure that's more workable than just using a new status code, as you've done.
> Cheers,
> P.S. In the first paragraph of section 2, s/request/response/

Thank you for pointing that out. Fixed in my draft.

>> On 1 Nov. 2016, at 1:25 am, Kazuho Oku <> wrote:
>> Hi,
>> I've just posted a new I-D named "An HTTP Status Code for Indicating Hints".
>> The draft can be found at
>> A prettified editor's copy can be found at
>> The draft proposes a new _informational_ status code that can be used
>> for indicating hints to help a client start making preparations for
>> processing the final response, while the server struggles to build the
>> final response.
>> Actually, we already have a working implementation. H2O, our HTTP/2
>> server, recognizes Link: rel=preload headers within an informational
>> response sent from upstream, and tries to push the specified resource.
>> One reason I decided to write this draft is because I believe it would
>> be better to standardize the mechanism.
>> But I also believe that having support for this status code within the
>> web browsers is beneficial as well.
>> For example, the proposed status code can be used by edge servers to
>> notify the client the existence of third-party resources while the
>> request is processed by an upstream server. It can also be used as an
>> alternative to H2 push on a bandwidth-constrained network.
>> In short, I consider the proposed method as a good complement to H2 push.
>> Please let me know what you think. Thank you in advance.
>> ---------- Forwarded message ----------
>> From:  <>
>> Date: 2016-10-31 23:09 GMT+09:00
>> Subject: New Version Notification for
>> draft-kazuho-early-hints-status-code-00.txt
>> To: Kazuho Oku <>
>> A new version of I-D, draft-kazuho-early-hints-status-code-00.txt
>> has been successfully submitted by Kazuho Oku and posted to the
>> IETF repository.
>> Name:           draft-kazuho-early-hints-status-code
>> Revision:       00
>> Title:          An HTTP Status Code for Indicating Hints
>> Document date:  2016-10-31
>> Group:          Individual Submission
>> Pages:          4
>> URL:
>> Status:
>> Htmlized:
>> Abstract:
>>   This memo introduces an informational status code for HTTP that can
>>   be used for indicating hints to help a client start making
>>   preparations for processing the final response.
>> Please note that it may take a couple of minutes from the time of submission
>> until the htmlized version and diff are available at
>> The IETF Secretariat
>> --
>> Kazuho Oku
> --
> Mark Nottingham

Kazuho Oku