22
The Deprecation HTTP Header Field
(greenbytes.de)
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 09 Jul 2024
22 points (100.0% liked)
Programming
17314 readers
339 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities !webdev@programming.dev
founded 1 year ago
MODERATORS
I don't really get the purpose of a header like this, who is supposed to check it? It's not like developers casually check the headers returned by an API every week.
Write them a mail if you see deprecated functions being used by a certain API key, probably much more likely to reach somebody that way.
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.
Taken from https://datatracker.ietf.org/doc/html/rfc6648
I still work on software that extendively uses X- headers.
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.It makes sense to include so it's obvious in the readable HTTP request response. We use readable URLs and header names for the same purpose: So it is inspectable and understandable from that text format. You may leave deprecation information out, but then you're missing part of the resource description that you're addressing with the URL/URI.
Given a defined header it also allows you to add tooling and automation. There's no need for manual reading.
You can simply log this response. Then developers know to replace that call in the next version. If you have unit tests that look for this then you can be sure that your next version is not using any deprecated API calls.
We don't have many unit tests that test against live APIs, most use mock APIs for testing.
The only use for this header would be if somebody sees it during development, at which point it would already be in the documentation or if you explicitly add a feature to look if the header is present. Which I don't see happening any time soon since we get mailed about deprecations as well.