Semi Protection

UESPWiki:Archive/CP RSS Atom Feeds

The UESPWiki – Your source for The Elder Scrolls since 1995
Jump to: navigation, search
This is an archive of past UESPWiki:Community Portal discussions. Do not edit the contents of this page, except for maintenance such as updating links.

RSS/Atom Feeds

Is anyone on the site seriously using these? The server-status page reports 7 attempts at accessing RSS or Atom feeds, all of which have been frozen for 4 days now, tying up the server and slowing down the site. This is not the first time it's happened, and we have to get Daveh to restart the server every time. So what I'm asking is whether it's really at all beneficial to the site to have these active at all? If nobody's really using them, I think we should consider simply disabling them to prevent them from bogging down the site repeatedly. --TheRealLurlock Talk 16:04, 2 December 2007 (EST)

At the moment these feeds represent a clear DoS possibility to anybody who wants to harm the site and I'd agree they should be taken off if at all possible. To be honest, even if a few users are using them legitimately the danger to the site is great enough that they should go anyway. Hopefully their removal will help the site to stay up longer between reboots. --RpehTCE 16:56, 2 December 2007 (EST)
Except that RSS/Atom feeds aren't the source of the problem, and they're not the only way to get a frozen connection. Anyone who tries to view the diff on a problematic edit, no matter what way they try to do it, will get a frozen connection. I've had it happen to me, and I've seen it happen to almost every other patroller on the site. So if the real concern is eliminating a possible avenue for a DoS attack, I don't think that turning off RSS/Atom feeds really makes the site more secure.
Furthermore, at least some of the editors right now who are having an extremely hard time accessing the site have frozen connections. Lurlock for example has an edit from yesterday that is still connected to the server. There are a couple of "read"-status connections in the server logs that have been frozen for a couple of days and I'd be willing to bet that one of those is rpeh (no IP addresses are provided at the "read"-status stage, so it's not possible to verify it unfortunately). Those connections would be frozen right now whether or not RSS/Atom feeds were enabled; the server would still need to be restarted to fix those frozen connections. So although the RSS/Atom feeds are contributing to general performance problems, they are not the reason why some people are having particularly acute problems accessing the site.
If we want to really make the site more reliable and more secure, we need to find the bug in the wiki code that freezes connections. I know in a general sense what triggers it in the common cases: viewing a diff of a large edit to a large page. The fact that apache isn't able to automatically terminate these connections says that they're being locked up in an unusual state. But any more serious debugging would really require being logged in to the server: being able to view the status of the frozen processes, view the server logs, being able to add some debugging messages to narrow down where in the code it's happening, being able to trigger the bug repeatedly and then restart the server. It's possible that going that process might also identify some underlying problem that also explains the other frozen connections that crop up from time to time, but that's purely speculation. --NepheleTalk 18:48, 2 December 2007 (EST)
You're right of course, but my concern is that the feeds will always cause the issue if a problematic edit exists; without the feed it requires somebody to view the precise difference. At the moment, 7/10 of the blocked connections are caused by the feed pages, which would seem to suggest that even though they aren't the source of the problem, they're the main expression of it. If there's no easy way to turn them off then Nephele's right - it makes more sense to fix the underlying problem. But if there's a switch somewhere, I'd seriously consider using it. --RpehTCE 02:49, 3 December 2007 (EST)