W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2016

Re: New Version Notification for draft-kazuho-early-hints-status-code-00.txt

From: Kazuho Oku <kazuhooku@gmail.com>
Date: Thu, 3 Nov 2016 11:26:40 +0900
Message-ID: <CANatvzznarGkPNMv7pRhGL+=FHjpd4WK3wBMkfVNDh_YQ4R33w@mail.gmail.com>
To: Werner Baumann <werner.baumann@onlinehome.de>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
2016-11-03 5:46 GMT+09:00 Werner Baumann <werner.baumann@onlinehome.de>:
> Just wondering.
>
> Cory Benfield wrote:
>> All of this *excludes* the alarming reality of the many millions of
>> embedded HTTP/1.1 stacks which are implementing a protocol that is at
>> best a second cousin to the one specified in RFCs 7230+.
>> ...
>> What that means is that the user-agent field will not be used to flag
>> non-compliant implementations, it will be used to flag *compliant*
>> ones, as there are vastly more of the former than the latter. That
>> means that Chrome, Safari, Firefox, Opera (maybe), curl, and wget
>> will all get a pass, and everyone else will be “guilty until proven
>> innocent”. That means that we are rolling out a feature that is
>> expressly a "browsers-only” feature if we deploy it in this way.
>
> Now reading the rationale of the draft:
>> Most if not all of the web pages processed by a web browser contain
>> links to external resources that need to be fetched prior to
>> rendering the documents.  Therefore, it is beneficial to send such
>> links as early as possible in order to minimize the time spent until
>> the browser becomes possible to render the document.  Link header of
>> type "preload" ([Preload]) can be used to indicate such links within
>> the response headers of an HTTP response.
>
> Isn't this features mainly intended for the WWW and browsers and
> whitelisting these would meet the goal of this draft?

The target of the draft is to optimize web browsing experience, but
the expected recipient of Early Hints is not restricted to the
browsers. Reverse proxies (and possibly forwarding proxies) are
expected to convert links found in 103 into HTTP/2 push (for details
please refer to the latter half of the Introduction section).

In fact, part of the motivation of me drafting this document is to
standardize what some HTTP/2 proxies (e.g. nghttpx, H2O) already do.

> What other use
> cases would want to benefit from this? Embedded HTTP/1.1 stacks?
>
> Werner
>



-- 
Kazuho Oku
Received on Thursday, 3 November 2016 02:27:13 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 3 November 2016 02:27:16 UTC