New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Define policy for which header name constants to include #573
Comments
Thanks for creating this issue. I went through the list of existing constants and here are some thoughts on the existing ones:
Speaking for me I would very well do without most of them if that meant adding newer security or otherwise useful headers. |
Thanks for listing those, it may be worth considering quicker if we should chop out some of the obscure ones that are currently in the crate before 1.0 (which is coming soon!). |
A good place to start is the IANA Field Name Registry. The registry itself is here, and the specification of the registry is here in RFC 9110. In this gist I compared the names in the registry vs the names defined as constants in There are three sets that I think are more debatable.
|
Hm, even the MDN DNT page says the header is deprecated. Perhaps it's worth just removing the non-standard ones entirely. Could we get away with removing all the deprecated/obsolete headers even if in the registry?
It's a fair position to take. If many others prefer it, we can do that. I'm personally skeptical of adding obscure names even if they are in the registry. They seem like a potential distraction in the docs. But I can't really articulate a good reason otherwise. Perhaps at least I'd wait to add the odd ones until someone really asked? |
I'm definitely coming from a biased perspective as an implementer of a reverse proxy. We don't control the nature of requests from clients or the responses from origins, so we try to accept as much actual existing HTTP traffic as possible without compromising security. It's also common for current, active specs to refer to deprecated and obsolete headers. This is often in
This raises a higher-level question: what is our goal for including these constants? For me, the value comes from being able to avoid repeating
I think being proactive about adding registered names would help us avoid a trickle of one-off PRs and requests for releases (like I am doing now in #583 😬). And while I doubt we want to impose a proc macro dependency for |
What if a core, standard, forward-looking set of constants were included by default, but then the rest of the obscure/deprecated/provisional/nonstandard-but-in-use ones were hidden behind a feature flag, like |
@d2718 the complexity of wrangling a Cargo feature would outweigh the benefit of less clutter in the namespace, in my opinion. I suppose we could add some namespacing via child modules of |
Another thing that came to my mind today was that now that Then I suppose a last question is how to determine whether something should be in |
I think we should start with a larger set in |
Would you be open for me to make a PR for Client Hint headers, or do these count as provisional, even if browsers do all support them now a days (the most common type of user agent among them all). I would understand if you do not want it yet though, even though servers and proxies do need these for content negotiation. It also impacts other aspects such as Caching. |
We include many standard header names as constants in
http::header
. The exact criteria has not been defined, and it would be wise to do so. This stops it from being an unwritten rule in a few people's heads. The policy likely should consider the pros of adding any name versus the costs of adding a name.The text was updated successfully, but these errors were encountered: