Subject: Early Hints (103)

From: Patrick McManus <[email-masked]>
Date: Tue, 22 Nov 2016 17:26:39 -0500

Dear Gentlefolk of HTTPbis,

This is a followup to Kazuho's presentation in Seoul[*] where he discussed
https://datatracker.ietf.org/doc/draft-kazuho-early-hints-status-code/

The idea seemed to have acceptance (both in the room and on the list) with
some concerns expressed about interoperability. Kazuho was kind enough to
publish an endpoint so you can test if the client you implement has an
unexpected failure in the face of 103.

However, the draft was published pretty close to meeting time and there
wasn't much space for discussion in the room. So before we do a Call For
Adoption, I would like to hear some more discussion so the chairs can be
confident there is interest - even if that discussion is "I would like to
implement that" or "what does that accomplish?". Please do chime in, your
silence will be taken for disinterest otherwise :).

-Patrick

[*]
http://recs.conf.meetecho.com/Playout/watch.jsp?recording=IETF97_HTTPBIS&chapter=chapter_1
goto 1:43 mark

---

From: Julian Reschke <[email-masked]>
Date: Wed, 23 Nov 2016 10:08:43 +0100

On 2016-11-22 23:26, Patrick McManus wrote:
> The idea seemed to have acceptance (both in the room and on the list)
> with some concerns expressed about interoperability. Kazuho was kind
> enough to publish an endpoint so you can test if the client you
> implement has an unexpected failure in the face of 103.

...and the endpoint is <https://nghttp2.org/?103-eh>.

> confident there is interest - even if that discussion is "I would like
> to implement that" or "what does that accomplish?". Please do chime in,
> your silence will be taken for disinterest otherwise :).

I would like to work on improving implementations so that they can 
actually use it.

I think it's great to work on 103, and while doing that also improve the 
situation for 1xx in general. I already saw somebody else saying that 
they're looking into using RFC 2518's 102 Processing status as well 
(different use case, but same protocol level).

Best regards, Julian

---

From: Stefan Eissing <[email-masked]>
Date: Wed, 23 Nov 2016 10:15:56 +0100

Thanks Patrick,

> Am 22.11.2016 um 23:26 schrieb Patrick McManus <[email-masked]>:
> 
> This is a followup to Kazuho's presentation in Seoul[*] where he discussed https://datatracker.ietf.org/doc/draft-kazuho-early-hints-status-code/
> 
> The idea seemed to have acceptance (both in the room and on the list) with some concerns expressed about interoperability. Kazuho was kind enough to publish an endpoint so you can test if the client you implement has an unexpected failure in the face of 103.
> 
> However, the draft was published pretty close to meeting time and there wasn't much space for discussion in the room. So before we do a Call For Adoption, I would like to hear some more discussion so the chairs can be confident there is interest - even if that discussion is "I would like to implement that" or "what does that accomplish?". Please do chime in, your silence will be taken for disinterest otherwise :).

I have released support for 103 in mod_http2 in the standalone github v1.8.0 and plan to include same code in the next Apache httpd release (mod_http2 being an experimental part makes that easy). 103 is, so far, only used over HTTP/2 connections there. I am waiting for some consensus to arrive on how to make best use of it over HTTP/1.1 (other than proprietary tweaks in reverse proxy/backend setups), if at all.

103 allows signalling of PUSH options by the backend way earlier than before (in connection time) and its implementation is very straightforward.

-Stefan

---

From: Stefan Eissing <[email-masked]>
Date: Wed, 23 Nov 2016 19:07:17 +0100

> Am 23.11.2016 um 10:15 schrieb Stefan Eissing <[email-masked]>:
> 
> Thanks Patrick,
> 

Not to be mistaken, 103 on HTTP/2 connections will be disabled by default, as some html-rendering clients report ERR_SPDY_PROTOCOL_ERROR...

:-S

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 24 Nov 2016 10:48:54 +0900

Thank you Patrick,

> unexpected failure in the face of 103.
FWIW the endpoint was created by Tatsuhiko (the owner of nghttp2).

Regarding myself, we plan to add experimental support for sending 103
downstream to H2O, much the same way as mod_http2.

> [*] http://recs.conf.meetecho.com/Playout/watch.jsp?recording=
> IETF97_HTTPBIS&chapter=chapter_1 goto 1:43 mark
>

-- 
Kazuho Oku

---

From: Martin J. Dürst <[email-masked]>
Date: Thu, 24 Nov 2016 18:22:04 +0900

On 2016/11/23 07:26, Patrick McManus wrote:
> some concerns expressed about interoperability.

With the help of others (Cory Benfield, Matthew Kerwin, Yui NARUSE, 
Tomoyuki Chikanaga, Usaku NAKAMURA), I have worked to make sure 103 
doesn't cause problems in the Net::HTTP Ruby client library.
Please see https://bugs.ruby-lang.org/issues/12890 for details.

The trunk (to become Ruby 2.4), 2.3, and 2.2 are already fixed, but of 
course it will take some time for these fixes to be widely used.

If there are any other things that you think are needed to address this 
problem in Ruby, please let me know.

Regards,   Martin.

> Kazuho was kind enough to

-- 
Prof. Dr.sc. Martin J. Dürst
Department of Intelligent Information Technology
College of Science and Engineering
Aoyama Gakuin University
Fuchinobe 5-1-10, Chuo-ku, Sagamihara
252-5258 Japan

---

From: Cory Benfield <[email-masked]>
Date: Thu, 24 Nov 2016 17:05:10 +0000

> On 22 Nov 2016, at 22:26, Patrick McManus <[email-masked]> wrote:
> 

I have no immediate intent to implement, but this is only due to limitations or constraints on the clients and servers I work on. I doubt any of my clients will implement Link header following directly because it’s of limited utility in programmatic clients. However, I intend for all my clients to tolerate such headers. On the server side the server I work on most right now has no support for returning headers before body computation, but I will investigate whether there is interest in providing such support. If there is, I will implement 103.

At a higher level, I’m +1 on this idea: I think it’s a good solution that uses established protocol tools to solve a very real problem.

Cory

---

From: Daurnimator <[email-masked]>
Date: Fri, 25 Nov 2016 13:02:55 +1100

> http://recs.conf.meetecho.com/Playout/watch.jsp?recording=IETF97_HTTPBIS&chapter=chapter_1

I really like the idea of this!

I've made a small preparatory change in lua-http for the code, but
haven't committed the full support yet.
I will wait until code (103) is registered on the IANA list before doing so.

It does give me ideas for a nice ':early_hints()' method that will
work in both http1 and http2 (where it would be a push_promise).

---

From: Mike Bishop <[email-masked]>
Date: Wed, 30 Nov 2016 19:41:05 +0000

Strongly support.  It’s useful and exactly what this class of responses was intended for.  Let’s do it – and fix the bugs we flush out at the same time.

From: Patrick McManus [mailto:[email-masked]]
Sent: Tuesday, November 22, 2016 2:27 PM
To: HTTP Working Group <[email-masked]>
Subject: Early Hints (103)

-Patrick
[*] http://recs.conf.meetecho.com/Playout/watch.jsp?recording=IETF97_HTTPBIS&chapter=chapter_1 goto 1:43 mark

---

From: Göran Eriksson AP <[email-masked]>
Date: Wed, 30 Nov 2016 19:55:39 +0000

On 2016-11-30, 20:41, "Mike Bishop" <[email-masked]<mailto:[email-masked]>> wrote:

+1! This mechanism complement other stuff well, especially if we can get an appropriate Web API surface.  Will that be looked into as well?