Subject: Eric Rescorla's No Objection on draft-ietf-httpbis-early-hints-04: (with COMMENT)

From: Eric Rescorla <[email-masked]>
Date: Tue, 01 Aug 2017 14:50:09 -0700

Eric Rescorla has entered the following ballot position for
draft-ietf-httpbis-early-hints-04: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-httpbis-early-hints/

----------------------------------------------------------------------
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?

---

From: Martin Thomson <[email-masked]>
Date: Wed, 2 Aug 2017 10:31:55 +1000

> Isn't this also a limitation of 103?

Yes.  The claim about h2 is also incorrect:

   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.

-- https://tools.ietf.org/html/rfc7540#section-8.2

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 2 Aug 2017 05:15:34 +0200

On Wed, Aug 02, 2017 at 10:31:55AM +1000, Martin Thomson wrote:
> Yes.

Hmmm no, these are hints containing Link header fields, so they can
reference any object including external ones just as if they were
delivered in the final response or in the HTML header.

>  The claim about h2 is also incorrect:
> 

Indeed, nice catch! While functionally speaking it's almost the same,
it would be better to place correct claims in the summary :-)

Willy

---

From: Martin Thomson <[email-masked]>
Date: Wed, 2 Aug 2017 15:03:53 +1000

> delivered in the final response or in the HTML header.

Oh, the claim is about the resources that can be referenced, which
could be anywhere, for which I agree.  The comparison with server push
is questionable given that server push can deliver resources in
addition to the identifier.

Part of my confusion was that "this issue" has become a little muddy
after 4 paragraphs.  I would instead say:

"""
HTTP/2 server push [ref] can accelerate the delivery of resources, but
only resources for which the server is authoritative.  Delivering Link
header fields in a more timely fashion is more flexible and it allows
clients to learn about resources they might like to load more quickly.
"""

Or something like that.

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 2 Aug 2017 07:15:21 +0200

> addition to the identifier.

Indeed. Maybe it should be presented like a complement and not an
alternative. Some sites might want to continue to deliver very small
resources using PUSH and larger ones using 103 for example (so that
clients can cache them and in order to avoid wasting bandwidth).

> clients to learn about resources they might like to load more quickly.

Yes probably something like this would be better.

Willy

---

From: Kazuho Oku <[email-masked]>
Date: Fri, 4 Aug 2017 12:49:13 +0900

Eric, Martin, Willy, thank you for your suggestions.

I agree that the original text was incorrect in the limitation of what
can be pushed, and also that the text was confusing.

I've filed a PR (https://github.com/httpwg/http-extensions/pull/375)
that tries to address the issue, based on Martin's suggestions (thank
you for the text!).

Please let me know what you think.

-- 
Kazuho Oku

---

From: Willy Tarreau <[email-masked]>
Date: Fri, 4 Aug 2017 06:01:24 +0200

Hi Kazuho,

> Please let me know what you think.

I'd reformulate this part :

  "especially if a client is associated with a large amount of cache storage."

more like this :

  "especially if for clients equipped with caching."

Otherwise it makes one think that Link header consumes a large amount of
space while it's 1) not true and 2) only a hint so it solely depends on
what the client does.

Willy

---

From: Martin Thomson <[email-masked]>
Date: Fri, 4 Aug 2017 14:08:59 +1000

> space while it's 1) not true and 2) only a hint so it solely depends on

I think that Willy's suggestion is good.  I'm also not sure about "and
consumes less bandwidth", which is only true in the case where the
client doesn't want the resource.

---

From: Willy Tarreau <[email-masked]>
Date: Fri, 4 Aug 2017 06:27:05 +0200

> client doesn't want the resource.

Let's use "and may consume less bandwith", which is true when it can retrieve
the objects from a cache :-)

willy

---

From: Kazuho Oku <[email-masked]>
Date: Fri, 4 Aug 2017 13:30:33 +0900

> the objects from a cache :-)

Martin, Willy,

Thank you for your suggestions.

Updated the text to "might consume less bandwidth" to avoid confusion
(and to avoid lower-case "may").

-- 
Kazuho Oku