Reg CSP for 302 and 301s | Community
Skip to main content
Level 2
July 16, 2026
Question

Reg CSP for 302 and 301s

  • July 16, 2026
  • 2 replies
  • 34 views

Hi Folks,

 

Currently we have CSPs implemented for all 200s but we need it for all 302s and 301s redirections also to achieve full compliance for Content Security Policys.

 

I have included below line (marked in BOLD) in the site_cloud_publish.vhost file.

 

Header set Content-Security-Policy "upgrade-insecure-requests; frame-ancestors 'none'; script-src blob: 'unsafe-inline' 'unsafe-eval' 'self' https://xyz.xyz.com https object-src 'none'"Header always setifempty Content-Security-Policy "upgrade-insecure-requests; default-src 'none'; frame-ancestors 'none'; base-uri 'self';" "expr=%{RESPONSE_STATUS} =~ /^30[1278]$/"<If "-n %{QUERY_STRING}">

 

but while deploying the dispatcher module, i am getting warning and deployment is failing.

Could you help me in thi? 

 

Thanks in advance.

 

Regards,

Shikha

2 replies

chaudharynick
Level 4
July 16, 2026

Hi ​@ShikhaSo6 

The reason your Dispatcher deployment is failing is due to a strict syntax validation error in your Apache expression.

 

The Root Cause

In your condition, you used the variable %{RESPONSE_STATUS}"expr=%{RESPONSE_STATUS} =~ /^30[1278]$/"

While this naming makes logical sense, Apache 2.4 does not recognize %{RESPONSE_STATUS} as a valid variable in its expression parser. The correct native Apache variable for checking the HTTP status code (even for responses) is actually %{REQUEST_STATUS}. Because the Cloud Manager/Dispatcher validator (httpd -t) encounters an unknown variable, it throws a fatal syntax error and fails the deployment.

The Solution

The Inline Fix (Recommended for your current setup) Simply change RESPONSE_STATUS to REQUEST_STATUS.

ShikhaSo6Author
Level 2
July 17, 2026

Thanks Nick for helping me out. After successful deployment, still CSPs are not getting applied for 302s. Do you have any idea why this might be happening.

 

lavishvasuja
Level 4
July 19, 2026

@ShikhaSo6 -

I would probably start by checking where the 301/302 is actually being generated. If the redirect is happening before the Dispatcher/vhost layer—for example at the CDN, load balancer, or another proxy—the CSP configured in site_cloud_publish.vhost won't be applied to that response.

Maybe we can check the first 301/302 in the Network tab or with curl -I and look at the response headers along with the Location header. That should help confirm whether the response is actually passing through Dispatcher and whether the REQUEST_STATUS condition is being evaluated.

If you're still seeing deployment warnings as well, could you share the exact error? That would help determine whether there's still a configuration issue in addition to the runtime behavior.