On the previous post (HTTP Protocol (Part 1)) we talked a little bit about HTTP basic structure. On this post, we’re gonna talk a little bit more about HTTP structure and go deep on the knowledge.

Status Codes

These are some of the Status Codes most used / known:

  • 200 – OK
    • Default successful response. It may contains response body.
  • 204 – No Content
    • Successful response in which there will never be response body. Note: even if you return response body, once with this status code response, the response body will be ignored and will be as if it had not.
  • 304 – Not Modified
    • It is used when conditional GET or HEAD requests are received and would have resulted in 200 status response, if not for the fact that the condition was false. Typically used when the client wants to see a response only if it has been changed compared to a previous request.
    • The server that generates a 304 response MUST generate any of the headers that would result 200 for the same request: Cache-Control, Content-Location, Date, ETag, Vary and Expires.
  • 400 – Bad Request
    • It means that the request could not be understood by the server due to malformed syntax.
  • 401 – Unauthorized
    • It means that for the request to proceed is required user authentication.
  • 403 – Forbidden
    • It means that the request was understood but the user is not allowed to complete the request.
  • 404 – Not Found
    • Default status when a URI is not found.
  • 500 – Internal Server Error
    • Generic error code, used when an unexpected condition is found and no specific message is suitable.


  • The headers in HTTP are used to traffic all types of meta information about the requests.
  • Several of these headers are standardized; however, they are easily extensible to accommodate any special particulars which an application may require on this direction.

These are the most used / known Headers:

  • Host – It shows which DNS was used to reach this server
  • User-Agent – It provides information on the means used to access this address
  • Accept – It performs negotiation with the server about the accepted content
  • Accept-Language – It negotiates with the server which language to be used in response
  • Accept-Encoding – It negotiates with the server which encoding to be used in response
  • Connection – Set the type of connection to the server (persistent or not)
  • Content-Type – It defines the MIME Type of the content

Host: www.casadocodigo.com.br
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:19.0) Gecko/20100101 Fire
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: pt-BR,pt;q=0.8,en-US;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate
Connection: keep-alive
Content-Type: application/json


There’s two authentication modes widely used on HTTP: Basic Auth and Digest Auth.

  • Basic Auth
    • Basically, it is to pass an Authorization header in the request using the following signature:
<br /><code>Authorization: Basic Base64UsernameAndPassword</code>

¹ – Base64UsernameAndPassword is achieved by converting to base64 the following value: username:password , in other words, uncleralph:123456 would be converted to dW5jbGVyYWxwaDoxMjM0NTY=

  • Digest Auth
    • STEP 1 – a client sends a request to a server
    • STEP 2 -the server responds with a special code (called a nonce), another string representing the ‘realm’ and asks the client to authenticate
    • STEP 3 – the client responds with this nonce and an encrypted version of the username, password and realm (a hash)
    • STEP 4 – the server responds with the requested information if the client hash matches their own hash of the username, password and realm, or an error if not

¹ – Nonce: is an arbitrary number that may only be used once.


Cookie is a small piece of data sent from a website and stored in the user’s web browser while the user is browsing.

Cookies are set using the Set-Cookie HTTP header, sent in an HTTP response from the web server. This header instructs the web browser to store the cookie and send it back in future requests to the server through Cookie Header.

  • How it works (Example)

The browser sends its first request to the homepage of the http://www.example.org website:

GET /index.html HTTP/1.1
Host: www.example.org

The server responds with two Set-Cookie headers:

HTTP/1.0 200 OK
Content-type: text/html
Set-Cookie: theme=light
Set-Cookie: sessionToken=abc123; Expires=Wed, 09 Jun 2021 10:18:14 GMT

The server’s HTTP response contains the contents of the website’s homepage. But it also instructs the browser to set two cookies. The first, “theme”, is considered to be a session cookie, since it does not have an Expires or Max-Age attribute. Session cookies are intended to be deleted by the browser when the browser closes. The second, “sessionToken” is considered to be a persistent cookie, since it contains an Expires attribute, which instructs the browser to delete the cookie at a specific date and time.

Continuing the example, the browser sends another request to visit the spec.html page on the website. This request contains a Cookie HTTP header, which contains the two cookies that the server instructed the browser to set:

GET /spec.html HTTP/1.1
Host: www.example.org
Cookie: theme=light; sessionToken=abc123

This way, the server knows that this request is related to the previous one. The server would answer by sending the requested page, possibly including more Set-Cookie headers in the response in order to add new cookies, modify existing cookies, or delete cookies.


SAUDATE, Alexandre. REST – Construa API’s inteligentes de maneira simples. ed. Casa do Código. BR.