I am getting 400 bad request when provider hosted app is trying to connect to SharePoint.Below is the stacktrace:

System.Net.WebException: The remote server returned an error: (400) Bad Request.
   at System.Net.HttpWebRequest.GetResponse()
   at Microsoft.SharePoint.Client.SPWebRequestExecutor.Execute()
   at Microsoft.SharePoint.Client.ClientRequest.ExecuteQueryToServer(ChunkStringBuilder sb)
   at Project.SharePoint.Web.Controllers.HomeController.GetLoggedInUserName()

The server logs shows that /_vti_bin/client.svc/ProcessQuery is giving me 400 bad request.

I have tried to connect to the client.svc from browser of the server where the MVC provider is installed and it works, so there is no access issue. Any help would be great.


        public string GetLoggedInUserName()
            string userName = string.Empty;

                User spUser = null;

                var spContext = SharePointContextProvider.Current.GetSharePointContext(HttpContext);

                using (var clientContext = spContext.CreateUserClientContextForSPHost())
                    if (clientContext != null)
                        var web = clientContext.Web;
                        spUser = web.CurrentUser;
                        clientContext.Load(spUser, user => user.Title);
                        userName = spUser.Title;

            return userName;
  • Can you show the code located at HomeController.GetLoggedInUserName()?
    – wjervis
    Commented Aug 11, 2015 at 16:46
  • Added it is the same code which gets loaded when selecting the Provider hosted app MVC template
    – Unnie
    Commented Aug 11, 2015 at 16:50
  • Ah, I have no knowledge of high trust apps, but perhaps using SharePointHighTrustContextProvider instead of SharePointContextProvider? It's a complete guess, I just remember seeing classes specific to acs and high trust the other day when I perused the SharePointContext.cs file.
    – wjervis
    Commented Aug 11, 2015 at 17:04
  • @wjervis SharePointContextProvider handles both Acs and High trust instances. So don't think that's the issue.
    – Akhoy
    Commented Aug 11, 2015 at 17:34
  • 1
    @uberz91 Ah, like I said, a complete guess. Perhaps a configuration issue then.
    – wjervis
    Commented Aug 11, 2015 at 17:35

1 Answer 1


To debug this, I would suggest that you setup Fiddler on the Remote Web, and then modify the web.config to have these lines (make sure to take these out when you are done debugging)

    <proxy  proxyaddress="" />      

This will make Fiddler a proxy for your web application, so that you can see the OAuth2 and ProcessQuery calls.

With Fiddler running, access the problem page. Then, go to Fiddler, and find a url that looks like this: /vti_bin/client.svc/ProcessQuery

Click on this url in Fiddler, and then click on the "Inspectors" tab on the top right. You should see a Request that was sent as XML and a response sent in JSON (you might want to start with the "RAW" view, then switch to "XML" and "JSON".

In the JSON response, look to see if there is an "error" and also an "error_description". Hopefully these will give you clues as to what went wrong. If not, try looking at some of the previous requests/responses in Fiddler (e.g. /vti/bin/client.svc) to see if there are any errors there.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.