The 400 Bad Request Error is an HTTP response status code that indicates 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 Bad Request 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, so determining the cause of a particular status code can be a difficult, even within a controlled development environment.The 400 Bad Request error is often caused by entering or pasting the wrong URL in the address window but there are some other relatively common causes as well.
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 4xx error doesn’t necessarily mean the issue has something to do with the client, where the client is the web browser or device being used to access the application.
On the other hand, since 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 steps from the client. 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. Windows Update can also report HTTP 400 errors but they display as error code 0x80244016 or with the message WU_E_PT_HTTP_STATUS_BAD_REQUEST.A 400 error that's reported for a link within a Microsoft Office application will often appear as a The remote server returned an error: (400) Bad Request. message within a small pop-up window.
Diagnosing 400 Bad Request Error
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), due to an issue that is perceived by the server to be a client problem. There are a wide variety of scenarios in which a 400 Bad Request Error could appear in an application, but below are some of the most likely causes:
The client may be accidentally (or intentionally) sending deceptive request routing information. Some web applications/web servers look for custom HTTP headers to process requests and verify the client isn’t attempting anything malicious. If an expected custom HTTP header is missing or invalid, a 400 Bad Request Error is a likely result.
The client may be uploading a file that is too large. Most web servers or applications have an explicit file size limit that prevents files that are too big from being uploaded and clogging up bandwidth and other resources in the server. In many cases, the server will produce a 400 Bad Request Error when a file is too large (and, thus, the request cannot be completed).
The client is accessing an invalid URL. If the client is sending a request to an invalid URL — particularly one that is malformed via improper characters — this could result in a 400 Bad Request Error.
The client is using an invalid or expired local cookie. Again, this could be malicious or accidental, but it’s possible that a local cookie in the web browser is identifying you via a session cookie. If this particular session token matches the session token from another request from a different client, the server/application may see this is a malicious act and produce a 400 Bad Request Error code.
How to Fix the 400 Bad Request Error
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 problems.
Check for errors in the URL. The most common reason for a 400 Bad Request error is because the URL was typed wrong or the link that was clicked on points to a malformed URL with a specific kind of mistake in it, like a syntax problem.Domain names (e.g. airbrake.io) are case-insensitive, meaning that this mixed case link to AirBrAKe.IO works just as well as the normal, lowercase version of airbrake.io.
Clear Relevant Cookies. One potential cause of a 400 Bad Request Error is an invalid or duplicate local cookie. HTTP cookies are tiny pieces of data stored on your local device, which are used by websites and applications as a mechanism to “remember” information about this 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 for future visits to be faster and easier.Especially if you're getting a Bad Request error with a Google service. Many sites report a 400 error when a cookie it's reading is corrupt or too old.
Cookies are stored based on the web application’s domain name, so you can explicitly remove only those cookies that match the website domain (e.g. airbrake.io), thereby keeping all other cookies intact.Clearing cookies can be accomplished in different ways, depending on the browser you’re using:
- Google Chrome - Internet Explorer - Microsoft Edge - Mozilla Firefox - Safari
Log Out and Log In If the application you’re using has some form of user authentication, the last client-side step to try is to log out and then log back in. If you’ve recently cleared the browser cookies, this should usually log you out automatically the next time you try to load the page, so feel free to just try logging back at this point, to see if things are working once again. Similar to the local cookie issue, the application may be running into a problem with your previous session, which is just a string that the server sends to the client to identify that client during future requests.
Rollback Recent Upgrades If you recently updated the content management system itself just before the 400 Bad Request Error appeared, you may want to consider rolling back to the previous version you had installed when things were working fine. Similarly, any extensions or modules that you may have recently upgraded can also cause server-side issues, so reverting to previous versions of those may also help. For assistance with this task, simply Google “downgrade [PLATFORM_NAME]” and follow along.
Uninstall New Extensions, Modules, or Plugins Depending on the particular content management system your application is using, the exact name of these components will be different, but they serve the same purpose across every system: improving the capabilities and features of the platform beyond what it’s normally capable of out of the box.
Check for Unexpected Database Changes It’s worth noting that, even if you uninstall an extension through the CMS dashboard, this doesn’t guarantee that changes made by the extension have been fully reverted.
Check for Invalid HTTP Headers This may be tricky for non-developer types, but it’s possible that the 400 Bad Request Error you’re seeing from your own application is a result of missing or invalid custom HTTP headers that your server/web application expects. 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.
Look Through the Logs Nearly every web application will keep some form of server-side logs. Application logs are typically the history of what the application did, such as which pages were requested, which servers it connected to, which database results it provides, and so forth. Server logs are related to the actual hardware that is running the application, and will often provide details about the health and status of all connected services, or even just the server itself.
400 Bad Request
Software Developer
computer future of mo history of mouse mouse