Subject: Last Call: <draft-ietf-httpbis-early-hints-03.txt> (An HTTP Status Code for Indicating Hints) to Experimental RFC

From: The IESG <[email-masked]>
Date: Wed, 21 Jun 2017 09:59:32 -0700

The IESG has received a request from the Hypertext Transfer Protocol WG
(httpbis) to consider the following document: - 'An HTTP Status Code for
Indicating Hints'
  <draft-ietf-httpbis-early-hints-03.txt> as Experimental RFC

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
[email-masked] mailing lists by 2017-07-05. Exceptionally, comments may be
sent to [email-masked] instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract

   This memo introduces an informational HTTP status code that can be
   used to convey hints that help a client make preparations for
   processing the final response.

Note to Readers

   Discussion of this draft takes place on the HTTP working group
   mailing list ([email-masked]), which is archived at
   https://lists.w3.org/Archives/Public/ietf-http-wg/ .

   Working Group information can be found at https://httpwg.github.io/ ;
   source code and issues list for this draft can be found at
   https://github.com/httpwg/http-extensions/labels/early-hints .

The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-httpbis-early-hints/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-httpbis-early-hints/ballot/

No IPR declarations have been submitted directly on this I-D.

---

From: Julian Reschke <[email-masked]>
Date: Sun, 25 Jun 2017 12:11:29 +0200

On 2017-06-21 18:59, The IESG wrote:
> ...

Here's my feedback...:

2.  103 Early Hints

    ...

    A server MUST NOT include Content-Length, Transfer-Encoding, or any
    hop-by-hop header fields ([RFC7230], Section 6.1) in a 103 (Early
    Hints) response.

That's a bit weird here, because the requirements for C-L and T-E are 
generic to 1xx, and already are stated in RFC 7230. The text above makes 
it sound as if these are specific to 103, which they are not.

For hop-by-hop, I'm not convinced that the requirement is needed here.

    ...

    An intermediary MAY drop the informational response. (...)

That seems to contradict a MUST-level requirement in RFC 7231 
(https://www.greenbytes.de/tech/webdav/rfc7231.html#rfc.section.6.2.p.3)

    The following example illustrates a typical message exchange that
    involves a 103 (Early Hints) response.

    Client request:

      GET / HTTP/1.1
      Host: example.com

(maybe insert blank line do delimit the message)

    Server response:

      HTTP/1.1 103 Early Hints
      Link: </style.css>; rel=preload; as=style
      Link: </script.js>; rel=preload; as=script

      HTTP/1.1 200 OK
      Date: Fri, 26 May 2017 10:02:11 GMT
      Content-Length: 1234
      Content-Type: text/html; charset=utf-8
      Link: </style.css>; rel=preload; as=style
      Link: </script.js>; rel=preload; as=script

      <!doctype html>
      [... rest of the response body is ommitted from the example ...]

The example suggests that early hints are repeated in the final 
response. Do they have to, actually?

3.  Security Considerations

    Some clients might have issues handling 103 (Early Hints), since
    informational responses are rarely used in reply to requests not
    including an Expect header ([RFC7231], Section 5.1.1).

s/header/header field/

    In particular, an HTTP/1.1 client that mishandles an informational
    response as a final response is likely to consider all responses to
    the succeeding requests sent over the same connection to be part of
    the final response.  Such behavior may constitute a cross-origin

s/may/might/ or /can/ (or invoke https://tools.ietf.org/html/rfc8174)

    information disclosure vulnerability in case the client multiplexes
    requests to different origins onto a single persistent connection.

    ...

5.  Acknowledgements

Nit: This should be an appendix (the last one).

6.  Changes

Nit: This should be an appendix.

Best regards, Julian

---

From: Willy Tarreau <[email-masked]>
Date: Sun, 25 Jun 2017 12:46:29 +0200

Hi Julian,

> (https://www.greenbytes.de/tech/webdav/rfc7231.html#rfc.section.6.2.p.3)

Not completely. An intermediary not aware of 103 may map it to 100. If
the intermediary inserted an "Expect: 100 continue" header field, we
can reasonably imagine that such an intermediary might also drop the
returning 103. This wording in 7231 may even encourage some implementations
to do so : "A proxy MUST forward 1xx responses unless the proxy itself
requested the generation of the 1xx response". Speaking about 1xx here
may be read as "I asked for 100, I'm receiving 1xx so that matches".

> The example suggests that early hints are repeated in the final response. Do
> they have to, actually?

If we imagine that clients ignore 103 or that intermediaries occasionally
drop it, I think it's desirable to send them. Said differently, the 103
response prepends a copy of the Link header fields that the final response
is supposed to present to help the client fetch them earlier.

Regards,
Willy

---

From: Julian Reschke <[email-masked]>
Date: Sun, 25 Jun 2017 12:50:30 +0200

> Not completely. An intermediary not aware of 103 may map it to 100. If

It may do so, but it's not allowed to (IMHO).

> may be read as "I asked for 100, I'm receiving 1xx so that matches".

But that sounds like a bug in the proxy to me. A 103 is not a 100.

> is supposed to present to help the client fetch them earlier.

Understood. But is this a requirement or just a suggestion? Does a 
client need to forget the information from the 103 when it's not 
repeated in the final response?

Best regards, Julian

---

From: Willy Tarreau <[email-masked]>
Date: Sun, 25 Jun 2017 13:28:42 +0200

> It may do so, but it's not allowed to (IMHO).

I agree with you but there's probably a difference with what is really
deployed in field. However I'm now seeing a wording issue here, because
saying "An intermediary MAY drop the informational response" suggests
to intermediary implementations that this is permitted. I think that
using just a warning for server implementations would be more appropriate,
like "A server should be prepared to see its 103 responses silently dropped
or altered by some non-compliant intermediaries".

> But that sounds like a bug in the proxy to me. A 103 is not a 100.

Sure, but it's also suggested that when processing a code XYY that you
don't know, you can consider that it will act like X00. I'm not
justifying that some might be doing this, just that we need the spec to
be robust against such bogus behavious *if they exist*. Especially
interim responses, which have always been tricky to get right
everywhere :-/

> Understood. But is this a requirement or just a suggestion? Does a client
> need to forget the information from the 103 when it's not repeated in the
> final response?

Hmmm the text says :
  "This memo defines a status code for sending an informational response
   ([RFC7231], Section 6.2) that contains header fields that are likely
   to be included in the final response"

Thus I think that the final header fields are the real ones, and that
those sent early are more about hints to help the client get mostly
prepared. Can there be a conflict between two overlapping header field
values for the same link ? If so, some text needs to be appended to
mandate that the final response the the only authoritative one and that
the interim ones are only here to help fill silence periods on the link.

Willy

---

From: Julian Reschke <[email-masked]>
Date: Sun, 25 Jun 2017 13:36:59 +0200

> or altered by some non-compliant intermediaries".

Yup.

> don't know, you can consider that it will act like X00. I'm not

I wouldn't consider that a license to *change* the code though.

> interim responses, which have always been tricky to get right

True, but we shouldn't confuse normative language (which simply can't be 
in conflict with the base spec without additional work) from implementor 
guidance.

> ... >> Understood. But is this a requirement or just a suggestion? Does a 
client
> the interim ones are only here to help fill silence periods on the link.

I'm interested in the case where the Link appears in the 103 but not in 
the final response...

Best regards, Julian

---

From: Willy Tarreau <[email-masked]>
Date: Sun, 25 Jun 2017 13:53:15 +0200

On Sun, Jun 25, 2017 at 01:36:59PM +0200, Julian Reschke wrote:
> I'm interested in the case where the Link appears in the 103 but not in the
> final response...

I think it will be very common, because I see a cool opportunity here for
edge gateways to send a few links regardless of what the origin server thinks
about this. I'm even considering implementing this capability into haproxy
because I think it can bring some value. So if this is going to have side
effects, it would be nice that they are properly estimated.

Willy

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 26 Jun 2017 11:39:23 +0900

Hi Julian,

Thank you very much for your comments.

I will create a PR fixing the editorial issues. For the other issues,
my responses in-line.

2017-06-25 19:11 GMT+09:00 Julian Reschke <[email-masked]>:
> generic to 1xx, and already are stated in RFC 7230. The text above makes it
> sound as if these are specific to 103, which they are not.
>

I agree that we do not need to talk about C-L and T-E here.

The reasons I added a clause prohibiting the use of hop-by-hop headers
in an 103 response are as follows:
* does not make sense for a response that attempts to send the
metadata of a final response early
* to avoid confusion caused by sending a hop-by-hop header in the 103 response

Without the restriction, a response like below would be valid, which
IMO is confusing at least.

```
HTTP/1.1 103 Early Hints
Connection: close
Link: </style.css>; rel=preload

HTTP/1.1 200 OK
Connection: close
Link: </style.css>; rel=preload
...
```

> (https://www.greenbytes.de/tech/webdav/rfc7231.html#rfc.section.6.2.p.3)

The statement exists since sending 103 only makes sense when it is
impossible to immediately send a final response.

For example, there is no need for a cache that is in possession of a
freshly-cached final response to send a 103 that was sent from the
origin before sending the final response. I also believe that most
caching proxies that exist today do not cache informational responses,
and that there is no need for us to require them to do so.

Considering the facts, one way to resolve the issue would be to adjust
the statement to something like "An intermediary MAY omit the 103
response when resending a cached response", and argue that re-sending
a cached response is not an action of "forwarding," which is defined
as a MUST in RFC 7231.

But wouldn't it be simpler to just have the "MAY drop" clause for any
intermediary?

> The example suggests that early hints are repeated in the final response. Do

Yes. They need to, especially if caching is involved. 103 is an
intermediary response and there is no guarantee (or a requirement) for
a cache to retain the headers included only in the informational
response.

In case of link rel=preload headers, a client can speculatively load
the resources included in the headers while revalidating a
stale-cached response, or a caching proxy can generate a 103 response
from a stale-cached 200 response, while waiting for the origin to
perform revalidation.

-- 
Kazuho Oku

---

From: Julian Reschke <[email-masked]>
Date: Mon, 26 Jun 2017 12:36:36 +0200

> Link: </style.css>; rel=preload

Yes, but does that mean we need a normative requirement? Also, is it 
really obvious that no future hop-by-hop header field could be 
meaningful on a 103?

> a cached response is not an action of "forwarding," which is defined

Sounds good to me.

> But wouldn't it be simpler to just have the "MAY drop" clause for any

In that case, the spec would contradict RFC 7231, which is bad position 
to be in...

> from a stale-cached 200 response, while waiting for the origin to

What I'm after is a clear statement whether they really need to be 
repeated, as normative language.

Best regards, Julian

---

From: Yoav Weiss <[email-masked]>
Date: Mon, 26 Jun 2017 15:58:32 +0000

An issue <https://github.com/w3c/preload/issues/101> raised by Mike West
(CCed) got me thinking if Early Hints are at all implementable at the
browser level (rather than just used as early push hints at the CDN level).

Currently, at least in Chromium and WebKit, requests triggered by preload
links are not sent until the document is committed, which means that they
are not sent immediately when the browser processes them. That's likely to
be a short, internal delay.
However, in the context of Early Hints, that delay can be significant, as
it can take hundreds of milliseconds for the renderer process to get
created. At the same time, a lot of the logic required to send those
requests out sits in the rendering engine.

I'm not sure what is the solution to bridge that gap, if one exists.

Cheers,
Yoav

---

From: Julian Reschke <[email-masked]>
Date: Mon, 26 Jun 2017 18:08:57 +0200

On 2017-06-26 17:58, Yoav Weiss wrote:
> Currently, at least in Chromium and WebKit, requests triggered by 
> preload links are not sent until the document is committed, which means 
> that they are not sent immediately when the browser processes them. 
> That's likely to be a short, internal delay.
> However, in the context of Early Hints, that delay can be significant, 
> as it can take hundreds of milliseconds for the renderer process to get 

As the IETF HTTP WG, we can specify the bits on the wire that *allow* a 
client to start fetching things earlier.

*How* the client does that is an implementation detail of the client. If 
I understand the issue correctly, *any* mechanism that would send 
"early" information would have the same problem, right?

Best regards, Julian

---

From: Yoav Weiss <[email-masked]>
Date: Mon, 26 Jun 2017 16:31:27 +0000

> client to start fetching things earlier.

I agree. The CDN use case is probably still a viable one, regardless of
this issue.

>
> *How* the client does that is an implementation detail of the client.

This is not a question of *how* but potentially a question *if* it's at all
possible to do so for a pretty significant set of clients.

> If I understand the issue correctly, *any* mechanism that would send

Indeed. The issue is similar with any API or syntax that would be destined
to trigger requests from the rendering engine before it is created and the
document is committed.

---

From: Alex Rousskov <[email-masked]>
Date: Mon, 26 Jun 2017 10:40:48 -0600

>>> For hop-by-hop, I'm not convinced that the requirement is needed here.

Prohibiting hop-by-hop fields is not only unneeded, it is harmful.

>> metadata of a final response early

Those hop-by-hop headers may have nothing to do with the 103 purpose
itself. They may make sense for authentication, tracking, logging, and
many other reasons specific to the deployment environment. As an extreme
example, consider a client that rejects all responses unless they have a
X-Hop-ID hop-by-hop header field. There is no reason to preclude such
client from using the new 103 feature!

>> * to avoid confusion caused by sending a hop-by-hop header in the 103

Adding unrelated restrictions creates even more confusion and bugs. Yes,
hop-by-hop headers can be misused, but early hints is not about
combating all world evils. A new protocol feature should not affect
standard behaviors unless such changes are absolutely necessary for that
feature functionality. If correct usage of some hop-by-hop headers does
not hurt early responses, then we should not prohibit all hop-by-hop
headers.

>> Link: </style.css>; rel=preload

The same can be said about 100 Continue and other 1xx responses. The
early response feature is not the place to address this confusion.

>> impossible to immediately send a final response.

The "only" part of that assertion is too restrictive AFAICT. I can
imagine situations where sending 103 immediately before the final
response makes sense, especially when an intermediary is generating 103s
but does not want to fiddle with final responses.

> Sounds good to me.

When a caching intermediary attempts to validate a previously cached
object and suddenly receives a 103 response, the intermediary does not
yet know whether the cached object is still valid/fresh. Thus, if we
require the intermediary to base its 103 forwarding decision on the
cached object state, such an intermediary would have to store the 103
message until the final response is received. That new storage
requirement creates a significant burden for intermediaries!

IMHO, new 1xx messages should not introduce new storage/forwarding
requirements that depend on future final response status. An old caching
proxy should not violate the new 103 specs by default.

Perhaps the proxy-initiated cache validation transaction can be
considered a transaction between the proxy and the server, with no
"forwarding" involved? In that case, the 103 response is directed at the
proxy itself, and any forwarding rules do not apply! The proxy may, at
its own discretion, generate its own 103 response to the client, of
course. That generation may look like forwarding to an outside observer,
but it is not subject to forwarding requirements.

> In that case, the spec would contradict RFC 7231, which is bad position

Agreed.

> repeated, as normative language.
 Based on the discussion, I think it should be the 103 sender decision,
not a protocol-level requirement. I can imagine cases where the final
response should omit some 103 details because the situation has changed
since that 103 was generated. The client should not be required to pay
attention to 103, and the server should not be required to duplicate 103
info.

>    A client MUST NOT interpret the 103 (Early Hints)
>    response header fields as if they applied to the informational
>    response itself

This requirement seems too broad -- a client that does not know about
103s may certainly apply the received 103 header fields to that 103
message. Yes, such a client would make an exception for Content-Length
and similar headers as already required for 1xx handling, but it seems
wrong to place _additional_ MUST-level requirements on an unsuspecting
client.

Overall, it feels like hints should be relayed using a mechanism that
does not abuse existing headers so that there is a clear separation
between the 103 message itself and the hints about the future message.
1xx responses cannot have a body, but perhaps these hints can be encoded
into a new header field? For example:

    HTTP/1.1 103 Hints
    Hints: <encoded Link and other fields here>
    Via: ...
    X-Hop-ID: ...
    Connection: X-Hop-ID

Thank you,

Alex.

---

From: Lucas Pardue <[email-masked]>
Date: Mon, 26 Jun 2017 16:47:09 +0000

Very interesting, thanks Yoav.

As an aside from the Mike’s issue, reading the W3C spec got me wondering if there is any definition of how non-browsers should handle preload. It seems like there is a guidance gap for non-browsers when, as you’ve identified, there are some clear use cases for preload. If there was some energy for writing up some standards language of this nature, would it belong to the W3C spec or would it be better placed elsewhere?

Regards
Lucas

From: Yoav Weiss [mailto:[email-masked]]
Sent: 26 June 2017 16:59
To: Julian Reschke <[email-masked]>; Kazuho Oku <[email-masked]>
Cc: [email-masked]; [email-masked]; Mark Nottingham <[email-masked]>; [email-masked]; HTTP Working Group <[email-masked]>; [email-masked]; Mike West <[email-masked]>
Subject: Re: Last Call: <draft-ietf-httpbis-early-hints-03.txt> (An HTTP Status Code for Indicating Hints) to Experimental RFC

An issue<https://github.com/w3c/preload/issues/101> raised by Mike West (CCed) got me thinking if Early Hints are at all implementable at the browser level (rather than just used as early push hints at the CDN level).

Currently, at least in Chromium and WebKit, requests triggered by preload links are not sent until the document is committed, which means that they are not sent immediately when the browser processes them. That's likely to be a short, internal delay.
However, in the context of Early Hints, that delay can be significant, as it can take hundreds of milliseconds for the renderer process to get created. At the same time, a lot of the logic required to send those requests out sits in the rendering engine.

Cheers,
Yoav

---

From: Mike Bishop <[email-masked]>
Date: Mon, 26 Jun 2017 20:53:36 +0000

Because our layer doesn’t have access to the renderer (the issue below), we currently only pre-resolve and pre-connect, even if there’s a preload link.  It’s still a latency win, even if we have to wait on the renderer to launch the actual resource request.  We currently don’t process any headers out of intermediate responses, so there’d be work here, but that’s no different from any other new feature we want to add support for.

Sent: Monday, June 26, 2017 8:59 AM

An issue<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fw3c%2Fpreload%2Fissues%2F101&data=02%7C01%7CMichael.Bishop%40microsoft.com%7Cce7e4dd057de4f2f1d8108d4bcacb99c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636340897417469474&sdata=9JfVLHdwpHiheFgVvAJfPy8UJEptLy4eu46iYWBZSR0%3D&reserved=0> raised by Mike West (CCed) got me thinking if Early Hints are at all implementable at the browser level (rather than just used as early push hints at the CDN level).

Cheers,
Yoav

On Mon, Jun 26, 2017 at 12:41 PM Julian Reschke <[email-masked]<mailto:[email-masked]>> wrote:
On 2017-06-26 04:39, Kazuho Oku wrote:
> ...
> 2017-06-25 19:11 GMT+09:00 Julian Reschke <[email-masked]<mailto:[email-masked]>>:

>> (https://www.greenbytes.de/tech/webdav/rfc7231.html#rfc.section.6.2.p.3<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.greenbytes.de%2Ftech%2Fwebdav%2Frfc7231.html%23rfc.section.6.2.p.3&data=02%7C01%7CMichael.Bishop%40microsoft.com%7Cce7e4dd057de4f2f1d8108d4bcacb99c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636340897417469474&sdata=fJPxfSrEe9D3n6lAp0rmijnSGTaoo2yT4ZZatoBI5FY%3D&reserved=0>)
>

Sounds good to me.

>>       Host: example.com<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fexample.com&data=02%7C01%7CMichael.Bishop%40microsoft.com%7Cce7e4dd057de4f2f1d8108d4bcacb99c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636340897417479487&sdata=CPFiVF0P3XgGQS9EaLKGVBvFLkZmYTEevl2m%2BVfKGpI%3D&reserved=0>
>>

Best regards, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 27 Jun 2017 11:05:21 +1000

> On 26 Jun 2017, at 12:39 pm, Kazuho Oku <[email-masked]> wrote:

> Link: </style.css>; rel=preload

Perhaps you could just give guidance that only the headers intended as early hints should be sent?

> But wouldn't it be simpler to just have the "MAY drop" clause for any

Re-specifying HTTP for a special case isn't a good idea. I think you could mention that gateways can decide not to forward a 103 response at their discretion / depending on their configuration, but I don't know if I'd put a requirement around it. Also, see below.

As an aside -- HTTP only specifies very general requirements for gateways; by their nature, they're black boxes (the back-end protocol *can* be HTTP, but it doesn't have to be, and how they connect the two sides in that case is also unspecified). So I wouldn't go into too much detail about their operation.

> from a stale-cached 200 response, while waiting for the origin to

The underlying problem here is that the caching model doesn't talk about final and non-final responses. 

I've raised <https://github.com/httpwg/http11bis/issues/29>. I don't think that you need to specify anything about this.

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

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 27 Jun 2017 12:52:14 +0900

Hi Mark, Julian,

Thank you for your comments / suggestions.

I have created a pull request that hopefully would address the issues
being raised: https://github.com/httpwg/http-extensions/pull/363;
please let me know what you think.

The PR removes the statements that have been pointed out either as
redundant or in contradiction with RFC 723x. It also gives guidance to
servers how they should generate the 103 headers.

Regarding the action of an intermediary, I like the Mark's view
(stated in the new GitHub issue) that caches are expected to store
only final responses and that it should be clarified in the next
revision of HTTP. Considering that way, I think we do not need to
specify how a intermediary needs to deal with a 103 response (except
for the fact that a HTTP/2 gateway might create a HTTP/2 push based on
the information found in the informational response).

-- 
Kazuho Oku

---

From: Willy Tarreau <[email-masked]>
Date: Tue, 27 Jun 2017 07:29:28 +0200

>   <draft-ietf-httpbis-early-hints-03.txt> as Experimental RFC

I've just noticed that it's never mentionned that a client should be
prepared to receive multiple 103 responses as any informational response
(or at least I did not notice).

I think that indicating that multiple responses MAY be sent with complementary
and/or possibly overlapping links, it may help grasp the overall principle
and the relation between these informational responses and the final one.

The case I'm having in mind is the same as described in the PR comment, a
server-side gateway could speculatively send a 103 with a few site-specific
links while the server provides another 103 with some resource-specific
links.

Willy

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 28 Jun 2017 11:07:07 +1000

Fair enough, but I wouldn't place requirements around this; just note it as something that might happen.

> On 27 Jun 2017, at 3:29 pm, Willy Tarreau <[email-masked]> wrote:
>