It looks like the plus sign %2b is getting doubly unescaped in tag names in URLs.

Unanswered Questions => link => https://stackoverflow.com/unanswered/tagged/c%2b%2b but this lists only tagged :

Add 11 to preceding URL => https://stackoverflow.com/unanswered/tagged/c%2b%2b11 lists questions tagged .

Clicking another tab then converts the %2b's to unescaped plus signs.

The "unanswered" tab under the "Questions" section works:

Why are there separate unanswered buttons right next to each other — a website section and a search filter with near identical functionality?

  • The unanswered sorting option for a tag sorts questions very differently than the options available in the Unanswered Questions list (I believe it's # answers ascending then score descending). They're completely different ways of browsing the lists.
    – animuson StaffMod
    Commented Jan 23, 2013 at 7:51
  • 2
    Yep can reproduce. This one results in [c] while this results in [c++] as it should. Commented Jan 23, 2013 at 7:55
  • @animuson Confused. Is there documentation? Which way is used for what? Commented Jan 23, 2013 at 7:57
  • @Potatoswatter: Just use them? You don't really need to document something that you can just browse and learn about it yourself. The options you get in the Unanswered Questions list are newest, votes, and no answers. None of those are used for sorting the unanswered tab from the normal Questions list. It's just a different way of sorting.
    – animuson StaffMod
    Commented Jan 23, 2013 at 8:00
  • @animuson that's not relevant. Same URL for tag name which works fine under Questions page is not working in the Unanswered page, there is indeed some bug behind the scenes in parsing the tag name. Added screenshots to make it more clear. Commented Jan 23, 2013 at 8:05
  • @ShaWizDowArd: He asked why there was a separate tab there at the end, and I was just explaining it. I realize it has nothing to do with the bug above it.
    – animuson StaffMod
    Commented Jan 23, 2013 at 8:06
  • @animuson oh sorry, thought you were trying to explain the bug. :) Commented Jan 23, 2013 at 8:07

2 Answers 2


Interesting; it looks like we (ok: me) added some code to "fix" (cough) that route after is was misbehaving locally. It looks like the various IIS versions (including express) process a path with non-trivial values slightly differently. But if the non-trivial values are in the query, all is well. I've removed the "fix", so that it will play nicely on prod - should be fine in a few minutes.

It actually reminds me of this slightly-related "feature", which MS claim to have now fixed (presumably on new OS versions, because it isn't fixed for us!) - in which case we might need to revisit this in future, if MS's new fix breaks it for us! All fun.

  • Wow uber-ultra-fast fix! So, you blame Microsoft for this? :-P Commented Jan 23, 2013 at 8:34
  • 1
    @ShaWizDowArd no, I blame me first, for breaking prod. Then Microsoft, for having it behave differently on different platforms. Commented Jan 23, 2013 at 8:35
  • 1
    Well, you can't possibly have all possible platforms on dev - really can't blame you. Coming from a fellow prod breaker maybe I'm a little biased though. :) Commented Jan 23, 2013 at 8:42

Try this link:


It works here.

  • Yeah, already noticed and edited the question. The bug still stands, and I'm confused why the part of the website that contains the bug even exists. Commented Jan 23, 2013 at 7:48

You must log in to answer this question.

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