1. Stateless - means the server does not have the record of any previous request response data, there is no client state preservation. Each request is a fresh request
2. Client-server model - the foundation of HTTP, the client sends request to server and the server responds

• HTTP/0.9 (1991)
• HTTP/1.0 (1996) - each req opened a new TCP connection
• HTTP/1.1 (1997) - persistent connections introduced (multi req - res over same TCP connection), chunk transfer encoding, better caching mechanisms over 1.0
• HTTP/2 (2015) - header compression, binary framing, multiplexing, server push (allowing server send resources before client req for them)
• HTTP/3 (2019) - a quick protocol was built upon UDP instead of TCP in transport layer

HTTP headers:

• Request Headers - client metadata, env and capabilities
  • User-Agent (e.g. chrome, postman)
  • Authorization (e.g. JWT token)
  • Cookie
  • Accept (type of response the client expects)
• General Headers - used by both Request and Response objects
  • Date
  • Cache-Control
  • Connection
• Representation Headers - represents the resource (body) being sent by client or server
  • Content-Type
  • Content-Length
  • Content-Encoding
  • ETag (a unique identifier used mostly for caching purposes)
• Security Headers (used by both client and server for using common and best security practices)
  • Strict-Transport-Policy (HSTS) - ensures the client server communication only happens over HTTPS, does not downgrade
  • Content-Secutity-Policy (CSP) - prevents loading scripts or images over transport to prevent cross-site attacks (XSS prevention)
  • X-Frame-Options - prevents the webpage from being embedded in an iFrame, preventing clickjack attacks
  • X-Content-Type-Options - prevents MIME-type sniffing
  • Set-Cookie - prevents JavaScript from accessing cookies and ensures they are sent over HTTPS only

HTTP methods (verbs):

• GET - retrieve data from server
• POST - submit data to server
• PUT - update/replace existing resource
• PATCH - partial update to resource
• DELETE - remove resource from server

Idempotent & Non-Idempotent methods

Idempotent: denoting an element of a set which is unchanged in value when multiplied or otherwise operated on by itself. Means the HTTP methods that can be called multiple times and still get the same response

Idempotent methods:

• GET - A resource can be fetched multiple times
• PUT - A resource or data can be replaced more than one time
• DELETE - A resource can be deleted multiple times (not really)

Non-Idempotent Methods:

• PUT - we cannot create a resource multiple times and expect same response

OPTIONS Method

This method is used by the browser usually for pre-flight requests to the server, to know the server capabilities. This method is used for CORS verification purposes. Browsers follow the same-origin policy in CORS

• Simple request flow

  Simple Request flow is a typical request where the client asks for a resource to a server or sends some resource to the server, in simple form-data or plaintext format

• Pre-flight request flow:

  In this request flow, the client does an additional server request with OPTION method before sending the actual request, to check the server’s available methods for this particular domain in the current context. Based on it’s response, it then decides to send the actual request

  There are three checks to a pre-flight request, any of them true corresponds to a pre-flight request to a server

  1. The method is not GET, POST or HEAD (e.g. PUT, DELETE)
  2. The request includes non-simple headers (like Authorization, X-Custom-Header)
  3. The request has a Content-Type other than application/x-www-form-urlencoded, multipart/form-data or text/plain

  This means, every request we do to a server which expects a json in response, which is almost all API requests, does perform a pre-flight with an OPTION method before the actual request

CORS Policy (Cross Origin Resource Sharing)

CORS allows servers to specify which client referers can access their server ports and services and who not

CORS on a Simple Request flow:

suppose a client sending a request from a frontend origin “example.com” to the server “api.example.com”. As they are not the same origin, the req-res flow is like this:

Request Header from client:

GET /api/products/123 HTTP/1.1

Host: api.example.com

Origin: https://example.com

Accept: application/json

Response Header from server:

HTTP/1.1 200 OK

Content-Type: application/json

Access-Control-Allow-Origin: https://example.com

{

“message” : “Hello there”

}

Now, the server first checks if the host and the origin domains are the same or not. If not, then it comes under the CORS policy. Then it checks the origin/referer is from the CORS allowed domain list or not, then it adds the Access-Control-Allow-Origin header in the response and adds the origin in it.

The client then verifies the header and checks if the Access-Control-Allow-Origin header is present or not, and if it has the name of it’s own as origin or ***** (denoting all origins) or not. If either of them are false, it throws an CORS error and blocks the response.

CORS on Pre-flighted request flow:

The pre-flight request header:

OPTIONS /api/resource HTTP/1.1

Host: api.example.com

Origin: https://example.com

Access-Control-Request-Method: PUT

Access-Control-Request-Headers: Authorization

And the intended server response is:

HTTP/1.1 204 No Content

Access-Control-Allow-Origin: https://example.com

Access-Control-Allow-Methods: PUT, DELETE

Access-Control-Allow-Headers: Authorization

Acces-Control-Max-Age: 86400

Here, the client asks if the server allows PUT method and Authorization header for the particular client or not. The server responds with its allowed methods and headers with 204 (as no response body is there).

The Access-Control-Max-Age header says that the server is going to contain the same settings for the next 24 hours (86400 seconds), so no further pre-flight request is required for the next 24 hrs