Force application of authorization header can break extensions that require their own authorization header.

[DakotaWray2]

In chat-api-dynamic-extensions.ts there is the following code.

// we need to add the user id to the headers as this is expected by the function and does not have context of the user
headerItems.push({
  id: "authorization",
  key: "authorization",
  value: await userHashedId(),
});

In my use case I am connecting to the Azure DevOps API. The API requires an 'Authorization' header with a personal access token issued by DevOps.

The current logic would apply two headers (authorization + Authorization) which breaks the api call.

Recommend we look at refactoring the requirement for that forced authorization header to help support more api call scenarios.

Thanks again for the great repo!

[fsch-ppi]

I do not even understand why this is a requirement - I mean the authorization header to be there.
Which function requires it?

[DakotaWray2]

chat-api-rag-extension.ts defines userId from the authorization header and passes it to CreateCitations(). There may be something else I am missing. For now I added a check to only push the authorization header if my extension does not have one defined.

Though if an api has cors options allowedHeaders defined and does not allow authorization it will reject even if unused I think.

[fsch-ppi]

Ah, I see.
I am using a different way of using Azure AI Search - not the extension that they propose. This is why the authorization header they set does not matter for my team.

Thanks for clearing it up though! Now I can remove it without having to worry at all. All restful API's I used so far just ignored the extra header.