What to do with an accepted answer which is plainly wrong?

Question

Inspired by this question and this one.

In the first question, the accepted and most upvoted answer is wrong and misleading, but it looks like it has been around for a while, it somewhat works (although with many caveats which the comments rightly pointed out), and people generally agreed it was perhaps adequate, presumably from lack of better knowledge; additionally, the second most upvoted answer is also an horrible kludge (using ping to pause batch execution? No, seriously?).

The second question does more or less the same.

Additionally, two elements make this situation even worse: the questions are about a very simple topic which is likely to pop up in searches (sleeping a few seconds in a batch file is by no means an unusual need), and the users who originally created the question are (or looks like they are) no longer around to accept a new and better answer.

What to do in such a case?

Answer 1

Questions like these and also questions with a known correct answer (but none of the answers are marked correct) are the reason I think Mods should be able to select Accepted Answer on questions that are blatantly abandoned (whatever criteria you want for that, user doesn't exist and Q is at least 1 mo old; User hasn't logged in for 3+ months... something reasonable)

Answer 2

Downvote and leave a (polite, detailed) comment explaining what's wrong with the answer.

It would be especially helpful if you leave a correct answer to help the poor asker out (and will probably net you some upvotes, particularly if you drop the WTF answer in The Comms Room :-).

If your answer is really good you may even earn yourself a Populist badge.

Answer 3

All I can really say is that shit happens. If it's bad, downvote it.

from How can I list my open ports on Debian?

if "-10 votes" isn't a signpost, there's very little else we reasonably can do. Oh, and:

Answer 4

Since no similar question seemed to be around asking the same thing and showing the correct answer, I created one and suggested closing the incorrect ones as duplicates.

Answer 5

When you see an incorrect/misleading answer, the first thing to do is to downvote and preferably to add a comment. If someone has already left a comment for this, upvote the comment itself.

Beyond that, it can be tricky and may have to be handled on a case by case basis.

I think the biggest problem with this is that it seems some users tend to up-vote the answer that already has the highest score, even if there are more correct answers around.

I've noticed this in this question, asked in Sep 2009. The most highly upvoted answer (until March 2012) was incorrect.

• I downvoted it and left a comment in Sep 2010.
• Some people kept up-voting it, so I left another comment with more details in Dec 2011.
• Later, I noticed that people kept up-voting it, so I took the time to write a much longer answer (with references). It started to be upvoted a bit and eventually caught up with the incorrect answer.

What I've noticed is that the incorrect answer still got a few upvotes during that period. It was clear that those up-voters had not gone much further than this incorrect answer (still at the top of the list per vote count at the time). My guess is that my answer was "rescued" from being unnoticed by the fact it's rather long and has a fairly large number of references. It seems quite hard to break out of that "up-vote the answer with the highest score" pattern otherwise, unfortunately. (I should point out that the asker hadn't accepted any answer at the time, and that the author of the incorrect answer never replied to any comment. I'm not sure whether those questions were semi-abandoned.)

Another thing that can help, if you've exhausted the approaches above (i.e. downvote, comment and write a better answer) is to draw attention to it on Meta. It's not quite what Meta is for, but for clearly incorrect cases, it's worth a try. (I would seem that the "publicity" coming from a discussion on the closure/rewording of that question led more visitors to it.)

I'm not entirely convinced that flagging or asking for moderators to sort it directly is the right approach. I'd still prefer there to be a discussion on Meta beforehand, simply because re-arranging the accepted answer forcibly goes again the principles of SE, even if it's for the right reasons.

In addition, even high rep users and moderators can be wrong sometimes. No one is perfect. I'm going to illustrate this with an example. I apologise in advance to voretaq7: please don't take it the wrong way, I'm only picking on this particular answer of yours, which is incorrect; I know that the vast majority of your answers are usually correct and that you deserve your high rep. This is unfortunately one of those instances where the incorrectness was pointed out in comments (even in this question).

---

The currently accepted and most highly upvoted answer to this (canonical) question is mostly incorrect; it was completely incorrect to start with, but has now been altered to add a correct link, leaving the incorrect parts unfortunately. Since a bounty was offered on that question a few weeks ago, a complete and correct answer appeared, although it's not yet the most highly upvoted. (In my opinion, the best course of action would be for the author of the incorrect answer to delete his own answer, there would be a slight loss of rep, but negligible out of 40k+, and he would win the Disciplined badge.)

Now I need to justify what's wrong with this answer... (In fact Meta is probably a slightly better place for this, since comments don't give enough space unfortunately.)

The question is about what can make multiple certificates on the same IP address and port for a web server with SSL.

• The answer (since its first revision) talks about RFC 2817:

"Multiple (different) SSL certificates on one IP" is brought to you by the magic of TLS Upgrading. It works with newer Apache servers (2.2.x) and reasonably recent browsers (don't know versions off the top of my head).

RFC 2817 (upgrading to TLS within HTTP/1.1) has the gory details, but basically it works for a lot of people (if not the majority). You can reproduce the old funky behavior with openssl's s_client command (or any "old enough" browser) though.

While upgrading to TLS on the same connection could solve this problem, this is not how HTTPS works. HTTPS is HTTP over TLS (RFC 2818), not RFC 2817.

HTTPS (as used by user-agents connecting to an https:// URL) always initiate the SSL/TLS connection first.

RFC 2817 is widely unsupported. No browser support it (see Chromium issue 4527 and Firefox issue 276813). There are some good arguments against using it (mainly because it's hard to convey the fact you need to turn on security afterwards by just having a URL, whereas https:// does it well with RFC 2818).

The only software I've heard of that uses RFC 2817 is Cups (the printing system). Even if Apache Httpd has had support since version 2.1, it seems to have been buggy since version 2.2.9, at least with OPTIONS *, without which you would have to send the initial URL in clear, before the upgrade. RFC 2817 wasn't supported more in 2010 or in 2000 than in 2012.

openssl s_client has some support for protocols that upgrade within the application protocol (the "START TLS" way), HTTP and RFC 2817 isn't one of them. As the help says: Currently, only "smtp", "pop3", "imap", "ftp" and "xmpp" are supported.

• A subsequent revision adds some curl debug traces, using -1 (for using TLSv1) and -3 (for using SSLv3), possibly to try to justify that upgrade story.

  Unfortunately, neither of these debug traces show any HTTP traffic at all, they only show the SSL/TLS handshakes. RFC 2817 is a protocol that relies on an explicit HTTP Upgrade header, in an HTTP request. This isn't there.

  In both cases, with SSLv3 and TLSv1, the HTTPS connection starts with establishing the SSL/TLS connection. No upgrade takes place later on.

  The real reason why this is happening is that TLSv1 has been extended with a server name (SNI) extension (see RFC 3546), which came after the TLS 1.0 specification, and was never back-ported to SSLv3.

  By using -1 with curl, both TLSv1 is enabled, which also makes it use the SNI extension if it was compiled with a recent-enough version of OpenSSL (OpenSSL 0.9.8f with specific compile-time options and OpenSSL 0.9.8k by default, according to this).

  That extension is part of the Client Hello message, and the curl trace doesn't show any of its details, thereby making the traces irrelevant without the explanations I've just given (and misleading when connected to RFC 2817).

• A later revision finally adds a link to SNI (in the context of Apache Httpd), which is the only correct part of that answer. It's just unfortunate that the rest of the answer wasn't removed. SNI is something that happens in the initial Client Hello sent by the browser, not something that's upgraded later.

The issue is that the answer's author seem to confuse SNI (the TLS extension defined in RFC 3546, later integrated with TLS 1.2, which is purely a TLS mechanism) with the protocol upgrade as defined in RFC 2817 (which requires some HTTP application protocol messages to be exchanged before the socket is upgrade to SSL/TLS). Coming from one comment on that answer:

Re: apache and SNI, Apache (2.2.x) definitely supports SNI, and should support TLS upgrading (it would probably depend on the version of the SSL library you're using though - something you should test on your specific installation). Specifically allowing only "strong" encryption via your SSLCypherSuite rather than have the client renegotiate the connection's encryption is definitely preferable though.

Again, TLS upgrading has absolutely nothing to do with what happens with SNI. Granted, SNI only works with TLSv1 or above, but the SSL/TLS version (3.0, 3.1, ...) is negotiated from the start when using HTTPS, there's no "upgrade" going on. RFC 2817 is enabled with Apache Httpd by using SSLEngine optional; how many of us have ever used "optional" there, really? Since it's not supported by browsers, what would be the point anyway? Unlike SNI, RFC 2817 support doesn't depend on the version of OpenSSL used with Apache Httpd.

Perhaps some of this misconception comes from the eternal confusion between SSL, TLS and "START TLS" (where the key word is "START", not "TLS")...

Apart from 3 lines at the top, that answer is misleading and/or incorrect. Yet, it's the accepted answer with 36 upvotes and 2 downvotes.

tl; dr

In short, when there's an incorrect accepted/highly upvoted answer, once the downtvote+comments approach has been used and has failed, discussing it here on Meta is probably the way to go.

As for the particular answer I was using as an example, its author quotes RFC 2817, which is in fact virtually never used, at least not for HTTPS, and confuses the "TLS Upgrade" defined in that RFC (which requires some plain-text HTTP exchange first) with Server Name Indication. He also seems to confuse TLS, (the version of SSL/TLS following SSLv3) with the common mechanism for upgrading from plain-text traffic used by other protocols often known as STARTTLS. Indeed, he seems to assume that the behaviour is different with SSLv3 because TLSv1 does an "upgrade", whereas it's because TLSv1 has support for the SNI extension when SSLv3 hasn't: in both cases the HTTPS connections are initiated with an SSL/TLS Client Hello without any RFC 2817 upgrade.

Despite multiple comments, that author hasn't done anything about it, which is a bit at odds with his own answers to this very question.

Answer 6

It comes to show that "wrong and misleading" might also be a matter of the viewpoint. The now most-downvoted answer to use "ping" is one that works and actually has been used for years in a whole number of logon scripts before "timeout" appeared in the stock Windows installs. It still is one of the few generic alternatives to pause execution for Windows XP / 2000 legacy clients.

In general, although editing accepted answers is frowned upon, if I would see an accepted answer which is plainly wrong (and does not just represent and unelegant solution to the problem), I would double-check first and edit it with the correct information afterwards, maybe using strike tags to make the edit more visible.