Subject: Working Group Last Call: draft-ietf-httpbis-early-hints-02

From: Mark Nottingham <[email-masked]>
Date: Thu, 18 May 2017 11:22:03 +1000

Kazuho has indicated that he thinks this draft is ready for WGLC, and we have no open issues.

Please have a look at:
  https://tools.ietf.org/html/draft-ietf-httpbis-early-hints-02
.. and raise any issues you see here or on the issues list. Statements of support / intent to implement would also be helpful.

WGLC will end in two weeks, on 1 June 2017.

Regards,

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

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 18 May 2017 11:22:02 +0900

> WGLC will end in two weeks, on 1 June 2017.

Thank you for changing the state to WGLC.

The only change that was made in the -02 draft (which was submitted on
Tuesday) is editorial improvements from Mark. I would appreciate it if
you could take a look. IMO the text is much clear and concise than
-01.

-- 
Kazuho Oku

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 18 May 2017 06:48:38 +0200

> you could take a look. IMO the text is much clear and concise than

It looks pretty good to me. I just think that one example could have been
nice (since not everybody is familiar with informational responses), to
make it visually clear that you can get one or a few 103 prior to a 200
for a single request.

I expect it to work out of the box through haproxy, and in general I intend
to make sure it will.

Regards,
Willy

---

From: Wesley Oliver <[email-masked]>
Date: Thu, 18 May 2017 07:22:58 +0200

Hi,

Bit late to the part once again.

Did any one consider, an external reference to preload resource manifest,
which just contains a list of preloaded resources.
The main difference is it is not inline, but external reference resource.
this external reference resource could then be pushed
via http 2.0 to the client, after which it can get to work. Obviously this
would not work with http 1.1 though,
so current solution proposed would be a better than this.

Kind Regards,

Wesley Oliver

On Thu, May 18, 2017 at 6:48 AM, Willy Tarreau <[email-masked]> wrote:

> > > .. and raise any issues you see here or on the issues list. Statements
> of support / intent to implement would also be helpful.
> > >

-- 
-- 
Web Site that I have developed:
http://www.swimdynamics.co.za

Skype: wezley_oliver
MSN messenger: [email-masked]

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 18 May 2017 08:13:07 +0200

> so current solution proposed would be a better than this.

I don't see any benefit in doing it like this, it would sound less flexible.
In my opinion, providing something to make HTTP/1 to generate server push
when relayed via an HTTP/2 edge is really nice. You can imagine a server-side
reverse-proxy using this to add some CSS/JS/whatever the application doesn't
have to care about, and to provide them to the client when it's done over H2.
That's just an example, but I find the current design well balanced between
efficiency and flexibility.

Regards,
Willy

---

From: Julian Reschke <[email-masked]>
Date: Fri, 19 May 2017 16:06:49 +0200

Here's my feedback (and yes, as stated elsewhere, there should be at 
least one example in the spec):

1.  Introduction

    The "preload" ([Preload]) link relation can be used to convey such
    links in the Link header field of an HTTP response.  However, it is
    not always possible for an origin server to generate a response
    header block immediately after receiving a request.  For example, the

Maybe s/generate a response header block/generate a final response/?

    The dilemma here is that even though it is preferable for an origin
    server to send some headers as soon as it receives a request, it

s/headers/header fields/ (throughout)

    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.
    Also, it is impossible to send only the links using server push.

That's not clear to me. We could HTTP/2-push a HEAD response with link 
header fields, no? Or a GET response which has links in the payload...

    This memo defines a status code for sending an informational response
    ([RFC7231], section 6.2) that contains headers that are likely to be

s/section/Section/ (throughout)

2.  103 Early Hints

    The 103 (Early Hints) informational status code indicates the client
    that the server is likely to send a final response with the headers
    included in the informational response.

maybe "indicates to the client"?

    A client MAY speculatively evaluate the headers included in a 103
    (Early Hints) response while waiting for the final response.  For
    example, a client might recognize a Link header field value
    containing the relation type "preload" and start fetching the target
    resource.

The "MAY" is a bit weird here, because that's the whole point of the new 
status code. I'd just say "can".

3.  Security Considerations

    Some clients may have issues handling 103 (Early Hints), since

s/may/might/ (avoid lowercase BCP14 keywords or invoke 
https://tools.ietf.org/html/rfc8174)

    informational responses are rarely used in reply to requests not
    including an Expect header ([RFC7231], section 5.1.1).

7.2.  Informative References

    [Preload]  Grigorik, I., "Preload", September 2016,
               <https://w3c.github.io/preload/>.

The reference is dated, but the thing referred to is not. Either cite 
the stable version or drop the date.

---

From: Willy Tarreau <[email-masked]>
Date: Fri, 19 May 2017 23:54:51 +0200

> header fields, no? Or a GET response which has links in the payload...

Indeed. Probably the wording could be relaxed, saying it's "non-trivial"
or "not straightforward" instead of "impossible".

Willy

---

From: Mike Bishop <[email-masked]>
Date: Sun, 21 May 2017 20:26:01 +0000

More fundamentally, we have this mechanism for dropping a request and its response on a client, but don't have a taxonomy of what sorts of request/response pairs clients should expect and what they should do with them.

-----Original Message-----
From: Willy Tarreau [mailto:[email-masked]] 
Sent: Friday, May 19, 2017 2:55 PM
To: Julian Reschke <[email-masked]>
Cc: Mark Nottingham <[email-masked]>; [email-masked] Group <[email-masked]>; Patrick McManus <[email-masked]>; Kazuho Oku <[email-masked]>
Subject: Re: Working Group Last Call: draft-ietf-httpbis-early-hints-02

Willy

---

From: Kazuho Oku <[email-masked]>
Date: Fri, 26 May 2017 07:00:57 +0900

Hi Julian,

Thank you very much for the suggestions. My comments in-line.

2017-05-19 23:06 GMT+09:00 Julian Reschke <[email-masked]>:
> Here's my feedback (and yes, as stated elsewhere, there should be at least
> one example in the spec):
>
>
> 1.  Introduction
>

How about https://github.com/httpwg/http-extensions/pull/353?

Including the word "final" makes sense to me. OTOH I think it might be
beneficial to retain the term "header block", to avoid readers
wondering why the solution to not being able to generate a final
response cannot be to stream the final response as you generate.

> header fields, no? Or a GET response which has links in the payload...

Does changing the last sentence of the quote to "Also, it does not
define a way to push the links only." sound reasonable to you?

The paragraph lists what cannot be done under the current state of
HTTP/2, namely: pushing a resource belonging to a different origin,
push links only, avoid resending an already cached response.

All the other suggestions seemed to me that nobody would object, hence
went directly into master in
https://github.com/httpwg/http-extensions/commit/339ac0fff9524f04e80dfc48db4f3ba3eb8963f6.

Thank you very much for your help.

> The reference is dated, but the thing referred to is not. Either cite the
> stable version or drop the date.

-- 
Kazuho Oku

---

From: Kazuho Oku <[email-masked]>
Date: Fri, 26 May 2017 10:18:33 +0900

> make it visually clear that you can get one or a few 103 prior to a 200

Hi Willy,

That sounds like a good idea!

I've created a PR adding such an example.
https://github.com/httpwg/http-extensions/pull/354

Please let me know what you think.

Thank you in advance.

-- 
Kazuho Oku

---

From: Willy Tarreau <[email-masked]>
Date: Fri, 26 May 2017 07:47:54 +0200

Hi Kazuho,

> Please let me know what you think.

This looks perfect to me.

Thanks,
Willy

---

From: Julian Reschke <[email-masked]>
Date: Fri, 26 May 2017 09:27:07 +0200

> How about https://github.com/httpwg/http-extensions/pull/353?

Looks good to me...

> define a way to push the links only." sound reasonable to you?

Yes.

> ...

You're welcome :-)

Best regards, Julian