W3C home > Mailing lists > Public > public-web-perf@w3.org > February 2018

Re: Is there any way to deal with streaming content?

From: Patrick McManus <pmcmanus@mozilla.com>
Date: Mon, 26 Feb 2018 11:20:19 -0500
Message-ID: <CAOdDvNp=g5xyfxxL6VawhiUF3gsiYJHBX-SEP70RefCQYW-UAQ@mail.gmail.com>
To: Ilya Grigorik <igrigorik@google.com>
Cc: Anton Nemtsev <newsilentimp@gmail.com>, public-web-perf <public-web-perf@w3.org>
firefox is doing support for server-timing in trailers. Its actually the
only trailer we will support. (so far.)

On Wed, Feb 21, 2018 at 11:20 PM, Ilya Grigorik <igrigorik@google.com>

> Hi Anton. Yes, and no..
> Server-Timing is communicated via an HTTP header field that, per spec, can
> either be present in the initial set of response headers before the
> response body, or as a trailer after the response. As such, one could, in
> theory, deliver a Server-Timing trailer *after* the full response body has
> been streamed, annotating the individual chunks — note that you can't
> interleave this data with the response itself.
> The one extra wrinkle here is that trailer support is still lacking:
> Chrome does not support it (yet, at least), and afaik Mozilla implemented
> partial support but it's not wired up fully for Server-Timing.
> On Sun, Feb 18, 2018 at 10:46 PM, Anton Nemtsev <newsilentimp@gmail.com>
> wrote:
>> Hi,
>> am I right and there are no way to transfer server-timings if you stream
>> content?
>> For example when I use renderToNodeStream
>> <https://reactjs.org/docs/react-dom-server.html#rendertonodestream> to
>> render html on server side?
>> Regards.
Received on Monday, 26 February 2018 16:20:46 UTC

This archive was generated by hypermail 2.3.1 : Monday, 26 February 2018 16:20:47 UTC