HTTP

HTTP-related global settings — compression, proxy/load balancer headers, response cache, output, and DW9 template compatibility.

The HTTP node groups the global settings that govern how Dynamicweb produces and serves HTTP responses — compression and minification of the response body, handling of forwarded headers from a reverse proxy, the static-file response cache, output tweaks for base href and the performance comment, and the DW9→DW10 template-compatibility switches.

HTTP compression

These settings control how the rendered HTML response is shrunk before it leaves the server. Compression is applied per-response based on the request's Accept-Encoding header; minification rewrites the markup itself.

Setting	Setting path	Use
Use HTTP compression	/Globalsettings/System/Http/Compression	Enables ASP.NET Core response compression. The encoding (Brotli, gzip, …) is negotiated automatically from the client's Accept-Encoding header — there is no longer a separate algorithm picker. Leave on unless a downstream layer (IIS, nginx, CDN) is already compressing and you want to avoid double work.
Minify HTML	/Globalsettings/Settings/Performance/MinifyMarkup	Strips redundant whitespace and line breaks from rendered HTML before it is written to the response. Reduces payload size at a small CPU cost.
Remove empty lines in HTML	/Globalsettings/Settings/Performance/RemoveEmptyLines	Lighter alternative to full minification — removes lines that contain only whitespace, but keeps indentation on lines that contain content. Useful when partners want readable view-source but still want to trim Razor-generated blank lines.

Proxy and load balancing

When Dynamicweb runs behind a reverse proxy (nginx, IIS ARR, Azure Application Gateway, Cloudflare, etc.) or a load balancer, the request that arrives at the application originates from the proxy, not from the end user. This means:

• HttpContext.Connection.RemoteIpAddress contains the proxy's IP, not the visitor's IP.
• HttpContext.Request.Scheme is http even when the visitor used https.
• HttpContext.Request.Host may be an internal hostname, not the public one.

Proxies communicate the original values through forwarded headers — typically X-Forwarded-For, X-Forwarded-Proto, and X-Forwarded-Host. The settings in this section control how Dynamicweb reads and trusts those headers.

Typical scenarios:

Deployment	Recommended configuration
Direct internet, no proxy	Leave Enable Forwarded Headers off.
Single cloud proxy (Cloudflare, Azure Front Door) with dynamic IPs	Enable, leave Known proxies/networks empty, set Forward limit to 1.
Fixed on-premises load balancer	Enable, add the load balancer IP to Known proxies, set Forward limit to 1.
Cloudflare + internal nginx	Enable, add nginx IP to Known proxies, set Forward limit to 2.
Proxy that sends CF-Connecting-IP instead of X-Forwarded-For	Enable and set Forwarded for header name to CF-Connecting-IP.

Note

Changes to all settings in this section require an application restart to take effect.

Enable Forwarded Headers

Enables the ASP.NET Core Forwarded Headers Middleware. When active, the middleware rewrites HttpContext.Connection.RemoteIpAddress, HttpContext.Request.Scheme, and HttpContext.Request.Host from the incoming X-Forwarded-For, X-Forwarded-Proto, and X-Forwarded-Host headers respectively, so the rest of the application sees the original client values.

Enable this setting whenever Dynamicweb is hosted behind a proxy or load balancer. Leave it disabled for direct internet-facing deployments.

Setting path	Default
/Globalsettings/System/Http/ForwardedHeaders/EnableForwardedHeaders	false

Known proxies

A comma-separated list of individual trusted proxy IP addresses. Only headers forwarded by these addresses are processed; headers from any other IP are discarded.

Use this when your proxy infrastructure has fixed, known IP addresses (for example, an on-premises load balancer).

Setting path	Default
/Globalsettings/System/Http/ForwardedHeaders/KnownProxies	(empty)

Example values: 192.121.163.197, 10.0.0.1

Tip

If both Known proxies and Known networks are left empty, Dynamicweb automatically trusts all source addresses (0.0.0.0/0 and ::/0). This is intentional — it supports dynamic-IP services such as Cloudflare or Azure Load Balancer whose outbound IPs change and cannot be enumerated. Trust is then enforced indirectly through the Forward limit setting.

Known networks

A comma-separated list of trusted IP network ranges in CIDR notation. Any proxy whose IP falls within one of these ranges is treated as trusted.

Use this instead of (or alongside) Known proxies when you have multiple proxies in a known subnet.

Setting path	Default
/Globalsettings/System/Http/ForwardedHeaders/KnownNetworks	(empty)

Example values: 192.168.1.0/24, 10.0.0.0/8

Forwarded for header name

The name of the header that carries the client's original IP address. The standard name is X-Forwarded-For.

Change this only if your proxy uses a non-standard header name — for example CF-Connecting-IP (Cloudflare), True-Client-IP, or X-Real-IP.

Setting path	Default
/Globalsettings/System/Http/ForwardedHeaders/ForwardedForHeaderName	X-Forwarded-For

Forward limit

Limits how many IP hops in the X-Forwarded-For header the middleware processes, counting from the right (nearest hop first). This prevents a malicious client from injecting fake entries at the left end of the header.

Set this to the number of trusted proxy hops between the internet and Dynamicweb.

Setting path	Default
/Globalsettings/System/Http/ForwardedHeaders/ForwardLimit	(no limit)

Examples:

• Direct internet access, no proxy → leave empty (not needed).
• Cloudflare only → 1.
• Cloudflare → internal nginx → Dynamicweb → 2.

Warning

Clearing this field disables the limit entirely. Only do this when Known proxies or Known networks are explicitly configured, otherwise any client can spoof its IP address by crafting an X-Forwarded-For header.

ASP.NET Core's built-in default is 1. Dynamicweb sets the default to no limit when the field is empty so that multi-hop cloud deployments work without additional configuration, relying on the trust-all-networks fallback described above.

Require header symmetry

When enabled, the middleware enforces that the number of entries in X-Forwarded-For, X-Forwarded-Proto, and X-Forwarded-Host are all equal. A mismatch causes the request to be rejected. This guards against certain header-spoofing attacks in multi-proxy chains.

Leave this disabled unless you have a controlled proxy chain where you can guarantee consistent header population.

Setting path	Default
/Globalsettings/System/Http/ForwardedHeaders/RequireHeaderSymmetry	false

Response cache

These settings control the Cache-Control headers that Dynamicweb emits for static files served from the /Files area (images, CSS, JS, fonts, downloads). They do not affect page output caching — that is configured elsewhere.

When Enable response cache is off, ASP.NET Core's default static-file behavior applies and the other two fields are read-only.

Setting	Setting path	Use
Enable response cache	/Globalsettings/System/Http/StaticFiles/Cache/EnableResponseCache	Turns on Dynamicweb's custom Cache-Control handling for static files. With it off, ASP.NET Core's defaults are used.
Max age	/Globalsettings/System/Http/StaticFiles/Cache/MaxAge	Adds max-age=<seconds> to the Cache-Control header. Must be greater than 0. Default 604800 (7 days). Tune higher when assets are fingerprinted in URLs, lower if they are not.
Disable cache	/Globalsettings/System/Http/StaticFiles/Cache/NoCache	Forces Cache-Control: private, no-cache, no-store. When enabled, Max age is ignored. Use during active development or for solutions where every asset must be revalidated.

Output settings

These switches modify the rendered HTML response without touching template code.

Setting	Setting path	Use
Do not add base href to header	/Globalsettings/Settings/Designs/DoNotIncludeBaseHref	Suppresses the auto-generated <base href="..."> meta tag that Dynamicweb otherwise injects. Enable when the design supplies its own <base> element or relies on absolute URLs throughout.
Disable port number in base href and Cart redirects	/Globalsettings/System/http/DisableBaseHrefPort	Strips the port from the auto-generated <base href> and from cart redirect URLs. Use in reverse-proxy setups where Dynamicweb listens on an internal port (e.g. :5000) but the public URL has none.
Disable performance comment	/Globalsettings/Settings/DwInclude/DisablePerformanceComment	Removes the trailing <!-- ... --> HTML comment that reports render time and database/cache statistics. Disable it on production to avoid exposing internals; keep enabled during performance debugging.

Template compatibility

The template compatibility settings exist to ease the migration of templates from DW9 (@helper, @System.Web.*) to DW10 (functions, Dynamicweb.* APIs). When enabled, the runtime detects legacy patterns at template-load time and rewrites them on the fly.

Warning

These settings incur a real performance hit because every template load triggers detection and rewriting. They are intended only for debugging and one-off migration work — never for production traffic. Once templates have been migrated, turn all four off.

Setting	Setting path	Use
Convert detected DW9 templates to DW10 runtime	/Globalsettings/System/dw10/enableAutomaticTemplateConversion	Makes the template engine discover DW9 templates and convert @helper blocks to functions and @System.Web.* calls to their DW10 equivalents, in memory.
Save detected DW9 templates converted to DW10	/Globalsettings/System/dw10/saveAutomaticTemplateConversion	Writes the converted result next to the original as {filename}.dw10.cshtml. Lets you diff the conversion against the source before committing.
Load DW10 version of templates if detected	/Globalsettings/System/dw10/enableDw10TemplateLoading	When a {filename}.dw10.cshtml sibling exists, load it instead of {filename}.cshtml. Pairs with the previous setting to test the converted output without overwriting the source.
Overwrite detected DW9 with DW10 conversion	/Globalsettings/System/dw10/saveAndReplaceAutomaticTemplateConversion	Replaces the original {filename}.cshtml with the converted DW10 version and backs up the original as {filename}.dw9.cshtml. Destructive — make sure templates are under source control before enabling.

A typical migration sequence is: enable Convert → enable Save → review the generated .dw10.cshtml files → enable Overwrite for a single run → disable everything → commit the converted templates.