The 406 Not Acceptable is an HTTP response status code indicating that the client has requested a response using Accept- headers that the server cannot fulfill.
The 406 Error is the result of the user agent (i.e., browser) specifying an acceptable character set (via Accept-Charset), language (via Accept-Language), etc. that needs a response and the server is unable to provide such a response.
This article will examine what causes a 406 Not Acceptable error and how to fix it. Using a Content Management System (CMS)? Not a problem! We'll also review how these systems generate 406 Not Acceptable errors.
And, with that, let's get started!
Server- or Client-Side?
All HTTP response status codes in the 4xx category are considered client error responses. This category contrasts with 5xx classification errors, such as the 504 Gateway Timeout Error, which are considered server error responses.
That said, the appearance of a 4xx error doesn't necessarily mean the issue is on the client side, where the "client" is the web browser or device used to access an application.
In some cases, the server could be responsible for the 406 Error since it's the network object producing the error. Perhaps the server is misconfigured and can't handle the request correctly. Maybe it's a traffic routing issue.
We'll look at both client and server-side issues within this article, but first, let's make sure you're set up to diagnose and debug your application.
Start With a Thorough Application Backup
Before attempting to fix any errors, you should perform a complete backup of your application, database, and all other components of your website or application.
Even better, create a complete copy of the application and stick the copy on a secondary staging server that isn't accessible to the public. A staging server will give you a clean testing ground to test all potential fixes to resolve the issue without threatening the sanctity of your live application.
Diagnosing a 406 Not Acceptable
As discussed in the introduction, a 406 Not Acceptable Error means that the user agent (the web browser, in most cases) has requested a valid resource; however, the request included a special Accept- header. The Accept- header indicates to the server a valid response can only contain certain types of information.
Here are a few examples of such scenarios:
- The user agent may be localized to a particular locale or language the server cannot provide. For example, a user agent may use the Accept-Language request header to specify a valid language of French (Accept-Language: fr). Still, if the server cannot serve a response in French, a 406 code may be the only proper response.
- The user agent may request a specific type of content to be returned by the server. These content types, commonly known as MIME types, define things like plain text (text/plain), PNG images (image/png), mp4 videos (video/mp4), etc. Thus, the client may include the Accept header in the request and define an explicit MIME type that the server should provide (e.g., Accept: application/XML). If the server cannot respond with the matching content type requested, a 406 Not Acceptable response may be necessary.
There are a handful of other Accept- headers that can be provided in HTTP requests. Still, the vast majority of scenarios are similar to the above: The user agent wants an explicit type of response, and the server either provides it or returns a 406 code indicating it cannot fulfill the request.
Troubleshooting on the Client-Side
Since the 406 Not Acceptable is a client error response code, it's best to troubleshoot any potential client-side issues first. Here are a few tips to try on the browser or device throwing the error.
Check the Requested URL
The most common cause of a 406 Not Acceptable is inputting an incorrect URL. Servers tend to be tightly secured against unexpected requests to resources that a client/user agent should not have access to. It may be that the requested URL is slightly incorrect, which is causing the user agent to request a specific type of response.
For example, a request to the URI https://airbrake.io?json might indicate to the server that a JSON response is required. Since 406 codes are not as common as 404 codes, the appearance of a 406 could mean that the requested URL is valid, but the browser may misinterpret the intended request type. Either way, it's a good idea to double-check the exact URL that is returning the 406 Not Acceptable error to make sure it is the intended resource.
Debugging Common Platforms
Suppose you're running common software packages on the server responding with the 406 Not Acceptable. In that case, you may want to start by first looking into those platforms' stability and functionality.
The most common content management systems (CMS) -- like WordPress, Joomla!, and Drupal -- are all typically well-tested out of the box. Once you start making modifications to the underlying extensions or PHP code, it's too easy to cause an unforeseen issue that results in a 406 Not Acceptable.
Here are a few tips to help you troubleshoot some of these popular software platforms.
Rollback Recent Upgrades
If you recently updated the content management system before the 406 Not Acceptable appeared, consider rolling back to the previous version you had installed.
Similarly, any extensions or modules you recently upgraded can also cause server-side issues, so reverting to previous versions of those may also help.
In some cases, however, certain CMSs don't have a version downgrade capability. This is likely because they consider the base application and each new version released to be highly stable and bug-free.
Uninstall New Extensions, Modules, or Plugins
Depending on the content management system you use, the exact names of these components will be different. Still, they all serve the same purpose across every system: improving the capabilities and features of the platform beyond what it's typically capable of out of the box.
Be warned: such extensions can, more or less, take complete control of the system and make virtually any changes to the CMS's code. As such, it may be wise to uninstall any new extensions you recently added.
Check for Unexpected Database Changes
Even if you uninstall an extension through the CMS dashboard, this doesn't guarantee that changes made by the extension will fully revert.
This is particularly true for many WordPress extensions. WordPress extensions are given carte blanche within the application, including full access rights to the database. That means they can modify database records that don't "belong" to the extension but are created and managed by other extensions (or even the base CMS).
Unfortunately, the extension may not know how to revert alterations to database records so that it will ignore such things during uninstallation.
Diagnosing such problems can be tricky, but I've personally encountered such scenarios multiple times. Your best course of action, assuming you're reasonably convinced an extension is a likely culprit for the 406 Not Acceptable Error, is to open the database and manually look through tables and records that were likely modified by the extension.
Troubleshooting on the Server-Side
If you aren't running a CMS application or you're confident the 406 Not Acceptable Error isn't related to that -- here are some additional tips to help you troubleshoot what might be causing the issue on the server-side.
Confirm Your Server Configuration
Your application is likely running on a server using one of the two most popular web server software, Apache or Nginx. One of the first steps you can take to determine what might be causing these 406 Not Acceptable response codes is to check the configuration files for your web server software for unintentional redirect or request handling instructions.
To determine your application's web server, you'll want to look for a key file.
Apache Server
If your web server is Apache, look for a .htaccess file within the root directory of your website file system.
For example, if your application is on a shared host, you'll likely have a username associated with the hosting account. The application root directory is typically found at the path of:
/home/<username>/public_html/, so the .htaccessfile would be at /home/<username>/public_html/.htaccess.
If you located the .htaccess file, open it in a text editor and look for lines that use RewriteXXX directives, which are part of the mod_rewrite module in Apache. Covering exactly how these rules work is well beyond the scope of this article; however, the basic concept is that a RewriteCond directive defines a text-based pattern that will be matched against entered URLs.
Suppose a visitor requests a matching URL to the site. In that case, the RewriteRule directive that follows one or more RewriteCond directives is used to perform the actual redirection of the request to the appropriate URL.
For example, a RewriteRule matches all incoming requests to https://airbrake.io/users/json that do not contain an Accept: application/JSON request header.
The result is a redirection and 406 Not Acceptable response error code:
RewriteEngine on
RewriteCond %{REQUEST_URI} ^/users/json/?.*$
RewriteCond %{HTTP_ACCEPT} !application/json
RewriteRule ^(.*)$ https://airbrake.io/users/json$1 [R=406,L]
Notice the R=406 flag at the end of the RewriteRule, which explicitly states that the response code should be 406. This tells the user agents that the resource exists, but the explicit Accept- headers could not be fulfilled.
If you find any strange RewriteCondor RewriteRule directives in the .htaccess file that don't seem to belong, try temporarily commenting them out (using the # character prefix) and restarting your web server to see if this resolves the issue.
Nginx
On the other hand, if your server is running on Nginx, you'll need to look for a completely different configuration file. By default this file is named nginx.conf and is located in one of a few common directories: /usr/local/nginx/conf, /etc/nginx, or /usr/local/etc/nginx.
Once located, open nginx.conf in a text editor and look for directives using the 406 response code flag.
For example, here is a block directive (i.e., a named set of directives) that configures a virtual server for airbrake.io and ensures that, similar to above, a request to
https://airbrake.io/users/json that doesn't include an Accept: application/JSON request header will fail and is met with a 406 response code:
server {
listen 80;
listen 443 ssl;
server_name airbrake.io;
location /users/json {
if ($http_accept != application/json) {
return 406 https://airbrake.io/users/json$request_uri;
}
}
}
Have a look through your nginx.conf file for any abnormal directives or lines that include the 406 flags. Comment out any abnormalities before restarting the server to see if the issue was resolved.
Configuration options for each different type of web server can vary dramatically, so we'll list a few popular ones to give you some resources to look through, depending on what kind of server your application is running on:
Look Through the Logs
Nearly every web application will keep some form of server-side logs. Application logs are typically the history of the application's actions, including requested pages, connected servers, database results, etc.
Server logs are related to the actual hardware running the application and will often provide details about the health and status of all connected services or the server itself.
Google "logs [PLATFORM_NAME]" if you're using a CMS, or "logs [PROGRAMMING_LANGUAGE]" and "logs [OPERATING_SYSTEM]" if you're running a custom application, to get more information on finding the logs in question.
Debug Your Application Code or Scripts
If all else fails, you might have a problem with some custom code within your application. Try to diagnose where the issue may come from by manually debugging your application and parsing through application and server logs.
Ideally, make a copy of the entire application to a local development machine and perform a step-by-step debug process, which will allow you to recreate the exact scenario in which the 406 Not Acceptable occurred and view the application code at the moment something goes wrong.
Prevent an future unexpected 406 Not Acceptable Error from impacting users by implementing an error monitoring solution. Error Monitoring will help you automatically detect errors and will alert you the very moment they occur.
Airbrake's Error and Performance Monitoring software provides real-time error monitoring and automatic exception reporting for all your development projects. Airbrake's state-of-the-art web dashboard ensures you receive round-the-clock status updates on your application's health and error rates. No matter what you're working on, Airbrake easily integrates with all the most popular languages and frameworks. Plus, Airbrake makes it easy to customize exception parameters while giving you complete control of the active error filter system, so you only gather the errors that matter most.
Check out Airbrake's error monitoring software today and see why so many of the world's best engineering teams use Airbrake to revolutionize their exception handling practices!
