The 400 Bad Request Error is an HTTP response status code indicating that the server was unable to process the request sent by the client due to invalid syntax. As with the dozens of potential HTTP response codes, receiving a 400 error while accessing your own application can be both frustrating and challenging to fix.
Such HTTP response codes represent the complex relationship between the client, a web application, a web server, and often multiple third-party web services. As you can imagine, determining the cause of a 400 error can be difficult, even within a controlled development environment.
Throughout this article, we’ll examine the 400 Bad Request error by digging into whether the root cause is on the local client or remote server. We’ll also go over a few tips and tricks to help you diagnose and debug your own application if it’s reporting a 400 error for some reason.
Lastly, we’ll explore a handful of the most common content management systems (CMSs) that are in use today and how these systems can cause an unexpected 400 Bad Request Error.
All HTTP response status codes that are in the 4xx category are considered client error responses. These types of messages contrast with errors in the 5xx category, such as the 504 Gateway Timeout Error we looked at last week, which are considered server error responses.
With that in mind, the appearance of a 400 error doesn’t necessarily mean the issue has something to do with the client (the web browser or device).
Oftentimes, if you’re trying to diagnose an issue within your own application, you can immediately ignore most client-side code and components. This might include HTML, cascading style sheets (CSS), client-side JavaScript, and so forth. This doesn’t apply solely to websites, either. Many smartphone apps using a modern-looking user interface are powered by a normal web application behind the scenes.
On the other hand, a 400 Bad Request Error indicates that the request sent by the client was invalid for one reason or another. It’s entirely possible the issue is from the client-side. Your client may be trying to send a file that’s too big, the request could be malformed in some way, the request HTTP headers could be invalid, and so forth. We’ll explore some of these scenarios (and potential solutions) down below.
Be aware that, even though a 400 error is considered a client error response, it doesn’t inherently mean we can rule out either the client or the server as the root of the problem. In these scenarios, the server is still the network object that is producing the 400 Bad Request Error and returning it as the HTTP response code to the client. It could also be that the client is causing the issue in some way.
It is critical that you perform a full backup of your application, database, and so forth, before attempting any fixes or changes to the system. Even better, if you have the capability, create a complete copy of the application onto a secondary staging server that isn’t “live” or available to the public. This will give you a clean testing ground to test all potential fixes to resolve the issue, without threatening the security or sanctity of your live application.
A 400 Bad Request Error indicates that the server (remote computer) is unable (or refuses) to process the request sent by the client (web browser). There are several scenarios in which a 400 Bad Request Error could appear in an application, but below are the most likely causes:
Since the 400 Bad Request Error is a client error response code, it’s best to start by troubleshooting any potential client-side issues that could be causing this error.
Here are a handful of tips to try on the browser or device that is giving you http error 400 issues.
As mentioned, the most common cause of a 400 Bad Request is simply inputting an incorrect URL.
Domain names (e.g. airbrake.io) are case-insensitive. This means that this mixed case link to AirBrAKe.IO works just as well as the normal, lowercase version of airbrake.io.
However, path, query, or fragment portions that appear after the domain name, are quite often case-sensitive. The exception is if the application/server configuration is explicitly designed to pre-process all URLs as lowercase before execution.
Check the URL for improper special characters that don’t belong. If the server received a malformed URL, it’s likely to produce a 400 Bad Request Error response.
As discussed above, one potential cause of a 400 Error is an invalid or duplicate local cookie. HTTP cookies are tiny pieces of data stored on your local device that is used by websites and applications to “remember” information about a particular browser and/or device.
Most modern web apps take advantage of cookies to store user- or browser-specific data, identifying the client and allowing future visits to be faster and easier.
However, a cookie that stores session information about your particular user account or device could be conflicting with another session token from another user, giving one (or both of you) a 400 Bad Request Error.
In most cases, you only need to concern yourself with cookies that are relevant to the website or application causing the problem.
Cookies are stored based on the web application’s domain name, so you can remove only those cookies that match the website domain (e.g. airbrake.io). This will allow you to keep all other cookies intact. However, if you are unfamiliar with manually removing certain cookies, it’s much easier and safer to clear all cookies at once.
Clearing cookies can be accomplished in different ways, depending on the browser you’re using. Here’s a list of how-to’s on clearing cookies depending on the browser:
If you’re experiencing a 400 error while uploading a file, try testing with a different, much smaller file to see if this resolves the error. This includes file “uploads” that don’t actually come from your local computer. Even files sent from other computers are considered “uploads” from the perspective of the web server running your application.
The last client-side step to try is to log out and then log back in if the application requires user authentication. If you’ve recently cleared the browser cookies, this should usually log you out automatically the next time you try to load the page. At that point, feel free to just log back in at this point and see if things are working once again.
For most web applications, logging out and logging back in will force the local session token to be recreated.
If you’re running common software packages on the server that is responding with a 400 Error, you may want to start looking into the stability and functionality of those platforms first.
The most common content management systems (CMS) — like WordPress, Joomla!, and Drupal — are typically well-tested out of the box. Unfortunately, once you start making changes to the underlying extensions or PHP code, it’s all too easy to cause an unforeseen issue that results in a 400 Bad Request error.
If you recently updated your CMS just before the 400 Error appeared, you may want to consider rolling back to the previous version you had installed.
Similarly, any extensions or modules that you may have recently upgraded can also cause server-side issues. Try reverting upgrades to a previous version. For assistance with this task, simply Google “downgrade [PLATFORM_NAME]” and follow along.
In some cases, certain CMSs don’t provide a version downgrade capability. This happens when the CMS creators consider the base application, along with each new version released, to be stable and bug-free. This is typically the case for the more popular platforms.
Extensions, modules, or plugins serve the same purpose across every system: improving the capabilities and features of your CMS.
But be warned: extensions can take full control of the system and make virtually any changes, whether it be to the PHP code, HTML, CSS, JavaScript, or database. As such, it’s wise to uninstall any new extensions that may have recently been added.
It’s worth noting that 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, which are given carte blanche within the application. This often includes full access rights to the database.
There are scenarios where an extension may modify database records that don’t “belong” to the extension itself but are instead created and managed by other extensions (or even the base CMS itself). In those scenarios, the extension may not know how to revert alterations to database records, so it will ignore such things during uninstallation.
Diagnosing such problems can be tricky, but I’ve personally encountered such scenarios multiple times. If you’re reasonably convinced an extension is a likely culprit for the 400 error, open the database and manually look through tables and records that were likely modified by the extension.
If you aren’t running a CMS application or you’re confident the 400 Bad Request error isn’t related to that — it’s time to check for server-side issues.
It’s possible that the 400 error you’re seeing from your own application is a result of missing or invalid custom HTTP headers. In such cases, you may be able to analyze the HTTP headers that are sent on the server-side and determine if they are invalid or unexpected in some way.
Nearly every web application keeps some form of server-side logs. Application logs contain the history of what the application did, such as which pages were requested, servers it connected to, database results it provides, and so forth.
Server logs are related to the actual hardware that is running the application. These often provide details about the health and status of all connected services, or just 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.
If all else fails, it may be a problem with some custom code within your application. Try to diagnose where the issue may be coming from by manually debugging your application, along with parsing through application and server logs.
Ideally, you should make a copy of the entire application on a local development machine and debug it step by step to find out exactly what caused the 400 Bad Request error.
Or you can find the bug in moments using Airbrake Error Monitoring.
Airbrake’s error 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.
Check out Airbrake’s error monitoring software today and see for yourself why so many of the world’s best engineering teams use Airbrake to revolutionize their exception handling practices!
Note: We published this post in November 2021 and recently updated it in May 2022.