Custom HTTP headers are commonly meant to provide additional information that may be pertinent to a web developer, or for troubleshooting purposes. These headers often times begin with
X-, however, we’ll discuss naming convention further on. This post should help give you a better overall understanding of what custom HTTP headers actually are, why they are useful, and how to define them.
Why Use Custom HTTP Headers?
As mentioned, custom headers are great for troubleshooting, informational purposes, and even implementing particular logic on the server-side. For example, KeyCDN makes use of the
X-Cache header to let users know whether or not an asset has been delivered from an edge server or from the origin server.
The custom header returns a HIT if the asset was delivered from cache and a MISS if it was delivered from the origin server. Another example of using a custom HTTP header would be to implement the X-Pull header. You can use this custom header for a variety of purposes including rate limiting bandwidth on your origin server, restricting CDN traffic, creating custom logic on your origin server, etc. There are many uses for custom headers and they are quite commonly used. Even if you aren’t using a CDN or haven’t specifically defined any custom HTTP headers on your origin server, you may still be sending responses with custom headers. For instance, WordPress sends the following headers (however they can be disabled).
X-Powered-By: PHP/5.2.17 X-Pingback: https://example.com/xmlrpc.php
When it comes to the proper naming conventions for HTTP custom headers, there has been some back and forth. Initially, it was recommended to begin naming custom headers with
X- so that users would be aware that these headers were custom and not standardized. However, according to RFC 6648, this recommendation has since been deprecated.
Creators of new parameters to be used in the context of application protocols SHOULD NOT prefix their parameter names with “X-” or similar constructs.
Although the recommendation to use
X- has been deprecated, it doesn’t mean that it is no longer supported. In fact, there are still many scenarios where
X- continues to be used. The reason behind the deprecation of the recommendation to use
X- is because, in the event that a particular custom HTTP header becomes standardized, browsers would need to support both names or developers would need to update all instances of their custom header name. Instead, it is now recommended to simply name custom headers with something of relevance without the
Setting Custom HTTP Headers
If you want to set a custom HTTP headers on your server to be sent in your HTTP responses, the process is quite simple. We have outlined below the snippets required to add a custom header for both Apache and Nginx web servers.
For Apache users, the following snippet can be added to your .htaccess file. Simply replace Custom-Header-Name and “Custom Header Value” with the actual name and value of your HTTP header.
Header set Custom-Header-Name "Custom Header Value"
For Nginx users, the following snippet can be added to your configuration file. Be sure to modify the name and value to suit your needs and reload Nginx once the changes have been saved.
add_header Custom-Header-Name "Custom Header Value"
Custom HTTP headers are extremely useful in many cases. Although their main purpose is for providing additional information, there is so much more you can do with them as we briefly explained above. One thing to be aware of however is to avoid using them in a way that changes the behaviour of HTTP methods. Other than that, try experimenting with them in various use-cases.