Re: New Draft: The Sustainability HTTP Response Header Field

Hi Andrei,

Speaking only for myself - 

I think the measures you've outlined are reasonable to address the issues you point out, with a few adjustments.

I would focus mostly on the opt-in mechanism; header compression comes 'for free' in H2 and H3, and often can't be controlled with any precision by those who are creating responses. Note that if you want people to use the opt-in mechanism, you actually have to specify it and create an entry in the IANA HTTP Preferences registry.

"Proxy aggregation" is a misnomer -- proxies in HTTP are interposed on behalf of the client, and so won't have much visibility into the cost of particular requests. I think what you mean is that gateways (like CDNs) might inject this header based upon their knowledge of the server (perhaps through configuration).

That highlights an important caveat. No where do you address why this information needs to be included in individual HTTP responses. "Proxy aggregation" implies that it's possible -- and indeed, will likely be common -- to estimate the costs based upon historical averages and other data, and then just apply that computed figure to an individual response; it may indeed be quite rare for someone to actually measure the energy used in satisfying a *specific* request.

If that's the case, a more realistic (and efficient!) approach would be to write down those estimates and related data somewhere for access by clients out-of-band; for example, making it available at a .well-known URI on the server. Doing so would reduce the overhead of the protocol considerably (both energy-wise and operationally).

I could still imagine using a header like this to convey something if it were much more narrow than "the estimated environmental impact of fulfilling the request," which is quite broad, imprecise, and difficult to estimate -- it begs the questions "by whom?" and "including what?". 

Better would be "the amount of energy used by a resource to compute a response" *above* a particular baseline, and specifically ignoring costs such as network transit. That number is likely to be useful and relevant regarding a query that's satisfied by e.g. spooling up an LLM. It's almost useless for a GET that's served out of cache, since the number it contains will be both very small and very much an estimate that includes some costs and excludes others. 

That brings up one more caveat. If the header is in a response that's cached, it's going to be misleading. For example, a request for something that requires spooling up an LLM is likely to have a high number; however, if that response is to a GET and it's cached, subsequent requests are going to very, very cheap, and yet that header will still be sent to them out of cache.

You could partially address this by specifying that the header should be ignored when the response has an Age header. However, note that some CDNs and reverse proxies don't set an Age header, so this isn't reliable. I suspect it'd be better to say that it's only valid on responses to POST requests.

A few other thoughts:

* If you really intend this header to report "the estimated environmental impact of fulfilling the request," it shouldn't be a Dictionary, it should be a List -- that impact is spread over many actors, and each needs to be able to add its own metrics. Long experience has shown that intermediaries are very reluctant to dynamically recalculate header values on the fly; at the most, you can ask them to add their information to a header block. Again, I do not recommend that the semantics be so broad as to necessitate including intermediaries.

* Requiring this to be a header means that the server will need to buffer the entire response so that it can calculate an accurate figure. Buffering is unattractive for performance and scalability reasons. If it were allowed to be a trailer this could be avoided, but note that trailers can be dropped by intermediaries, and may not be exposed in some client implementations. 

* "Sustainability" is a fine goal, but it doesn't describe what this header does very well. I'd suggest "Resource-Energy" if you take the approach I outline above.

Cheers,


> On 28 Feb 2026, at 4:03 am, Andrei Besleaga <andrei.besleaga@ieee.org> wrote:
> 
> Hello dear members of working group,
> I have just submitted a new Internet-Draft proposing the "Sustainability" HTTP response header field.
> Draft: https://datatracker.ietf.org/doc/draft-besleaga-green-sustainability-header/
> As regulatory frameworks increasingly require transactional traceability for carbon accounting, there is a growing need to stamp a precise environmental cost onto digital transactions.
> This draft defines a structured mechanism for servers to report environmental impact metrics (such as Scope 2 and Scope 3 emissions) associated with processing an HTTP request. To ensure high parsing reliability and compatibility with modern HTTP/2 and HTTP/3 header compression (HPACK/QPACK), the header is defined strictly as a Structured Field Dictionary (RFC 8941 / RFC 9651).
> I am aware that previous proposals for carbon-emission headers (e.g., draft-martin-http-carbon-emissions-scope-2) faced valid pushback regarding the "rebound effect"—the concern that adding metadata to trillions of HTTP requests could consume more energy than it saves. To address this, the current draft mandates HPACK/QPACK compression, an opt-in behavior using the Prefer header, and proxy aggregation where per-thread calculations are prohibitive.
> My primary question for the community is: Does this technical approach successfully solve the rebound-effect concerns raised in previous carbon header proposals?
> I would appreciate any feedback on the suitability of this work within the GREEN WG, or any other technical help or suggestions.
> Best regards,
> Andrei Nicolae Besleaga

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

Received on Sunday, 1 March 2026 21:41:52 UTC