XML Variable Substitution changes "'" to "'" in customHeaders section

[phleebagg]

[AGENT_MACHINENAME] --> [factoryvm-az391]
[AGENT_NAME] --> [Hosted Agent]
[AGENT_OS] --> [Windows_NT]
[AGENT_ID] --> [5]
[AGENT_VERSION] --> [2.131.0]

Task: Azure App Service Deploy
Version: 3.3.45

Before transform:
<add name="Content-Security-Policy" value="default-src 'self' 'unsafe-inline' 'unsafe-eval';"/>

After transform:
<add name="Content-Security-Policy" value="default-src &apos;self&apos; &apos;unsafe-inline&apos; &apos;unsafe-eval&apos;;"/>

Edit: Some further clarification:
The above element is in the system.webServers/customHeaders section, which is not accessible via variable substitution (which is fine and as expected).

My expectations were that there would be no modifications to the config beyond the variables being applied. The above changes to the Content-Security-Policy element causes the header to not be included in responses, which is unacceptable.

[vincent1173]

@phleebagg , thanks for reporting the issue. This is a limitation we have in the substitution.
As a work-around, Can you try substituting the Content-Security-Policy with the same value default-src 'self' 'unsafe-inline' 'unsafe-eval'; ? In this way, the old value is retained.

[phleebagg]

I have tried doing so both with a Release scope variable and an environment-specific variable. Neither was applied, leaving the ' value.

[vincent1173]

@phleebagg , To debug the issue, Can you please share the web.config file (mask the secrets) to [email protected] ?

[phleebagg]

Files (web.config before and after substitution) sent.

[vincent1173]

@phleebagg , it's a genuine issue and we are currently working on the fix.
As a workaround, Can you please the substitution with XML transformation?

[phleebagg]

The use of a config transform would probably work, however I am already using XML variable substitution for connection strings and other values at this time. I'll continue to use a manual edit post-release as a workaround for now.

[vincent1173]

@phleebagg , the issue is fixed and the fix will be available in upcoming deployment (~3-4 weeks)