Ultimate Guide to Understanding HTTP Status Codes: 400 Series

Issues with a user-agent client can range from requesting resources that are no longer available (by mis-typing a URI) or even the server reacting to requests fitting a security-attack signature.

The most common is the 404. 404 Not Found is returned when a client requests a resource the web-server cannot find:

Let's go over the most common and interesting 400 series response codes in a little more detail.

400 Bad Request

400 Bad Request is (usually) the result of a user-agent sending something in the request a web-server could not process. Let's generate a 400 Bad Request to understand what can cause this error.

We will go old-school on Linux and use a tool called netcat. Netcat can be used for sending raw data over sockets. After all, HTTP/1.1 requests are just that: raw text.

First, let's send a legitimate HEAD Request to google:

Let's force a 400 Bad Request:

We purposefully sent a request the server could not understand. Let's look at the request method used:

$ nc www.google.com 80
BAD / HTTP/1,1
Host: www.google.com

The web-server could not process the method: BAD

It's unlikely a modern web browser would send malformed requests like depicted above. However, if you're using a custom developed HTTP application like a web-scraper, it's time to debug.

These steps resolve most common 400 errors.

1. Check The URL

If clicking on a link it is quite possible the web-author made a typo. Examine the entire URL paying particular attention to the path, document title, and query-string portions.

2. Clear all Cookies and Cache

Clearing cookies and cache fixes many 400 errors, and it is a good first step for a lot of other 400 Status Codes, too.

1. clear all cookies and browsing history
2. re-try the request

In Chrome, Edge and Firefox the option lives in the browser settings under Privacy, usually called "Clear browsing data"; menu names vary by version. Clearing the cookies of the one affected site is often enough.

Clearing all cookies and browsing history will assure anything cached and/or corrupted (like cookies) are gone. This often fixes a 400 Bad Request.

3. File Upload Size

The problem could very well be a back-end script itself, uploading too large of a file or a file with an incorrect media type.

1. If the 400 bad request presents itself while uploading a file, try a smaller file.
2. Make sure the file-type is acceptable.
3. If uploading an image try both jpeg and png formats.
4. If uploading a document, plain text and common office formats are usually permitted.

4. Malformed Headers

Malformed headers would be a pretty low-level issue and could very well leave the web-application itself at fault.

The developer tools built into every modern browser (the Network tab) let us watch the entire HTTP transaction for anything out of the ordinary.

5. Update Your Web Browser and Disable Plugins

If your browser is out of date it could very well be sending antiquated headers and requests.

Also, try removing or disabling all plug-ins and extensions. Trying the same request in another web browser can assist in isolating issues as well.

6. Try Logging Out

If using a web application with user-based authentication and sessions try logging out and then clearing the browser cache.

---

401 Unauthorized

401 Unauthorized is returned when a web server requests credentials for a secured document.

403 Forbidden

403 Forbidden is usually one of four things:

• directory listings are not permitted
• currently authenticated user does not have sufficient permissions
• the web-server process has inadequate permissions
• requesting address has been banned

Directory Listing Not Permitted

Here the web server does not allow directory listings for unauthenticated users. The simplest fix is to put an index file in the directory. Otherwise, directory listings to unauthenticated users will need to be explicitly set.

Authenticated User Does Not Have Permissions

The best method in this situation is making a group for all users who need access to a resource. Give this group the necessary permissions at the filesystem level. Then add permitted users to the group.

Web Server Process Does Not Have Sufficient Permissions

We are unable to access the test.php page in the webroot in /var/www/html. On RHEL and its derivatives (Oracle Linux, AlmaLinux, Rocky Linux) there are two things to check: classic file permissions and the SELinux context.

First, check ownership and permissions:

# ls -ld /var/www/html/
drwx------. 3 root root 4096 Nov 24 03:47 /var/www/html/

The directory is owned by the root user and root group with no access for anyone else, so the web server process (user apache for Apache httpd, nginx for nginx) cannot read it. Give the web server's group read access, without write:

# chgrp -R apache /var/www/html
# chmod 750 /var/www/html
# chmod 640 /var/www/html/test.php
# ls -ld /var/www/html/
drwxr-x---. 3 root apache 4096 Nov 24 03:47 /var/www/html/
# ls -l /var/www/html/test.php
-rw-r-----. 1 root apache 91 Nov 16 06:52 /var/www/html/test.php

Second, check the SELinux context. Files moved into the webroot from elsewhere keep their old label, and SELinux then blocks the web server even when the permissions are right:

# ls -Z /var/www/html/test.php
# restorecon -Rv /var/www/html

Content under /var/www/html should carry the httpd_sys_content_t type. Fix the label with restorecon; never disable SELinux to make a 403 go away.

In a staging environment, put developers in the web server's group and give that group write access; keep production read-only.

Another common scenario for a 403 Forbidden Status may be an IP Address or IP Range being banned in a .htaccess file by the server Administrator.

404 Not Found

404 Not Found means the web-server could not find a requested resource. When encountering a 404 error a few things can be done:

• check spelling of host, domain, path, and document

• check case of file and path. Linux and Unix web-servers (unless configured differently) usually distinguish case, with tradition of using all lowercase for each.

• use Google to find an alternative URL to the resource

• try an archived copy of the page in the Internet Archive's Wayback Machine

Using Advanced Google Search Operators

A query like the one above, using operators such as site: and filetype:, often finds a document whose old link now returns a 404.

If the page has been taken down, the Internet Archive's Wayback Machine may still hold an older copy.

405 Method Not Allowed

A 405 Method Not Allowed is presented when attempting a request method that is unpermitted by the web-server.

406 Not Acceptable

406 Not Acceptable is returned when the server cannot provide the resource in any of the content types, encodings, languages or character sets the client says it accepts.

To resolve a 406, look at the request headers in your browser's developer tools (Network tab).

Header values sent by the client to look over include:

• Accept
• Accept-Charset
• Accept-Encoding
• Accept-Language

Modern browsers rarely trigger this. If yours does, try upgrading it to a later version.

407 Proxy Authentication Required

407 Proxy Authentication Required will usually mean the user-agent needs to provide credentials to access a proxy server.

408 Request Timeout

408 means the server waited too long for the client to finish sending its request; it usually points at a slow or unstable client connection rather than the server.

429 Too Many Requests

429 will usually mean rate limiting has been enabled on the server. Rate limiting will only allow a certain amount of requests in an allotted amount of time.

When receiving 429 Too Many Requests, slow down. The server may send a Retry-After header that says how long to wait before trying again; well-behaved clients and scripts honour it and back off.

451 Unavailable for Legal Reasons

451 is returned when the server is legally required to block access to a resource, for example after a court order.