Workaround for April 2014 CU and MS14-022 Double Encoding Bug

9/9/2014 Update:

This issue is resolved in the SharePoint 2013 September 2014 Cumulative Update. Please use the CU instead of applying the below workaround.

————-

The April 2014 Cumulative Update and MS14-022 introduced a “double encoding” issue that caused search results with %5C (the “\” character) to become double encoded (represented as “%255”). This caused broken links. This bug persists in the June 2014 Cumulative Update.

As a workaround, you can edit a few files in the 15 hive. This is a temporary workaround where the issue is a critical impact to your business.

You will want to edit two files, Search.ClientControls.js and Search.ClientControls.debug.js. Both files are located in C:\Program Files\Common Files\microsoft shared\Web Server Extensions\15\TEMPLATE\LAYOUTS\ and I’d strongly suggest backing both files up to an alternate location so they can be restored prior to a final fix being released by Microsoft.

Edit Search.ClientControls.debug.js first. This file is used when debugging in the browser, so it is easier to read and will help you understand what needs to be edited in the non-debug version.

Find the following block of text:

The encodeURI is a native function that is causing the double encoding issue. This is a fairly simple fix, just remove the encodeURI function and save the file. The block of text will look like this:

The next step is to edit the non-debug version of the file. This one you’ll want to be careful with as it isn’t formatted as nicely. Search for “encodeURI” in Search.ClientControls.js:

Next, remove encodeURI, carefully removing the opening parenthesis and closing parentheses for both method calls:

Refresh your browser (you may need to clear your browser’s cache), and the URLs, at least for People searches, will be correct. Other scenarios should be correct, but my lab is not set up to test them.

35 Comments

  1. Valerian Heints

    worked perfectly

  2. Good solution, this can be achieved through editing display template. What do you think should be ideal approach to handle this, going directly to 15 hive or managing through Display Templates?

    • Only certain scenarios can be managed through Display Templates, hence this workaround. Also, Display Templates are Site Collection-by-Site Collection modifications, where-as this is Farm wide. Both solutions must be reversed before applying the next update provided by Microsoft. Editing files in the hive should not be done, but this is a quick-fix with a quick and easy way to revert the change, once a proper fix is released.

      • Thanks. very useful Info. Just curious to know, how this bug trouble shooting went to finally found this root cause.
        Best
        Vinu

  3. Thanks for this Trevor- I had stared at the URL until I saw the double-encoding and then ended up here. A couple thoughts:

    1.Did you notice that that block of code in the Debug, is pretty much the only code with comments in that whole file? The style and existence of the comments at all seems a bit out place with production, billion dollar SharePoint codebase, don’t you think? Just an oddity IMO, which may or may not explain the genesis of this bug in the first place. Seems like an indicator this chunk of code may have slipped in inadvertently as opposed to an engineering defect.

    2.Instead of just removing the encodeURI wrapper, would it not be a safer bet to replace the encodeURI, with the $htmlencode function derived from SP.Utilities.HttpUtility.htmlEncode, which is used later in the same function? In looking at what the htmlEncode function does in Reflector, it seems to be quite intelligent and specifically geared for SharePoint (as one would expect).

    Client side validation being vulnerable to tampering of course, I would think we’d want to go with encoding vs no encoding at all, if possible. I tried swapping out the encodeURI for $htmlencode, and my very limited tests show it solve this particular bug scenario with the people.aspx querystring, and doesn’t seem to introduce any breakages. Whatcha think?

  4. This only partially worked for me. It worked from a browser on the 2013 server itself but not from any other machine connecting to it.

  5. That is what I first believed to be the issue but I tried 5 different machines with 2 different browsers and clearing the caches did not work. On the server itself, I did not even need to clear the cache for it to register the correction and the reversion.

  6. Thanks for the workaround – works great for us.

    Do you happen to know if this issue is fixed in the July 2014 CU?

  7. I got word that it will be fixed in the next CU and this work around should be unaffected. But this is an amazing fix. Thank you. Definitely a life saver.

  8. Pingback: Workaround for April 2014 CU and MS14-022 Double Encoding Bug | SPTechLearn

  9. I installed the august 2014 cu. Bug still exists. can anyone else confirm that?

  10. A related double-encoding bug exists in links for account names, but it occurs only in IE9. A colleage of mine has blogged about it: http://tech.bool.se/rare-bug-sharepoint-ie9-account-names-commas/

  11. Consider to solve this issue without updating the hive: http://chuvash.eu/2014/09/01/do-not-mess-with-the-hive/ – my new blog post.

    • The problem with this approach is it is targeted, rather then global. In addition, working with GBS they are OK with this manual workaround until the September CU is released.

      • If they are ready to compromise the integrity of the SharePoint product, then it is a solution (You always to to compromise when working with SharePoint :) ), but I wouldn’t recommend this “global” solution for production environments.

        • There is no compromise to the integrity of the installation. The files will be replaced with the fixed versions from the Sept CU. Strictly speaking, editing files in the hive is not unsupported, simply not recommended as your changes may be lost with any update made to those files via patching, which is exactly what we want to happen in this case.

  12. Pingback: Do not mess with the hive - Bool Tech

  13. Hi Trevor

    I am seeing this problem on the videoplayerpage.aspx in SharePoint 2013. When I click a video to play it brings up this page, alongside this page on the right is a name and photo of a staff member. The photo url here has the double encoding, for example – http://my.contoso.com/User%2520Photos/Profile%2520Pictures/joe_bloggs_MThumb.jpg

    How do I fix this? Will the above procedure work here too?

    Thanks Trevor.

    Yoshi.

  14. Hi Trevor,
    Does this need to be done on all the servers in the farm or just specific ones?

  15. The propblem even exists after installing the cu from september 2014. Anyone who can confirm that?

  16. Yes, I can confirm it. On our Sharepoint the problem is still there. File date is 8/12/2014.

  17. Pingback: Sharepoint 2013 Search – broken results with special chars (ä, ö, ü) | bernd-mareth.de/blog

  18. Trevor, thanks so much for this fix. Totally worked in my environment. Plan to install September CU eventually, do I need to do anything with these 2 files before deploying september cu or can i just deploy and it overwrites these 2 files?

    Thanks so much

  19. Hello, Strange thing is that i can’t clearly see on the CU page where it states that the problem with the double coding is fixed, could you tell me exactly where it is? Thanks!

  20. Trevor, I have seen that you recommend the September 2014 CU solves the double encoding issue, but it didn’t work on our servers. This workaround helps me to solve my issue. Thanks a lot Trevor!!!

Leave a Reply