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

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? What other use
cases would want to benefit from this? Embedded HTTP/1.1 stacks?

Werner

Received on Wednesday, 2 November 2016 20:47:33 UTC