New principle: Guidance on HTTP Headers

[johannhof]

This was brought up in our discussion of Storage Access Headers.

The design principles do not contain a lot of guidance on HTTP request / response headers. They only say that one should use structured fields, but it seems like there are a bunch of other considerations for headers that new user agent features should consider:

• Naming - How should we name headers, what conventions do we follow?
• Request size / overhead - how bad is the impact of new request headers on the web infrastructure, considering things like header compression, etc.?
• Should we aim to reduce redundancy and omit request headers where possible, or consistently supply them for robustness?
• Something about the trade-off between exposing headers vs. JS APIs

...and probably other things I'm not thinking of right now.

So, more headers guidance please :)

[ylafon]

Like in https://www.rfc-editor.org/rfc/rfc9205#name-specifying-http-header-fiel

[annevk]

Same-origin policy implications and whether to use a Sec- prefix and such are probably the most pertinent. But I think in most cases you want Fetch community/editor review for any new web platform HTTP headers.