Debugging with response headers
Table of Contents
- Enabling Debug Mode
- Enabling Whitelist Debug Mode
- Headers
- MageStack-Debug
- MageStack-Area
- MageStack-Cache
- MageStack-Cacheable
- MageStack-Cache-Lifetime
- MageStack-Cache-Status
- MageStack-Web-Node
- MageStack-Tag
- MageStack-Spdy
- MageStack-Whitelist-Debug
- MageStack-Whitelisted-Http-Host
- MageStack-Whitelisted-Uri
- MageStack-Whitelisted-Ip
- MageStack-Whitelisted-Useragent
- MageStack-PageSpeed
MageStack sets a number of different response headers to help you identify how a request is being treated.
- Those marked with a ¹ are only shown when debug mode is enabled
- Those marked with a ² are only shown when whitelist debug mode is enabled
The following debug headers are available
- MageStack-Spdy
- MageStack-Area¹
- MageStack-Cache¹
- MageStack-Cacheable¹
- MageStack-Cache-Lifetime¹
- MageStack-Cache-Status¹
- MageStack-Debug¹
- MageStack-Tag¹
- MageStack-Web-Node¹
- X-Magento-Tags¹
The following whitelist debug headers are available
- MageStack-Whitelisted-Http-Host²
- MageStack-Whitelisted-Uri²
- MageStack-Whitelisted-Ip²
- MageStack-Whitelisted-User-Agent²
Enabling Debug Mode
To enable debug mode (ie. to view the debug headers), you merely need to edit your Nginx configuration to enable debug mode. You can do this for a specific URI or the entire site.
Edit your ___general/example.com.conf
(where example.com is your chosen domain), and add
set $magestack_debug true;
This can also be used conditionally by location, eg.
location ~* ^/(index.php/)?(furniture) {
set $magestack_debug true;
}
Then restart Nginx via Monit or by running /etc/init.d/nginx reload
.
Enabling Whitelist Debug Mode
Whitelist debug mode should not be enabled in a production environment as it exposes the stack to security risks. This should only be used in testing and development, but never left on in a production environment. If this setting is enabled, Varnish is automatically disabled for the request, so the headers cannot be cached.
To enable whitelist debug mode (ie. to view the whitelist debug headers), in addition to enabling normal debug mode, you must also set another flag to enable whitelist debug mode. You can do this for a specific URI or the entire site.
Edit your ___general/example.com.conf
(where example.com is your chosen domain), and add
set $magestack_debug true;
set $magestack_whitelist_debug true;
This can also be used conditionally by location, eg.
location ~* ^/(index.php/)?(furniture) {
set $magestack_debug true;
set $magestack_whitelist_debug true;
}
Then restart Nginx via Monit or by running /etc/init.d/nginx reload
.
Headers
MageStack-Debug
True
This header defines whether debug mode is enabled or not.
MageStack-Area
Frontend|Backend|PaymentBridge
This header defines how MageStack has interpreted the request; frontend (customer) traffic is treated differently to backend (admin) traffic. This could be a separate admin server, different PHP memory allocation, longer HTTP request timeout etc.
Requests for Payment Bridge are specifically assigned their own area for PCI-DSS Compliance handling.
MageStack-Cache
Hit|Miss
This header defines whether the content has been served from Varnish or not.
MageStack-Cacheable
Yes|No
This defines whether Varnish has processed the content, but has invalidated the content as being able to be cached. This could be for a number of reasons
- Response status header not
200
- TTL is <0
- Nocache cookie has been set
MageStack-Cache-Lifetime
[0-9]+[s|m|h|d|w]
This header defines the Varnish cache TTL of the current request.
MageStack-Cache-Status
This header clones the response header from the back-end (eg. 200, 404, 503 etc.)
MageStack-Web-Node
This header shows the name of the web server serving the response.
MageStack-Tag
Dynamic|Static
This header defines whether the request was interpreted as a dynamic request or static request. This is used for 2 purposes,
- Send requests to separate dedicated static/dynamic back-end servers
When scaling in a multi-server configuration, you can have separate dedicated servers to fulfill specific roles, isolating static content web servers from dynamic content allows you to scale your store in increasing traffic loads.
- Defining 'safe/acceptable' limits on the DOS filter.
The inbuilt DOS filter has default thresholds for what is deemed acceptable in terms of numbers of requests per second for both dynamic and static content. The DOS filter grading and scoring is based of this header.
Whether a request is deemed as static or dynamic is based primarily off the requested file extension, this list is not exhaustive, and is configurable per MageStack, but the defaults are:
Eg.
- Static Files: See this article
- Dynamic Files:
php
There is also additional processing involved to determine request type (to account for combination/minification of static files via a dynamic server).
MageStack-Spdy
This is a special header that is only served on HTTPS SPDY enabled domains. MageStack natively supports HTTPS SPDY - but due to HTTP incompatibility, it has a limited use on MageStack
MageStack-Whitelist-Debug
True
This header defines whether debug mode is enabled or not.
MageStack-Whitelisted-Http-Host
True
This header will only show if the requested HTTP host has been whitelisted on the DOS filter.
MageStack-Whitelisted-Uri
True
This header will only show if the requested URI has been whitelisted on the DOS filter.
MageStack-Whitelisted-Ip
True
This header will only show if the source IP address of the request (the client) has been whitelisted on the DOS filter.
MageStack-Whitelisted-Useragent
True
This header will only show if the user agent of the request (the client) has been whitelisted on the DOS filter.
MageStack-PageSpeed
True|False
This header defines whether Pagespeed is enabled or not.