Also, TIL that the IETF deprecated the X- prefix more than 10 years ago. Seems like that one didn’t pan out.
Can you elaborate on that? The X- prefix is supposedly only a recommendation, and intended to be used in non-standard, custom, ah-hoc request headers to avoid naming conflicts.
In short, although in theory the “X-” convention was a good way to avoid collisions (and attendant interoperability problems) between standardized parameters and unstandardized parameters, in practice the benefits have been outweighed by the costs associated with the leakage of unstandardized parameters into the standards space.
I still work on software that extendively uses X- headers.
I still work on software that extendively uses X- headers.
I wouldn’t worry too much about it. The reason they give is mostly that it is annoying if a X- header suddenly becomes standardized and you end up having to support X-Something and Something. Most likely a non-issue with real custom headers.
Can you elaborate on that? The X- prefix is supposedly only a recommendation, and intended to be used in non-standard, custom, ah-hoc request headers to avoid naming conflicts.
Taken from https://datatracker.ietf.org/doc/html/rfc6648
I still work on software that extendively uses X- headers.
deleted by creator
The RFC you linked recommends that no new
X-prefixed headers should be used.The paragraph you quoted does not say you should use the
X-prefix, only comments on how it was used.See section 3 for the creation of new parameters: https://datatracker.ietf.org/doc/html/rfc6648#section-3
I wouldn’t worry too much about it. The reason they give is mostly that it is annoying if a
X-header suddenly becomes standardized and you end up having to supportX-SomethingandSomething. Most likely a non-issue with real custom headers.