Verify the Axis web server restart boundary after a header change

Bottom line: Verify the emitted HTTP response after the documented application boundary, and preserve the headers that existed before the change.

Source fact: documented behavior

The Custom HTTP header API documentation says some devices ship with preinstalled custom HTTP headers and that the list method shows the headers.

It also says those preinstalled headers can be removed through the remove method.

In its CORS and Set-Cookie examples, the documented new header is included in web-server responses once that server has been restarted.

What the source does not establish

Treat the examples as an interface behavior to confirm for the deployed device and software. Do not infer that a proposed CORS, cookie or framing policy is appropriate merely because the API accepts a header. Keep policy review separate from application of the configuration. Obtain the supported restart procedure and an approved interruption window rather than inventing a restart command.

Applicability questions

• Which existing custom headers must remain after the change?
• What policy owner approved the exact proposed header and value?
• Which documented restart or application procedure applies to this device?
• Which direct response and client workflow will establish the intended result?

DSE recommendation: controlled next steps

The following steps are DSE recommendations based on the cited source.

DSE recommends treating a custom-header change as a before-and-after response comparison with a controlled application step.

1. Read and preserve the existing custom-header configuration before proposing an edit. Identify the exact header to change and the reason for it. Ask the responsible application or security owner to review the value. Avoid bulk removal of preinstalled entries as a way to obtain a clean-looking configuration, especially when their operational purpose has not been established.
2. Use a representative supported test device. Apply the approved change through the documented interface, then follow the manufacturer-supported web-server restart procedure in an authorized window. Preserve the configuration result and the restart timing separately. Do not classify an unchanged pre-restart response as proof that the final configuration is wrong without examining the documented application boundary.
3. Capture a fresh response directly from the device and exercise the intended client workflow. Compare the approved value and preserved headers with the observed response. Investigate any unexpected difference before adding compensating headers in another layer. If the change disrupts the required application, restore the accepted configuration through the supported procedure and document the reason.

Verification and evidence

Retain the sanitized original and proposed header lists, approval of the policy value, device/software identity, application-step timing and before-and-after response captures. Protect cookies or other sensitive values when sharing diagnostic evidence. Record whether the direct response and intended client behavior each match the approved expectation.

For the proposed rehearsal, include a configuration check before the application step and an actual response check after it. Keep those results on separate lines so a later operator can locate the boundary. This article reports no browser compatibility test, security-policy assessment or observed device restart.

Official references

• Custom HTTP header API — Axis Communications; official VAPIX documentation.

Source review completed October 28, 2026. Recheck the official documentation and the deployed device’s capabilities before changing production settings.