Consider making HttpClient features opt-in

[wictorwilen]

The HttpClient (@microsoft/sp-client-base) always add a "odata-version":"4.0" header to all requests. This makes requests to for instance the SharePoint Search API endpoint to fail (HTTP 500).

Please remove this automatic addition of the header.

[vman]

For now, you can manually add the odata version 3.0 in the headers:

const reqHeaders = new Headers();
    reqHeaders.append('odata-version', '3.0');

    return this.context.httpClient.post(
    `${this.context.pageContext.web.absoluteUrl}/_api/SP.UserProfiles.PeopleManager/SetSingleValueProfileProperty`,
      {
        body: JSON.stringify(postBody),
        headers: reqHeaders
      })
    .then((response: any) => {
        return response.json();
    });

[wictorwilen]

Yes, we know that is a workaround. Or just adding an empty string as value.

[patmill]

At the same time, we should follow up with the search end points to support OData v4 as well. Consistency and all that.

[wictorwilen]

Which one do you think is fastest, you fixing a few lines of TypeScript or a DCR for SharePoint 😜

[patmill]

So cruel.

Also - a discussion is going on here as well for people that are hitting this. http://sharepoint.stackexchange.com/questions/191340/how-to-supply-a-querytext-parameter-to-the-search-rest-api-without-receiving-an

[octogonz]

At present, this behavior is "by design", and the workaround you suggested is the intended usage.

We have been considering a design change where all the HttpClient "magic" would be opt-in, e.g. via an enum bitfield maybe with an HttpClientOptions.DefaultsV1 that captures the current set of features. This would serve several purposes:

1. More explicitly document the magic features that are happening behind the scenes
2. Give us the ability to introduce new features in the future without breaking existing code (e.g. by adding a DefaultsV2 constant)
3. Give developers an easier way to opt-out, e.g. by defining their own bitfield constants

Your example above would change to look something like this (pseudocode):

enum HttpClientFeatures {
  FetchRequestDigest = 1<<0,
  ODataVersion4 = 1<<1,
  AcceptHeader = 1<<2,
  ContentTypeHeader = 1<<3,
  DefaultsV1 = FetchRequestDigest|ODataVersion4|AcceptHeader|ContentTypeHeader
}

const httpClientFeaturesForSearch = HttpClientFeatures.DefaultsV1 & ~HttpClientFeatures.ODataVersion4;

return this.context.httpClient.post(
    `${this.context.pageContext.web.absoluteUrl}/_api/SP.UserProfiles.PeopleManager/SetSingleValueProfileProperty`,
      {
        features: httpClientFeaturesForSearch,
        headers: {
          'OData-Version': '3.0'          
        },
        body: JSON.stringify(postBody)
      })
    .then((response: any) => {
        return response.json();
    });

"Opt-in" would mean that if you omit the "features:" parameter, then you would get the vanilla BasicHttpClient behavior.

What would you think of this approach?

[octogonz]

VSO 239957

[wictorwilen]

@pgonzal: I like it!

[sebastianrogers]

As a user my feelings are that:

• If its 'magic' then it should always work and explicitly passing an 'empty' parameter to get around it feels odd.
• If there is an 'opt-in' for the magic then I would want it on by default.
• I want control at a lower level than my web part, so for some calls I might want the magic and for some I might not.

Therefore I'd ideally like:

• An 'opt-out' setting I can pass to each function call, i.e. 'no-magic' or 'magic-version-x' with the default being 'magic-version-latest'.
• The parameter to be mandatory so I have to make an informed choice each time.

Just my tuppennies worth.

Sebastian