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

Excellent question about CO2 quotas!

However, in 2023, we're looking for a way to know the carbon emissions of our supply chain (external Web services).

Maybe in the future we will be able to implement a negotiation mechanism on CO2 quotas, but unfortunately it's likely we'll never be able to implement such mechanism at the HTTP request/response level (given the state of the art in programming and energy observability).

So that may be discussed for another RFC.

Bertrand Martin
sentrysoftware.com<https://sentrysoftware.com/>

From: Graham Cox <graham@grahamcox.co.uk>
Sent: Tuesday, April 11, 2023 5:49 PM
To: ietf-http-wg@w3.org
Subject: Re: Introducing a new HTTP response header for Carbon Emissions calculation

I know very little about the CO2 emissions aspect of all of this. However, I wonder if there's any benefit in the exact opposite header as well?

This proposal is an HTTP Response header that tells you how much CO2 was emitted in the processing of the request.

But would there also be benefit in an HTTP Request header that tells the server an acceptable upper limit on CO2 emissions? That way, the client can tell the server that the processing should emit no more than XYZ, and if it does exceed that then the server can either fail (which would be wasteful, but at least would stop even more emissions) or else return a partial result with what it's managed so far.

That gives the clients some ability to keep emissions down whilst still doing what they can, rather than just keeping track of the emissions that they have caused.

Just a thought :)

Cheers

On Tue, 11 Apr 2023 at 15:17, Mark Nottingham <mnot@mnot.net<mailto:mnot@mnot.net>> wrote:

> On 12 Apr 2023, at 12:10 am, Lucas Pardue <lucaspardue.24.7@gmail.com<mailto:lucaspardue.24.7@gmail.com>> wrote:
>
> Have you considered how this might work where there is a chain of servers involved in handling a request? We might think of CDNs in this light but it is also common for servers to sit in front of something like an app server or cache server. Therefore it could benefit this proposal to make it a list of values that can comprise the entire lifecycle of a request/response exchange.

I had the same thought. It's probably best specified as a List of Decimals; see:
  https://httpwg.org/specs/rfc8941.html


But, I also wonder if the response is the best place to put this information -- it only makes it available after the fact, and scatters information that needs to be aggregated for many use cases. More discussion / description of the use cases would help guide the design.

E.g., if the client is an API consumer and their use case is informing their request patterns, it's likely better to get this sort of hint from a description (e.g., OpenAPI) rather than in responses.

That doesn't mean you shouldn't define the header, of course -- just that it might not be useful on its own. Also, adding headers to responses does ever-so-slightly increase carbon emissions...

Cheers,

--
Mark Nottingham   https://www.mnot.net/