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

From: Kazuho Oku <[email-masked]>
Date: Mon, 31 Oct 2016 23:25:30 +0900

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:  <[email-masked]>
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 <[email-masked]>

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

---

From: Julian Reschke <[email-masked]>
Date: Mon, 31 Oct 2016 18:00:39 +0100

> Please let me know what you think. Thank you in advance.

+1!

Best regards, Julian

---

From: Cory Benfield <[email-masked]>
Date: Mon, 31 Oct 2016 18:21:47 +0000

> On 31 Oct 2016, at 14:25, Kazuho Oku <[email-masked]> wrote:
> 

Kazuho,

This draft generally seems like a really good idea. It helps to resolve some of the substantial issues around the processing of large or high-latency responses, and as you have identified seems like it would make a good companion to HTTP/2 server push. I think this is a draft worth pursuing, and though I will not be at the next IETF meeting I look forward to seeing the progress through the IETF.

While I’m here, I’d like to discuss section 3. To provide some data points, most of the HTTP/1.1 clients in the Python ecosystem will not handle a new 1XX status code very well. A quick survey of the ecosystem suggests that the following tools will all misbehave:

- every standard library http client (urllib, urllib2, httplib), all of which treat only “100 Continue” specially: the rest will treat the 103 header block as the final response and, because it MUST NOT have a content-length, will read until connection close.
- every third-party library built on top of those tools, including urllib3, Requests, and httplib2, which inherit their misbehaviour.
- aiohttp, which special-cases 100 and 101 but not any others
- Twisted’s client, which special-cases 100

In fact, so far I haven’t found a single Python http client that would handle this response in any way that approaches sensible. I would even tolerating *ignoring* the response as a sensible behaviour, but we don’t even have that. In all cases, these clients treat the 103 response as the final response and totally lose track of their framing.

I doubt Python is unique here. While other languages may have libraries that are somewhat better at handling this situation, certainly some-to-many of them will continue to have this problem. This problem is also likely to be present throughout the long-tail of HTTP implementations: clearly it has been received wisdom by implementers that non-100 1XX status codes do not need to be supported because they will not be encountered. Worse, many of these implementations may be unable to update. Even if Python’s standard library http.client library was fixed to handle 1XX codes sensibly, the most widely-deployed version of Python (2.7) would not receive any such fix, meaning that all Python 2.7 users would be utterly confused by the receipt of a 103 status code.

This means that your suggestion that this should be negotiated is extremely important. I think it’s not “desirable” to negotiate this behaviour: I think it’ll have to be mandatory if we want to avoid screwing up a majority of long-tail HTTP/1.1 clients in the world. For HTTP/1.1, that’ll have to be negotiation by header, presumably by means of either an extension to the “Expect” header field or an equivalent header field that is inserted by analogy. For HTTP/2 this could be negotiated at the connection level by means of a settings value, or by the same header at the cost of one byte per request.

I’ll start filing bugs against relevant repositories to address this behaviour so that the Python ecosystem is less embarrassingly unprepared for further 1XX status codes, but in the short-to-medium term it would be much better if we could negotiate the 103 status code rather than assume it will function correctly.

Cory

---

From: Julian Reschke <[email-masked]>
Date: Mon, 31 Oct 2016 19:32:26 +0100

> This means that your suggestion that this should be negotiated is extremely important. I think it’s not “desirable” to negotiate this behaviour: I think it’ll have to be mandatory if we want to avo…

Or "Prefer".

> I’ll start filing bugs against relevant repositories to address this behaviour so that the Python ecosystem is less embarrassingly unprepared for further 1XX status codes, but in the short-to-mediu…

Please, by all means, *do* file bug reports.

Best regards, Julian

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 1 Nov 2016 10:32:58 +0900

> This means that your suggestion that this should be negotiated is extremely important. I think it’s not “desirable” to negotiate this behaviour: I think it’ll have to be mandatory if we want to avo…

Cory, Julian, thank you for looking into the I-D.

Thank you for looking into the existing implementations using Python.
Your research makes it evident that some kind of negotiation is
mandatory if we are going to use 103 on the public Internet.

For the purpose, defining an Accept-EH header (much like Accept-CH)
might make sense. For example, a client can send `Accept-EH: Link` to
indicate that it will recognize link headers within the Early Hints.

For HTTP/2, my tendency leans toward using HTTP headers rather than
having its own way of negotiation, considering the fact that the
information transferred using Early Hints could be considered
end-to-end rather than hop-by-hop, and also that we can expect HPACK
to compress Accept-EH header efficiently.

> I’ll start filing bugs against relevant repositories to address this behaviour so that the Python ecosystem is less embarrassingly unprepared for further 1XX status codes, but in the short-to-mediu…

Fantastic! Thank you for all your efforts.

-- 
Kazuho Oku

---

From: Julian Reschke <[email-masked]>
Date: Tue, 1 Nov 2016 07:32:01 +0100

> mandatory if we are going to use 103 on the public Internet.

Having to negotiate it makes me sad.

> indicate that it will recognize link headers within the Early Hints.

Can't we use "Prefer"?

> to compress Accept-EH header efficiently.

For HTTP/2, I think we should push stronger to fix the code and not 
negotiate at all.

Best regards, Julian