Sp-dev-docs: SPHttpClient.get Error 404 with ambiguous end point URL (2x concatenated [tenantName].sharepoint.com)

[nateforsyth]

Category

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

A little background

We have an SPFx WebPart that is deployed tenant wide. Currently we have Lists on various Site Collections that the WebPart can interface with (not all). We override the site url where necessary to render List items from a different Site Collection - useful for sharing the items.

This functionality works on all Modern Site Collections (/sites/[siteName]).

I am encountering an issue where the site collection URL appears to be being concatenated with 2x [tenantName].sharepoint.com. This is obviously causing the 404. See below:

https://[tenantName].sharepoint.com/[tenantName].sharepoint.com/sites/[siteName]/...

It appears to be an issue in these scenarios (Classic site collections):

• Site built on the root of the tenant (I cannot control this, it's a client environment).
• Sub Sites built off of the Site built on the root of the tenant.

Expected or Desired Behavior

I expect the SharePointQueryableCollection.toUrlAndQuery() result to correctly propagate to my SPHttpClient.get invocation when using SharePointQueryableCollection.toUrlAndQuery().

I expect to be able to receive the normal XML content with a 200 response, so that I can continue to process the data and build the objects for the WebPart to function.

Observed Behavior

We create a SharePointQueryableCollection using Web.lists.getByTitle within TypeScript.

Upon building the SharePointQueryableCollection I am outputting the URL to the console, which looks as expected (you'll note other properties here, which I don't show in the code block for brevity).

this is from this line in the code block below: // this outputs expected URL

https://[tenantName].sharepoint.com/sites/[siteName]/_api/web/lists/getByTitle('Some Links')/items?$select=*&$filter=LinkActive eq '1'&$top=10&$orderby=OrderBy asc&$expand=FieldValuesAsText

I can paste that URL into the browser and it will resolve to the XML results as expected.

I receive the 404 upon invocation of SPHttpClient.get(query.toUrlAndQuery(), SPHttpClient.configurations.v1), and the error message output shows the URL has been changed to have 2x [tenantName].sharepoint.com absolute URLs.

https://[tenantName].sharepoint.com/[tenantName].sharepoint.com/sites/[siteName]/_api/web/lists/getByTitle('Some Links')/items?$select=*&$filter=LinkActive eq '1'&$top=10&$orderby=OrderBy asc&$expand=FieldValuesAsText

This occurs just after I have output the correct URL to the console, somewhere within SPHttpClient (or subsequent libraries).

I traced this to row 1078 within the following file:
https://spoprod-a.akamaihd.net/files/sp-client-prod_2019-05-03.013/sp-webpart-workbench-assembly_en-nz_7406634b0941d8c00c9dd43590016f94.js

Which appears to fail where indicated here (note the comment FAILS HERE):

function n(e, t) {
                  function r() {
                      this.constructor = e
                  }
                  S(e, t), e.prototype = null === t ? Object.create(t) : (r.prototype = t.prototype, new r)
              }
              Object.defineProperty(t, "__esModule", {
                  value: !0
              });
              var o, i = r(0),
                  s = (function() {
                      function e(e) {}
                      return e.prototype.fetch = function(e) {
                          return window.fetch(e) // FAILS HERE
                      }, e
                  })(),

Steps to Reproduce

Using the Workbench on a Classic sub-site, build a SharePointQueryableCollection, and then invoke SharePointQueryableCollection.toUrlAndQuery() outputting to the console, noting that the URL is as expected.

Paste the URL into your browser, you should receive XML data from the List.

Invoke SPHttpClient.get(SharePointQueryableCollection.toUrlAndQuery(), SPHttpClient.configurations.v1) noting that you will receive a 404 and the failed URL will include 2x concatenated [tenantName].sharepoint.com in the string.

Here's an elided version of our invocation code, you'll note that it is a very simple example, however the issue I am experiencing crops up at the SPHttpClient.get invocation where I do not have the experience to debug further unfrotunately.

public getLinksInList(/* elided for brevity */): Promise<IItems> {
    const query: SharePointQueryableCollection = this.urlHelper.buildSPOListUrlForQuery(/* elided for brevity */);

    if (trace) {
      console.log(query.toUrlAndQuery()); // this outputs expected URL
    }

    //  the this.httpClient.get invocation is where it fails
    return this.httpClient
      .get(query.toUrlAndQuery(), SPHttpClient.configurations.v1) // I lose visibility here, this is where the 404 is encountered
      .then((response: SPHttpClientResponse) => {
        if (response.ok) {
          return response.json().then((responseFormatted: any) => {
            const formattedResponse: IItems = { value: [] };

            // elided for brevity

            return formattedResponse;
          }, (err: any): void => {
            // elided for brevity
          });
        } else {
          // elided for brevity
        }
      }, (err: any): void => {
        // elided for brevity
      }) as Promise<IItems>;
  }

[msft-github-bot]

Thank you for reporting this issue. We will be triaging your incoming issue as soon as possible.

[patmill]

Does the issue only happen on the root site collection?

Also - to confirm - the SharePointQueryableCollection is from a PNP library, not from SPFx itself, correct?

[nateforsyth]

Does the issue only happen on the root site collection?

This is very difficult to confirm. I've only seen this occur on the root site collection, however they're not overly common where I work to try on another sorry.

Also - to confirm - the SharePointQueryableCollection is from a PNP library, not from SPFx itself, correct?

Indeed, node_modules\sp-pnp-js\lib\sharepoint\sharepointqueryable.d.ts to be precise.

[nateforsyth]

Hi guys,

It appears that pnp _may_ be using the token /sites/ for validation of the current web within pnp.

I've encountered this same issue with SPFx extensions.

• The root site is encountering this double [tenantName].sharepoint.com concatenation.
• a sub-site off of the root site is encountering this double [tenantName].sharepoint.com concatenation.
• any site with /sites/ within the window.location.href works as intended.

I created a sub-site under a normal site using the /sites/[siteName]/[subsiteName] pattern and it worked as I expected as well.

[nateforsyth]

To throw a spanner into the works, https://[tenantName].sharepoint.com/search works as I'd expect using the same pnp libraries (I believe).

The difference here is that the package we've built for /search isn't SPFx (classic, it's vanilla React using pnp to interface with SharePoint due to the inability to use the top and bottom placeholders available in modern).

I'm starting to think this issue is something to do with how SPFx handles the pnp modules (or more likely the other way around).

[andrewconnell]

I'm not seeing this in the SPFx API.

Can you log the output of query.toUrlAndQuery() and look at what's generated? If that's being generated by PnPJS, then I think the issue is more appropriate in the PnPJS repo's issue list, not within this issue list.

The SPFx API SpHttpClient.get() method expects an absolute URL to the endpoint you want to issue the request. If it's getting something else, then that's the issue...

[nateforsyth]

I'm not seeing this in the SPFx API.

Can you log the output of query.toUrlAndQuery() and look at what's generated? If that's being generated by PnPJS, then I think the issue is more appropriate in the PnPJS repo's issue list, not within this issue list.

The SPFx API SpHttpClient.get() method expects an absolute URL to the endpoint you want to issue the request. If it's getting something else, then that's the issue...

Hi @andrewconnell thanks for your reply

In my post above you'll note I was outputting to the console with:

    if (trace) {
      console.log(query.toUrlAndQuery()); // this outputs expected URL
    }

With the result of:

this is from this line in the code block below: // this outputs expected URL

https://[tenantName].sharepoint.com/sites/[siteName]/_api/web/lists/getByTitle('Some Links')/items?$select=*&$filter=LinkActive eq '1'&$top=10&$orderby=OrderBy asc&$expand=FieldValuesAsText

The URL resolves within the browser correctly, we receive the XML we expect to see.

That is immediately passed into the invocation of SPHttpClient.get(query.toUrlAndQuery(), SPHttpClient.configurations.v1) and I receive the 404.

Can you confirm please that this shouldn't be reported here?

Thanks again.

[andrewconnell]

@nateforsyth said

Can you confirm please that this shouldn't be reported here?

Yup... if that's the URl you're sending the SPFx API, it won't work. Those token replacements don't happen in the SPFx API.

IOW, it's coming from an upstream library you're using. If that's PnPJS, then you should post the question there.

[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