An HTTP Status Code for Indicating Hints
draft-ietf-httpbis-early-hints-05

[Ballot comment]
Switching to Yes, as promised in my Discuss, which was:

I'll be a Yes after you help me figure this out, so this really is a request for Discussion ...

In this text,

    HTTP/1.1 103 Early Hints
    Link: ; rel=preload; as=style
    Link: ; 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: ; rel=preload; as=style
    Link: ; rel=preload; as=script
   
I see that the preload Links appear in both the 103 response and the 200 response.

(1) I'm not sure why that makes sense (HTTP still requires reliable transport, no?), but

(2) more Discuss-worthy is that I'm not sure where the question of whether to include the Early Hinted header fields is addressed.

Probably related, but since I can't figure out the answer to (2), I'm confused about this, also - I'm assuming that the 200 response could have additional Links that weren't included in the 103 response, but I don't see that written down anywhere.

If this is an appeal to "be liberal in what you accept", that's an answer (and I'd clear if it is), but I wonder if it is helpful to the implementer to make this clearer than it was to me.

Previous comments:

I have the same question that Mirja has, about Early Hints being a (possibly unintentional) amplification attack. I'm watching that conversation, but I suspect that one answer that I haven't seen go past yet, would be that clients know whether they have the resources to accept Early Hints; if they do, preloading resources that won't be used is wasteful but OK, while if they don't, they wouldn't be preloading resources anyway. If that's not true, I'd like to hear more.

I have the same question Adam has, about how the server knows the client supports 103. I'll watch that conversation.

[Ballot comment]
-2, example: (Related to Spencer's first comment): If the 103 links are required to also be in the 200 response, please state that explicitly somewhere.

An example with multiple 103s might be helpful.

- Note to Readers: I assume you intend this to be removed? if so, please do so or add a note to the RFC editor to do so.

[Ballot discuss]
I'll be a Yes after you help me figure this out, so this really is a request for Discussion ...

In this text,

    HTTP/1.1 103 Early Hints
    Link: ; rel=preload; as=style
    Link: ; 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: ; rel=preload; as=style
    Link: ; rel=preload; as=script
   
I see that the preload Links appear in both the 103 response and the 200 response.

(1) I'm not sure why that makes sense (HTTP still requires reliable transport, no?), but

(2) more Discuss-worthy is that I'm not sure where the question of whether to include the Early Hinted header fields is addressed.

Probably related, but since I can't figure out the answer to (2), I'm confused about this, also - I'm assuming that the 200 response could have additional Links that weren't included in the 103 response, but I don't see that written down anywhere.

If this is an appeal to "be liberal in what you accept", that's an answer (and I'd clear if it is), but I wonder if it is helpful to the implementer to make this clearer than it was to me.

[Ballot comment]
I have the same question that Mirja has, about Early Hints being a (possibly unintentional) amplification attack. I'm watching that conversation, but I suspect that one answer that I haven't seen go past yet, would be that clients know whether they have the resources to accept Early Hints; if they do, preloading resources that won't be used is wasteful but OK, while if they don't, they wouldn't be preloading resources anyway. If that's not true, I'd like to hear more.

I have the same question Adam has, about how the server knows the client supports 103. I'll watch that conversation.

[Ballot comment]
The document contains the following text: "a server might refrain from sending Early Hints over HTTP/1.1 unless the client is known to handle informational responses correctly."  This supposition does not indicate how a server might know this, and therefore implies that servers should engage in user-agent sniffing for guessing feature support. User-agent string sniffing is a well-known anti-pattern, and not one that we should be encouraging.

My recommendation would be inserting an indication in the request to indicate client support of the 103 status code, which would serve the dual purpose of avoiding the issues discussed in the Security section as well as not taking up unnecessary bandwidth for the 103 itself when its contents will go unused.

[Ballot comment]
I don't understand this text:
"  HTTP/2 ([RFC7540]) server push can be used as a solution to this
  issue, but has its own limitations.  The responses that can be pushed
  using HTTP/2 are limited to those belonging to the same origin.
"

Isn't this also a limitation of 103?

Also, the HTTP spec says
"The server MUST include a value in the :authority pseudo-header field for which the server is authoritative (see Section 10.1). A client MUST treat a PUSH_PROMISE for which the server is not authoritative as a stream error (Section 5.4.2) of type PROTOCOL_ERROR."

So I'm not sure that this restriction is correctly described

[Ballot comment]
I don't understand this text:
"  HTTP/2 ([RFC7540]) server push can be used as a solution to this
  issue, but has its own limitations.  The responses that can be pushed
  using HTTP/2 are limited to those belonging to the same origin.
"

Isn't this also a limitation of 103?

[Ballot comment]
One minor comment:
Not sure if this should be part of the security consideration but isn't there also a higher risk of loading resources unnecessarily if the finale response turns out to not need these resources? Could that be even used somehow as an attack?

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has completed its review of draft-ietf-httpbis-early-hints-03.txt. If any part of this review is inaccurate, please let us know.

The IANA Services Operator understands that, upon approval of this document, there is a single action which we must complete.

In the HTTP Status Code registry on the Hypertext Transfer Protocol (HTTP) Status Code Registry page located at:

https://www.iana.org/assignments/http-status-codes/

a single, new status code is to be registered as follows:

Value: 103
Description: Early Hints
Reference: [ RFC-to-be ]

The IANA Services Operator understands that this is the only action required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.


Thank you,

Sabrina Tanamal
IANA Services Specialist
PTI

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC: httpbis-chairs@ietf.org, Mark Nottingham , mnot@mnot.net, draft-ietf-httpbis-early-hints@ietf.org, ietf-http-wg@w3.org, alexey.melnikov@isode.com
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (An HTTP Status Code for Indicating Hints) to Experimental RFC


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'
  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
ietf@ietf.org mailing lists by 2017-07-05. Exceptionally, comments may be
sent to iesg@ietf.org 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 (ietf-http-wg@w3.org), 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.

# Shepherd Writeup for draft-ietf-httpbis-early-hints

## 1. Summary

Mark Nottingham is the document shepherd. Alexey Melnikov is the responsible Area Director.

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.

The Working Group has chosen Experimental to get deployment experience with this extension.


## 2. Review and Consensus

This draft has enjoyed broad review from the Working Group, and a number of parties have expressed an intent to implement, or have already started.


## 3. Intellectual Property

The author has stated that their direct, personal knowledge of any IPR related to this document has already been disclosed, in conformance with BCPs 78 and 79.


## 4. Other Points

N/A