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

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.

From: Yoav Weiss [mailto:yoav@yoav.ws]
Sent: Monday, June 26, 2017 8:59 AM
To: Julian Reschke <julian.reschke@gmx.de>; Kazuho Oku <kazuhooku@gmail.com>
Cc: ietf@ietf.org; httpbis-chairs@ietf.org; Mark Nottingham <mnot@mnot.net>; draft-ietf-httpbis-early-hints@ietf.org; HTTP Working Group <ietf-http-wg@w3.org>; alexey.melnikov@isode.com; Mike West <mkwst@chromium.org>
Subject: Re: Last Call: <draft-ietf-httpbis-early-hints-03.txt> (An HTTP Status Code for Indicating Hints) to Experimental RFC

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).

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

On Mon, Jun 26, 2017 at 12:41 PM Julian Reschke <julian.reschke@gmx.de<mailto:julian.reschke@gmx.de>> wrote:
On 2017-06-26 04:39, Kazuho Oku wrote:
> ...
> 2017-06-25 19:11 GMT+09:00 Julian Reschke <julian.reschke@gmx.de<mailto:julian.reschke@gmx.de>>:
>> On 2017-06-21 18:59, The IESG wrote:
>>>
>>>
>>> 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
>>> ...
>>
>>
>>
>> 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.
>
> 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
> ...
> ```

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?

>>     ...
>>
>>     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<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>)
>
> 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.

Sounds good to me.

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

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

>>     The following example illustrates a typical message exchange that
>>     involves a 103 (Early Hints) response.
>>
>>     Client request:
>>
>>       GET / HTTP/1.1
>>       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>
>>
>> (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?
>
> 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.

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

> ...

Best regards, Julian