HTTP Status Codes

HTTP Methods

By Error Admin in HTTP Methods, HTTP Verbs

HTTP Methods: The HTTP defines a set of request methods that indicate desired actions to be performed for a given resource. Even if they are nouns, the request methods are commonly called HTTP verbs. These HTTP verbs are case sensitive and must be used in uppercase. Each and every HTTP Methods establishes different meaning, but some common features are shared by a group of them. For example, the HTTP request methods are safe, idempotent and cacheable.

HTTP Methods

HTTP Methods

Although this set of HTTP verbs can be expanded, additional request methods cannot be assumed to share the same semantics for separately extended clients and servers. Below are the HTTP Methods and their request methods in detail.


The GET method is used to retrieve the information from the requested URL. The GET method should only retrieve data and should not have any effect on the data. Thus calling a request multiple times won’t affect the data and has an effect as the same when they are called once. To point out, GET method is idempotent which means making multiple request results in ending up like a single request. Usually, GET returns a representation in XML or JSON and an HTTP response code of 200 OK. In an error case, it most often returns a 404 Not Found or 400 Bad Request.

If the request message includes an If-Modified-Since, If-Unmodified-Since, If-Match, If-None-Match, or If-Range header field the semantics of the GET method changes to a “Conditional GET”. The conditional GET method requests can be transferred only when conditional header fields are available. It is intended to reduce the unnecessary network usage by using cached entities.

If the request message includes a Range header field then the semantics of GET method changes to “Partial GET”. It is also intended to reduce network similar to conditional GET as it requests for only a part of the entity being transferred.


The HEAD method is same as that of GET except that the server doesn’t return any message-body in the response. The metainformation contained in the HTTP headers in response to a HEAD request SHOULD be identical to the information sent in response to a GET request. This HEAD method can be used to obtain meta-information about the request without transferring the entity-body. This method is often used for testing hypertext links for validity, accessibility, and recent modification.

The HEAD response method is cacheable so that the information contained can be used to update previously cached entity from that resource. If the new file values state that the cached data is different from the present data, then the cache is treated as an old one.


The POST method is used to request the server to accept a new entity as a new subordinate. To point out it is used to create subordinates that are subordinate to some other parent resource. It is often used to make changes in the state or side effects on the server. So when you are creating a new resource, POST to the parent resource and it takes care of assigning and associating the resources.

On successful creation of the resource, return an HTTP status 201, returning a Location header with a link to the newly-created resource with the 201 HTTP status.

The POST method takes cares of the following functions:

  • Providing a block of data, as the result of submitting a form to a data-handling process
  • Extending a database through an append operation
  • Annotation of existing resources
  • Posting a message to a bulletin board, newsgroup, mailing list, or similar group of articles

The POST method is dependent on the Request-URI. The new entity is subordinate to that URL the same way a file is subordinate to a directory. The action performed by the POST method might not result in a resource that can be identified by a URI. Now either 200 OK or 204 No Content is the appropriate response status based on the response that describes the result. If a resource has been created on the origin server, then the response should be 201 Created.

The response to the POST method is not cacheable unless the response includes a Cache-Control or Expires header fields. You can also use 303 See Other to direct the user to retrace a cacheable resource.


The PUT method is used to update the target resources with the enclosed entity from the request payload. It is most frequently used for updating purposes. The known resource URL is replaced with the newly updated data of the request body. The PUT method requests to store the enclosed entity with the Request-URL. If it already persists, the enclosed entity is considered as a modified resource with the one present in the origin server. If the Request-URL does not point to the existing resource and if the URL is capable of being defined as a new resource, then the server can create a new entity with that URL.

In case of a new resource being created then the origin server should inform the user using 201 Created status code. In case of the existing resource being modified then either 200 OK status code or 204 No Content should be used to represent successful completion of the request. If the resource could not be created or modified as per the Request-URL, then the corresponding error code must be given to the user. Also, a 501 Not Implemented response is used in cases that the recipient’s headers gets ignored.

The PUT method is not to use as it modifies the state on the server, yet it is idempotent. Create a resource using PUT and make a call, again and again, it will have the same state as it had with the first call. It is highly recommended to use PUT method for idempotent requests and to use POST method for non-idempotent requests.


The delete works the same way as it means, it deletes the resources identified by the Request-URL. This PUT method can be overridden or interrupted by human intervention or any other means on the origin server. It is not guaranteed that operation is completed successfully even if the status code from the origin server states success. Thus the server should not post success unless the response is given that the resource is deleted and moved to a location that is inaccessible.

A successful response is returned with 200 OK including a description of the status. Or a 202 Accepted status if the action is yet to be performed. Else a 204 No Content if the action has been enacted, but the server response does not include any entity.

The DELETE method is idempotent that is if you delete a resource it is removed. Even if you call DELETE multiple times, it ends up on the same. IF calling DELETE decrements a counter then no longer DELETE is idempotent. It is recommended to use POST for non-idempotent resource requests.

Calling DELETE on a resource for the second time will often return a 404 NOT FOUND as it was already removed and no longer available. This in some notion makes DELETE operations no longer idempotent. However, the final state is the same.


The TRACE method uses an application layer message loop-back of the request method. The end recipient SHOULD reflect back the message to the client as a 200 OK response. The final recipient is the either the first proxy or the origin server or the gateway to receive a Max-Forwards value of zero.

The TRACE method MUST NOT include an entity. The TRACE method allows the client to see what is being received at the other end of the request chain and use that data for testing information. The value of the Via header acts as the trace of the request chain. The Max-Forwards header field allows the client to lessen the length of the request chain. This will be useful for testing a chain of proxies forwarding messages in an infinite loop. If the request is valid, then the response SHOULD contain the entire request message in the entity-body, with a Content-Type of “message/http”. Responses to this method MUST NOT be cached.


The CONNECT METHOD is referred to proxies that dynamically establishes a tunnel to the server identified by the target resource.

Learn more about HTTP Methods for HTTP Error Codes.

Other HTTP Status Codes

HTTP Verbs

HTTP Methods

1xx Informational

100 Continue

101 Switching Protocol

102 Processing

2xx Success

200 OK

201 Created

202 Accepted

203 Non-Authoritative Information

204 No Content

205 Reset Content

206 Partial Content

207 Multi-Status (WebDAV; RFC 4918)

208 Already Reported (WebDAV; RFC 5842)

226 IM Used (RFC 3229)

3xx Redirection

300 Multiple Choice

301 Moved Permanently

302 Found

303 See Other

304 Not Modified

305 Use Proxy

306 Unused

307 Temporary Redirect

308 Temporary Redirect

4xx Client Error

400 Bad Request

401 Unauthorized

402 Payment Required

403 Forbidden

404 Not Found

405 Method Not Allowed

406 Not Acceptable

407 Proxy Authentication Required

408 Request Timeout

409 Conflict

410 Gone

411 Length Required

412 Precondition Failed

413 Payload Too Large

414 URI Too Long

415 Unsupported Media Type

416 Requested Range Not Satisfiable

417 Expectation Failed

418 I’m a teapot (RFC 2324)

421 Misdirected Request

422 Unprocessable Entity (WebDAV; RFC 4918)

423 Locked (WebDAV; RFC 4918)

424 Failed Dependency (WebDAV; RFC 4918)

426 Upgrade Required

428 Precondition Required

429 Too Many Requests

431 Request Header Fields Too Large

451 Unavailable For Legal Reasons

5xx Server Error

500 Internal Server Error

502 Bad Gateway

503 Service Unavailable

504 Gateway Timeout

505 HTTP Version Not Supported

506 Variant Also Negotiates

507 Variant Also Negotiates

508 Loop Detected (WebDAV; RFC 5842)

510 Not Extended (RFC 2774)

511 Network Authentication Required

Unofficial Error Code List

103 Checkpoint

420 Method Failure (Spring Framework)

420 Enhance Your Calm (Twitter)

450 Blocked by Windows Parental Controls (Microsoft)

498 Invalid Token (Esri)

499 Token Required (Esri)

499 Request forbidden by antivirus

509 Bandwidth Limit Exceeded (Apache Web Server/cPanel)

530 Site is frozen

Internet Information Services Error Code List

449 Retry With

451 Redirect

444 No Response

Nginx Error Code List

495 SSL Certificate Error

496 SSL Certificate Required

497 HTTP Request Sent to HTTPS Port

499 Client Closed Request

CloudFlare Error Code List

520 Unknown Error

521 Web Server Is Down

522 Connection Timed Out

523 Origin Is Unreachable

524 A Timeout Occurred

525 SSL Handshake Failed

526 Invalid SSL Certificate

Post a Reply

Your email address will not be published. Required fields are marked *