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

Mark Nottingham <mnot@mnot.net> Mon, 07 November 2016 07:46 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 C8626129CDC for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sun, 6 Nov 2016 23:46:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.398
X-Spam-Level:
X-Spam-Status: No, score=-8.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-0.001, SPF_PASS=-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 61JdDzISxN-G for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sun, 6 Nov 2016 23:46:23 -0800 (PST)
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 13699129CB1 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Sun, 6 Nov 2016 23:46:22 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1c3eYf-0000yB-NZ for ietf-http-wg-dist@listhub.w3.org; Mon, 07 Nov 2016 07:41:33 +0000
Resent-Date: Mon, 07 Nov 2016 07:41:33 +0000
Resent-Message-Id: <E1c3eYf-0000yB-NZ@frink.w3.org>
Received: from mimas.w3.org ([128.30.52.79]) by frink.w3.org with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <mnot@mnot.net>) id 1c3eYZ-0000xQ-9O for ietf-http-wg@listhub.w3.org; Mon, 07 Nov 2016 07:41:27 +0000
Received: from mxout-07.mxes.net ([216.86.168.182]) by mimas.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <mnot@mnot.net>) id 1c3eYT-0003W3-4n for ietf-http-wg@w3.org; Mon, 07 Nov 2016 07:41:22 +0000
Received: from [192.168.3.104] (unknown [124.189.98.244]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id AA55022E1F3; Mon, 7 Nov 2016 02:40:57 -0500 (EST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\))
From: Mark Nottingham <mnot@mnot.net>
In-Reply-To: <CANatvzwm_T-HW0yT1MAWEUrfw5OAVkmAZe890575qg8HuU9Z_Q@mail.gmail.com>
Date: Mon, 7 Nov 2016 18:40:54 +1100
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <3134DBCF-A038-4B11-B457-8126ECD22920@mnot.net>
References: <147792294052.32397.15544665152412530374.idtracker@ietfa.amsl.com> <CANatvzwm_T-HW0yT1MAWEUrfw5OAVkmAZe890575qg8HuU9Z_Q@mail.gmail.com>
To: Kazuho Oku <kazuhooku@gmail.com>
X-Mailer: Apple Mail (2.3251)
Received-SPF: pass client-ip=216.86.168.182; envelope-from=mnot@mnot.net; helo=mxout-07.mxes.net
X-W3C-Hub-Spam-Status: No, score=-8.1
X-W3C-Hub-Spam-Report: AWL=1.498, BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_DB=-1, W3C_IRA=-1, W3C_IRR=-3, W3C_WL=-1
X-W3C-Scan-Sig: mimas.w3.org 1c3eYT-0003W3-4n 037241d7c9adff6f3737df905e856f62
X-Original-To: ietf-http-wg@w3.org
Subject: Re: New Version Notification for draft-kazuho-early-hints-status-code-00.txt
Archived-At: <http://www.w3.org/mid/3134DBCF-A038-4B11-B457-8126ECD22920@mnot.net>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/32849
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>

[ 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.

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/



> On 1 Nov. 2016, at 1:25 am, Kazuho Oku <kazuhooku@gmail.com> wrote:
> 
> Hi,
> 
> I've just posted a new I-D named "An HTTP Status Code for Indicating Hints".
> 
> The draft can be found at
> https://datatracker.ietf.org/doc/draft-kazuho-early-hints-status-code/
> A prettified editor's copy can be found at https://kazuho.github.io/early-hints/
> 
> 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:  <internet-drafts@ietf.org>
> 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 <kazuhooku@gmail.com>
> 
> 
> 
> 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:
> https://www.ietf.org/internet-drafts/draft-kazuho-early-hints-status-code-00.txt
> Status:
> https://datatracker.ietf.org/doc/draft-kazuho-early-hints-status-code/
> Htmlized:
> https://tools.ietf.org/html/draft-kazuho-early-hints-status-code-00
> 
> 
> 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 tools.ietf.org.
> 
> The IETF Secretariat
> 
> 
> 
> -- 
> Kazuho Oku
> 

--
Mark Nottingham   https://www.mnot.net/