A helpful user notified me that ~8 links in one of my answers on Cryptography were broken. I quickly found out that the problem is that the HTML version of RFC's have moved. The original HTML versions were not seen as a standard rendering and could be found at, e.g. http://tools.ietf.org/html/rfc3447.html for the RSA standard. As you can see this is the unprotected HTTP; I guess that the link to https://tools.ietf.org/html/rfc3447.html was never used because that document doesn't exist; it seems to be a forward to https://datatracker.ietf.org/doc/html/rfc3447.html.

A pretty intensive look at RFC shows that this is not the preferred location of RFC's. The actual RFC is published at https://www.rfc-editor.org/rfc/rfc3447.html. That should be the correct location. Still, since the IETF forwards to the data tracker as replacement, I guess that's the preferred method to replace the deprecated URL's.

So the feature request is: would it be possible to use an automated tool to change all deprecated http://tools.ietf.org/html/* links (EDIT: and the currently https://tools.ietf.org/html/* forwarded links) to https://datatracker.ietf.org/doc/html/*? Going over all my answers to replace these links seems a huge waste of time, and more importantly, it wouldn't do anything for all the other answers on Stack Exchange whose links have broken.

  • 5
    Tagging this as status-review since staff has a tool specifically for straightforward URL substitutions like these.
    – Glorfindel Mod
    Commented Jul 28, 2021 at 8:20
  • 2
    Is it maybe worth contacting the webmaster at ietf.org to confirm this is the correct place they want us redirect to? I'm assuming here that you're not the webmaster on ietf.org but I wouldn't be surprised if you were ....
    – rene
    Commented Jul 28, 2021 at 8:37
  • Heh, no, I'm not associated in any way with IETF, although I have been sideways involved in some RFCs (initiated a small change in TLS 1.3, for one). I would have to look up the webmaster there, but as they themselves forward to the data tracker instead of RFC editor I think we should use that as most logical location. I think that's also most likely to have all the links, not everything progresses to become a true internet standard after all. Commented Jul 28, 2021 at 12:27
  • @Glorfindel I presume the tool tests if the target URL exists before converting? Commented Jul 28, 2021 at 12:28
  • 3
    @MaartenBodewes no. I presumed all URLs would exist in the new scheme. My bot is capable of repairing more selectively but 1) it bumps posts and 2) it only runs under my account, and I don't have network-wide edit privileges.
    – Glorfindel Mod
    Commented Jul 28, 2021 at 12:37
  • Well, if there is anything amiss we'll find out soon enough. We can always adjust once more, but I don't think it will be needed. I'll check some of my posts that link to "tools", there are plenty of those as I like to reference standards in my answers. Commented Jul 28, 2021 at 12:54
  • 5
    This is on the CM team backlog. We'll have a look at how many posts are affected by this network-wide, and get back to you with updates after that.
    – JNat StaffMod
    Commented Jul 28, 2021 at 14:50
  • 1
    @JNat Good to hear. If possible I would also look at the secured https tools.ietf.org URL's, doing a spurious forward seems unnecessary and they may stop the forwarding service in the future. Commented Jul 28, 2021 at 20:58
  • 12
    This change affects on the order of 10,000 posts cross the network. Because the scope of the change is so large, we've sent an email to IETF attempting to confirm that https://datatracker.ietf.org/doc/html/ is the correct destination going forward before making any changes. I will provide updates here once the team receives a reply.
    – Slate StaffMod
    Commented Sep 22, 2021 at 16:20
  • 5
    Question on MSO about this: Community replaced http://tools.ietf.org/html/rfc with https://www.rfc-editor.org/rfc/rfc - why?. Also, hilariously, Community bot just replaced the example link in both of these posts. Will this replacement keep happening after rollbacks? Better use code formatting like https://tools.ietf.org/, then. Commented Oct 7, 2021 at 7:06

1 Answer 1


Post-hoc update: we were able to capture a bit more than we thought we would - namely, drafts. Final summary of the changes follows.

  1. [http/https]://tools.ietf.org/html/[rfc/RFC] became https://www.rfc-editor.org/rfc/rfc network-wide
  2. [http/https]://tools.ietf.org/html/draft- became https://datatracker.ietf.org/doc/html/draft-

Both of these should conform to the reply we received from IETF.

In total, 18k posts on Stack Overflow were fixed, and another 7k network-wide.

Yaakov has my sincere gratitude for helping get the tooling for this up to date and effective to make this network-wide change easy and fast - and the tools should be more enduring for future use cases as a result, too.

I will be waiting a couple days after this post to make these changes, to allow for some feedback on whether my plan is the appropriate way to proceed for our network. If you have any reason you think we should pause or change course, speak now or forever hold your peace. If nothing comes up, expect this to be done by end of week.

I've spent some time chatting by email with a very helpful contact at the IETF, and I'm grateful for their several quick replies. Here's the long & short of it.

rfc-editor.org is the canonical location for RFC documents, and will remain the correct destination for now. The RFC document locations at the various IETF URLs aren't canonical repositories, even though they do ultimately point to the same documents. I gather (but could be wrong) that these are more so 'working repositories' than the reference documents themselves.

After RFC8650, the format for RFC documents changed, and there are some visual differences between rfc-editor.org and datatracker.ietf.org. Our contact at the IETF has indicated that there shouldn't be any differences in the content between the two - but one is a canonical resource, and will have different formatting for pre-RFC8650 documents. As an example, see:

  1. https://www.rfc-editor.org/rfc/rfc7841.html
  2. https://datatracker.ietf.org/doc/html/rfc7841/

Since I'd personally prefer we reference the canonical documents for the longevity of the posts on our network, my plan is to move both http://tools.ietf.org/html/[RFC####].html and https://tools.ietf.org/html/[RFC####].html over to https://www.rfc-editor.org/rfc/[RFC####].html, which is the primary resource for published documents.


  1. Links targeting http://tools.ietf.org/html/draft-*, where RFC internet drafts were stored, may need to be moved to the IETF data tracker - and this will need to be double checked by hand.
  2. IETF may move these documents in the future, and though we can expect a redirect for these documents, the possibility we'll need to move these links over in the future is not precluded.
  • 2
    I'll also be pinging the moderators of some of the more affected sites across the network - mostly SO, InfoSec, Server Fault, and a couple others.
    – Slate StaffMod
    Commented Sep 27, 2021 at 19:43
  • Is your replacement search able to only touch links with subsection-anchors looking like they will work at the new location? Are you considering any additional URLs? (third-party formatters/mirrors/non-html/non-http(!), e.g. SF, Security).
    – anx
    Commented Sep 28, 2021 at 7:25
  • I have made links as per your second example - where the URL does not end in .html e.g. tools.ietf.org/html/rfc2822 Will you be moving those as well
    – mmmmmm
    Commented Sep 28, 2021 at 15:26
  • 1
    @mmmmmm That's a good catch. Those would have been caught the way I was planning on doing this, but I definitely wasn't expecting that style of link, so I'll make sure to double check those when we deploy.
    – Slate StaffMod
    Commented Sep 28, 2021 at 15:28
  • 1
    @anx As far as I'm aware, our tool is a direct match and substitution on a subsection of the URL. If there are other URL formats that need to be included, let me know.
    – Slate StaffMod
    Commented Sep 28, 2021 at 15:28
  • 2
    Quick update - a) the tool I was planning to use requires additional access I don't have, and b) the change is actually a bit more complicated than this plan. Don't have an updated ETA unfortunately, but it's still in the works. Probably the next update will be to say that we did it, either way.
    – Slate StaffMod
    Commented Sep 30, 2021 at 14:48
  • 1
    Updating links is pretty important, maybe some time should be spent on improving the tooling to be able to do so. Bad link detection would also be a great thing to have (I'm always wondering why I get bad links on sites that are content-managed). That said, at least on SE users can change URLs, so there's that. Commented Oct 7, 2021 at 10:59
  • 4
    @MaartenBodewes That's actually what's caused the hold! This tooling should be significantly better in the future, huge props to the devs.
    – Slate StaffMod
    Commented Oct 7, 2021 at 14:04
  • @Slate Cool, happy if I helped initiate that, and great that the devs implemented it of course. Don't forget to notify us when everything is done, as I still have an accept to do :) Commented Oct 7, 2021 at 21:49
  • I've more than 7.5 pages - I think that's 153 revisions - of a certain community user to review :) Commented Oct 8, 2021 at 15:10
  • 1
    Tag info pages links don't seem to be updated though.
    – TheMaster
    Commented Oct 10, 2021 at 22:36
  • 1
    Could you pass me an example @TheMaster?
    – Slate StaffMod
    Commented Oct 11, 2021 at 14:15
  • @Slate The link to rfc4180 @ stackoverflow.com/tags/csv/info
    – TheMaster
    Commented Oct 11, 2021 at 14:28
  • 1
    @TheMaster Yeah, the tool won't touch every part of the site - and won't cover tag wikis. Some of that will have to be done by hand, unfortunately.
    – Slate StaffMod
    Commented Oct 11, 2021 at 14:59

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .