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

[Mark Nottingham <[e-mail]>]

[ 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 <[e-mail]> 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:  <[e-mail]>
> 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 <[e-mail]>
> 
> 
> 
> 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/