It's long gone. Kill it, kill it with fire
Description
Description
Details
Details
| Project | Branch | Lines +/- | Subject | |
|---|---|---|---|---|
| operations/dns | master | +0 -2 | Remove secure.wikimedia.org from DNS | |
| operations/puppet | production | +1 -31 | Remove secure.wikimedia.org from apache |
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Invalid | None | T93531 secure.wikimedia.org entries still showing up in Google search results | |||
| Declined | None | T120790 Remove secure.wikimedia.org | |||
| Open | None | T119274 Check incoming requests to secure.wm.o |
Event Timeline
Comment Actions
Change 257510 had a related patch set uploaded (by Reedy):
Remove secure.wikimedia.org from apacheo
Comment Actions
Change 257513 had a related patch set uploaded (by Reedy):
Remove secure.wikimedia.org from DNS
Comment Actions
Traffic is irrelevant imho. This was a user-facing service for many years. See also https://meta.wikimedia.org/wiki/Don't_delete_redirects. It's not like bits.wikimedia.org or other internal services.
They may be used in old discussions, mailing lists, talk pages, tweets, edit summaries, printed form etc. Just because they don't happen often doesn't mean they no longer exist.
Comment Actions
@BBlack: Any idea who could (be in a position to) make a decision (kill vs. decline)?
Comment Actions
I'm normally in favor of removing cruft when we can, but this was a semi-canonical way to access our domains for a long time, and it still has functional redirects to our current canonical HTTPS URLs. There's probably a lot of other more-important cruft to kill before we go after this, which will give more time for old usage of it to die off naturally. So I'd say decline for now, revisit later (later as in a year or two probably).