Guidelines for header field names

[mnot]

Is it useful to give some guidance about the use of prefixes like:

• Accept-
• Allow-
• Expect-

etc.? In particular, we could say that you can't depend on the semantics of a prefix, but it's a good idea to align your use with existing prefixes.

[annevk]

Is it worth mentioning Sec- here?

[mnot]

I think so, but probably separately, since the ones above don't trigger any automatic handling, whereas Sec- does.

[royfielding]

I don't think it is true that they don't trigger automatic handling -- that happens for Accept-* and Content-*, for example.

I also don't think we should encourage application-specific prefixes unless we can also accurately define what application-specific means and avoid repeating the mistake of x-prefixes. In general, it is better to encourage broad standardization and ignore the ones that failed, rather than encourage prefixes and then have to make a standard out of them after deployment.

I do like the tweak to encourage shorter names.

[mnot]

I don't think it is true that they don't trigger automatic handling -- that happens for Accept-* and Content-*, for example.

How so?

I also don't think we should encourage application-specific prefixes unless we can also accurately define what application-specific means and avoid repeating the mistake of x-prefixes. In general, it is better to encourage broad standardization and ignore the ones that failed, rather than encourage prefixes and then have to make a standard out of them after deployment.

"limited-use, such as a header confined to a single application or use case"?

[MikeBishop]

More generally, if I come along and define something new in an existing family -- let's say Accept-Species:, to indicate I only want resources that include cat pictures -- is there any logic that will treat it differently because it's Accept-*, even if unknown? Will I start seeing Content-Species: headers in responses? I'm dubious, though I could obviously be wrong.

Even Sec- I find questionable, because it's not the HTTP layer that's attributing any specific meaning to that prefix.

At the HTTP layer, we don't care what format a header name takes; it's merely an opaque key in a dictionary. However, as a best practice, aligning your naming with similar headers aids developer comprehension and debugging.

[royfielding]

"limited-use, such as a header confined to a single application or use case"?

yes, that's much better.