Weirdly, when I'm evaluating open source libraries having their own domain name rather than a site on GitHub pages or ReadTheDocs is a very slight mark against them in my book - because of exactly this.<p>If a project has its own domain name, it has better be VERY confident that it will be renewing that domain for decades to come. If it's a relatively concise library I would much rather it use a trustworthy service to host its documentation as opposed to some custom domain that's likely to expire and break links in the future.<p>(My own open source projects now mostly hang off my <a href="https://datasette.io/" rel="nofollow">https://datasette.io/</a> domain, but I was a few years into that project before I committed to a domain name that I plan to renew for the rest of my life.)
From <a href="https://github.com/psf/requests/issues/6140" rel="nofollow">https://github.com/psf/requests/issues/6140</a>:<p>> The domain is still owned by Kenneth and the maintainers haven't had access to it in quite some time.<p>and:<p>> For those looking for alternatives, <a href="https://requests.readthedocs.io/en/latest/" rel="nofollow">https://requests.readthedocs.io/en/latest/</a> should be returning docs correctly again. This has been the "official" location for some time as we lack controls on the python-requests domains. I'll update again once we receive a response from Kenneth.
What does it mean that the domain has expired?<p>I tried to look it up on a domain purchasing website and it isn't available for purchase, and according to namecheap it is still owned by the same owner since 2011.
This happened to the Celery project a while back.
I was surprised most opensource projects arn't using something like gitlab or hub pages for cheap hosting for docs.
Too bad, requests is a very popular and useful library.<p>Yet, this is just one more example against reliying on third-party libraries for production purposes. Sometimes, urllib is enough.