Re: Introducing a new HTTP response header for Carbon Emissions calculation

Yeah server-timing is one of the headers that sprang to mind when reading
the proposal. Which really focuses the question, who is this data for and
why should it be added to every request on the wire?

Server-timing is useful because it provides information related to the
performance of the request. That can help with spot debugging and/or
beaconed back somewhere. In the reporting case, this might be sampled to
provide some protection for the data aggregator.

With this carbon header, who is anticipated to be processing it? So far
we've heard it could be the client software, a site operator, or even a hop
(by summing the received value with its own).

If its just a header that hits a browser, what good is it in isolation?

At TPAC 2022 there was discussion that overlaps this proposal[1]. Some of
that discussion related to how a sizeable amount of energy is cobsumed by
the user agent to request, receive, and process resources. There seems an
opportunity to have more utility via a more joined up strategy than _just_
adding a single header about the server side.


[1] -

On Tue, 11 Apr 2023, 19:20 , <> wrote:

> On Tue, Apr 11, 2023 at 01:56:44PM -0400, Michael Sweet wrote:
> > If we really want a short header name, why not just:
> >
> >     CO2: <value>
> >
> > (our shed is a lovely shade now, isn't it?)
> >
> > WRT negotiation, I think adding a request header/value limits the
> opportunistic value and adds a tiny bit more resource usage over just
> sending it if you have it.
> >
> >
> > > On Apr 11, 2023, at 1:34 PM, Greg Wilkins <> wrote:
> > >
> > >
> > > Really good idea to get some eco accounting into http.
> Server-Timing already exists for some metrics and might be extended
> with a CO2 metric.
> Cheers, Glenn

Received on Tuesday, 11 April 2023 19:40:44 UTC