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.

[jyasskin]

We're mostly delegating HTTP advice to the IETF, currently in https://w3ctag.github.io/design-principles/#using-http, but #546 proposes to shorten that into https://w3ctag.github.io/design-principles/#specs-include-guidance. The cited RFC9205 delegates to RFC9110 on naming, which mentions the impact of names on request size. Those RFCs don't address omitting request headers, but an IETF document seems like the right place to discuss that.

A web document should discuss the tradeoff between headers and JS: Something like "Client-side APIs (whether in HTML, CSS, or Javascript) are more flexible and usually cheaper than HTTP headers, especially headers that would need to be sent on every request. However, sometimes new HTTP headers are needed for cases where servers need to react to a condition before their response has started executing on the client."

If the Fetch editor (that is, Anne) is willing to review new web platform HTTP headers, it'd be good to add a section on his general advice and how to ask for review at, perhaps, https://fetch.spec.whatwg.org/#background-reading, and then https://w3ctag.github.io/design-principles/#specs-include-guidance can link to it. @annevk does that make sense to you? I'm inclined to put the header-vs-JS paragraph in that section so people have fewer places to look.