Support the new Deprecation HTTP header

The Deprecation header indicates that an API is deprecated, and shouldn’t be used. It’s either true, or an HTTP datetime value (the time after which the API is deprecated).

This is a draft HTTP standard from the IETF HTTPAPI working group: https://datatracker.ietf.org/doc/draft-ietf-httpapi-deprecation-header/. It’s still a draft, but it’s been around since 2019 and been through a few revisions already. It’d be great if it was supported by Requests!

I think there’s a good argument that Requests should treat this like any of its own internal deprecation warnings (e.g. a, b, c), i.e. automatically logging it via warnings (if true, or if the date in the header has passed) to notify developers that they’re depending on explicitly deprecated functionality. This seems like a quick standards-based win to help developers deal with API changes before their projects break, rather than later.

I understand if you’d prefer to wait until the standard is finalized, but in the meantime I’m just interested to know if the Requests team is open to supporting this in theory?

Feedback on the standard is also very welcome, the WG mailing list is here: https://www.ietf.org/mailman/listinfo/httpapi

[sigmavirus24]

Yeah, that’s not this library’s responsibility, nor should any HTTP focused library be raising exceptions for things like that breaking code unexpectedly and requiring significantly more work from users of the library to be aware of it to start and handle it explicitly.

Logging this via warnings (another option) is also a non-starter. We log (and warn) things that are legitimately more concerning and get heaping loads of complaints about that already. If we start warning this on a single request, I can’t imagine the level of confusion and anger we’ll receive.

* Supporting this drives a virtuous cycle for the HTTP ecosystem: having more popular HTTP clients warn users for you makes the standard immediately valuable to API developers, which drives adoption there, making more HTTP clients use it, etc, until deprecation notices for APIs become a solved problem everywhere (granted, this may take a while smiley).

Alternatively, Requests supports this and other HTTP client developers see the vitriol that’s poured out here and decide never to do that because developers tend to treat each other horribly, especially when the other is providing free labour.

[pimterry]

There are a lot of forks based on drafts that have been dropped out before an official RFC was released

Yep, I think there’s a very good argument for not implementing this today, or at least not enabling it by default, until the standard is finalized.

I posted this mainly to start a discussion before that happens, to make it easier to implement this once/if this becomes a fully fledged IETF standard. Note that the sunset RFC is already a published RFC though (RFC 8549).

Personally, I’d find it really useful if python -Wd automatically printed warnings when talking to deprecated and/or sunsetted HTTP APIs, since that’s a strong sign that your code will stop working soon.