Sp-dev-docs: 🐞 SpHttpClient returns XML when JSON requsted

[andrewconnell]

Category

• [ ] Question
• [ ] Typo
• [X] Bug
• [ ] Additional article idea

Expected or Desired Behavior

Using SpHttpClient to GET data from a SharePoint list in the current site, when specifying JSON in the ACCEPT header should return JSON in the response body.

Observed Behavior

It's returning XML... regardless of the ACCEPT header, which triggers an error when calling the json() method on the response returned due to unexpected < character.

Steps to Reproduce

When running the following request from a within a modern SPList.

  const spQuery: string = `${this.context.pageContext.web.absoluteUrl}/_api/web/lists/getbytitle('SpaceX Missions')/items(${itemId})?$select=Id,Title,Links`;
  this.context.spHttpClient.get(spQuery,
    SPHttpClient.configurations.v1,
    {
      headers: {
        'Accept': 'application/json;odata=verbose',
        'odata-version': ''
      }
    })
    .then((response: SPHttpClientResponse) => {
      console.debug(`${LOG_SOURCE} sp response`, response);
      return response.json();
    })
    .then((listItem: ISpaceXMissionSpListItem) => {
      console.debug(`${LOG_SOURCE} sp item`, listItem);
    })
    .catch((error: any) => {
      console.error(`${LOG_SOURCE}`, error);
    });

The request headers look just fine:

GET /sites/developersite/_api/web/lists/getbytitle('SpaceX%20Missions')/items(1)?$select=Id,Title,Links HTTP/1.1
Host: acio365dev.sharepoint.com
Connection: keep-alive
accept: application/json;odata=verbose
odata-version:
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.115 Safari/537.36
Referer: https://acio365dev.sharepoint.com/sites/developersite/Lists/SpaceX%20Missions/AllItems.aspx?loadSpfx=true&debugManifestsFile=https://localhost:4321/temp/manifests.js&customActions={%226a909524-f364-445f-aa4a-8889e42cb0a4%22:{%22location%22:%22ClientSideExtension.ListViewCommandSet.ContextMenu%22}}
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.8
Cookie: <snip>
If-None-Match: "3"
If-Modified-Since: Fri, 04 Aug 2017 17:19:01 GMT

By the way, I've tried using nometadata for the ACCEPT header as well... no effect.

But inspecting the request in the browser dev tools, I can confirm that XML is returned.

Using v1.1.1 of @microsoft/sp-http & tried on dev tenant with first release enabled.

[andrewconnell]

Furthermore, I've tried tweaking the header properties but nothing impacts the payload... it's always XML coming back.

Tried:

'Accept': 'application/json;odata=verbose'
'Accept': 'application/json;odata=nometadata'
'Accept: 'application/json;odata.metadata=none'
'odata-version': ''
'odata-version': '4.0'

[bcameron1231]

@andrewconnell Could this be a caching issue? Here is what I have done to replicate the issue. I accidentally made a request using the wrong headers (minimal isn't a part of 3.0 spec and I think the libraries max service version is 3.0).

headers: {
        'Accept': 'application/json;odata=minimal',
        'odata-version': ''
      }

This request returned an XML Response back. I updated my code and did a gulp build, serve

headers: {
        'Accept': 'application/json;odata=verbose',
        'odata-version': ''
      }

I reloaded the CommandSet. The javascript that was loading in Dev Tools was correct. This was the header

accept:application/json;odata=verbose
Accept-Encoding:gzip, deflate, br
Accept-Language:en-US,en;q=0.8
Connection:keep-alive
Host:bcameron.sharepoint.com
odata-version:

Everything looks fine, however, the result that came back was XML. I cleared my browser cache, and refresh and I got the correct result set in JSON. It's as if the call or the response was cached, even though the code was correct.

I found this out because I was testing between nometadata and verbose. If I make a nometadata call, change my code to verbose and refresh without clearing my cache, I get a result set with nometadata.

[andrewconnell]

Very strange... with no code changes, it's working now... closing this issue but perplexed...

[shaipetel]

@andrewconnell you are not alone... had the exact same thing and only a reload with clearing all cache resolved (in chrome, right-click the refresh button and choose "empty cache and hard reload").

Here is exactly what caused it for me:

1. had a user with no permissions to site, but only to one list.
2. made a rest request to get that list info
3. request resulted in access denied.
4. disabled "Limited-access user permission lockdown mode" site collection feature
5. checked request in the browser (just open it in a tab) - getting XML valid response
6. making API calls returned XML, so the JSON was null.

thanks for this - it saved me hours of frustration!
Maybe these repro steps can help the team figure it out? or is it a browser issue? I doubt it is a browser issue since it is not cache - the first requests returned access denied error, not the XML I was getting...

[dsm0880]

@andrewconnell Hey, I've been trying to track down a similar issue which is occurring with me right now. Hopefully it is enough reason to re-open this.

I'm sitting here able to reproduce what I deem is a caching issue as well, in my instance it is modifying the OrderBy field in the ViewXML of a RenderListDataAsStream call. I know the query is correct because when I make it through Postman the correct results come through, but when I go through the browser they do not. I was able to track down the issue to the 'User-Agent' header that is automatically applied to outgoing browser requests. If I add it to my call in Postman then sure enough I get the same results as the browser.

User-Agent: User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/77.0.3865.120 Safari/537.36

Now if I backspace all the way to 'Mozilla/5.0' the issue occurs, but the second I delete anything further then it is resolved, likely due to the fact that it is an invalid User-Agent.

When you try to reproduce you likely won't be able to as I have multiple site collections where this exact same scenario is not an issue.

I'm hoping the SharePoint team can try to track this down or help out. Also happy to open a new ticket as I understand I went a little outside process by commenting on this.

[msft-github-bot]

Issues that have been closed & had no follow-up activity for at least 7 days are automatically locked. Please refer to our wiki for more details, including how to remediate this action if you feel this was done prematurely or in error: Issue List: Our approach to locked issues