Hypertext Transfer Protocol (HTTP)

HTTP

• HTTP (Hyper Text Transfer Protocol) is an application protocol for transmitting hypertext documents on the Internet
• The latest version of HTTP is 3
• Ports used are 80/TCP and 443/TCP, additionally 8000, 8080, 81, etc
• The protocol stack location includes:
  • Application: HTTP
  • Transport: TCP (UDP HTTP/3)
  • Network: IP
• Standards include:
  • RFC 1945 (HTTP/1.0, 1996)
  • RFC 2616 (HTTP/1.1, 1999) (RFC 9111)
  • RFC 2774 (HTTP/1.2, 2000) (RFC 9112)
  • RFC 7540 (HTTP/2, 2015) (RFC 9113)
  • RFC 9114 (HTTP/3, 2022)
• The initial HTTP version was HTTP/1.0 (RFC 1945)
• In 1998, Version 1.1 was released as RFC 2616
• HTTP/1.1 maintains backward compatibility with HTTP/1.0
• TCP is the transport protocol used
• A client sends an HTTP request to the server to request a resource in client/server communication
• The server processes the message, then sends an HTTP response that contains the resource
• HTTP is stateless
  • There's no way to relate info to previous petitions, this is solved with cookies

HTTP/1.0

• HTTP/1.0 relies on non-persistent connections
• After the server sends the resource, each TCP connection closes
  • Example: https://www.udl.cat/index.html
  • The client creates a TCP connection on port 80 of www.udl.cat server
  • The client sends a request to the server for the desired resource, such as index.html
  • The server receives the request, retrieves /index.html, and sends it back in an HTTP response
  • The server closes the connection
  • The client extracts the HTML document, then parses the data
  • These steps repeat for each resource in the HTML document

HTTP/1.1

• HTTP/1.1 introduces persistent connections, addressing the issue of excess resource use in HTTP/1.0
• Connections are kept open, which allows for the transfer of multiple resources
• Persistent connections enable pipelining
  • No pipelining means each resource transfers completely and is parsed before requesting new resources
  • In pipelining, resources are parsed as transferred and references are requested as they're found
• Clients must:
  • Mandatory host header
  • Accept responses of chunked data
  • Handle persistent connections by closing all of them when needed
  • Handle 100 Continue
• Servers should:
  • Require a "Host" header
  • Accept absolute URL in requests
  • It must include the "Date:" header
  • It must indicate the right time as "Date: Tue, 25 Nov 2008 17:15:13 GMT"
  • Accept headers to be sent in chunked data
  • To have persistent connections or include a "Connection: close" on all responses
  • If necessary, use "100 Continue"
  • Accept "If-Modified-Since" / "If-Unmodified-Since"
  • Support GET and HEAD
  • Support HTTP/1.0
• Must include destination hosts as an option
  • GET /path/file.html HTTP/1.1
  • Host: www.example.com:80
  • [blank line]
• Absolute URLs better solve multi-hosting versus "Host:" headers
• Absolute URLs are mandatory as of HTTP/1.2 and later
  • GET http://www.example.com/lang/resource.html HTTP/1.2
• Servers must provide responses in the order of the requests if a client has sent them over one connection
• If a request has a "Connection: close" header, the server needs to close the connection when it responds
• Servers may close inactive connections after a timeout
• If a server does not support persistence, it needs to show it in its header
• Except for 1xx responses (100 Continue), all answers must contain the actual time
• Servers use it always in GMT

HTTP Petition and Response Formats

• The format consists of:
  • Request line, header lines (0 or more) + blank line (CR/LF) + request body (if a POST request)
• Request line Method Request-URI HTTP-version CRLF
  • Method: Action to perform (Verb)
  • Request-URI: Resource requested
  • HTTP-Version: HTTP/1.0, HTTP/1.1
• Field name and a value delimited by CRLF
  • field-name: [field-value] CRLF
  • As many as needed
  • Mandatory (HTTP/1.1) Host:
• Request body is only required and used for POST requests
• The HTTP Response's format contains:
  • HTTP-Version Status-Code Reason-Phrase CRLF field-name: [field-value] CRLF Blank line (CR/LF) Response body
  • Status-Code: type of response
  • Reason-Phrase: Text describing the response
  • HTTP-Version = HTTP/1.0 | HTTP/1.1

Methods

• GET: Retrieve the request-URI
• HEAD: Retrieve request-URI headers
  • To get metadata from a URI, to check update time, or validate links
• POST: Request the server to perform Request-URI with data included in the HTTP request body

Headers

• Common headers include:
  • Accept, Date, Host, Referer, User-Agent
  • If-Modified-Since (GET), Connection (HTTP/1.1)
  • (BODY) Content-Length (POST), Cache-Control, Cookie

Chunked Transfer Encoding

• Servers use chunked transfer encoding to send data of unknown total size (e.g., script output, DB query results)
• The server splits data into chunks and sends them sequentially
• The response shows "Transfer-Encoding: chunked"
• All HTTP/1.1 clients should accept this format
• A chunked message has a sequence of chunks, then a line with 0 and potential footers:
  • Chunk:
  • Start with a line indicating size (hex), then ";" and potential extra parameters, and finally CRLF
  • Then the data follows
  • It ends with CRLF

Chunked vs Non-Chunked

• Example of chunked transfer:
  • `HTTP/1.1 200 OK Date: Fri, 31 Dec 1999 23:59:59 GMT Content-Type: text/plain Transfer-Encoding: chunked

1a; ignored-stuff-here abcdefghijklmnopqrstuvwxyz 10 1234567890abcdef 0 footer1: value-footer1 footer2: value-footer2 [white line]`

• Total size: 42 bytes (1a + 10)
• Equivalent transfer (non-chunked): `HTTP/1.1 200 OK Date: Fri, 31 Dec 1999 23:59:59 GMT Content-Type: text/plain Content-Length: 42

footer1: value-footer1 footer2: value-footer2 abcdefghijklmnopqrstuvwxyz1234567890abcdef`

Connection Handling

• "Connection: close" usage:
  • The connection will shutdown after the response, when the client has it
  • The client doesn't support persistent connections
  • Is the final request
  • Usage for servers and its implications
  • Servers that close connections without response require client attention
• If a request is processed and the server is slow, it might reply with the "100 Continue" code to indicate that the request has been received
• This is followed by the rest of the data
• Example:

HTTP/1.1 100 Continue

HTTP/1.1 200 OK
Date: Fri, 31 Dec 1999 23:59:59 GMT
Content-Type: text/plain
Content-Length: 42

some-footer: some-value
another-footer: another-value

abcdefghijklmnoprstuvwxyz1234567890abcdef

Status Codes

• 1xx: Informational
  • 100 Continue
• 2xx: Request success
  • 200 OK
• 3xx: Redirects (Resource changed location)
  • 301 Moved Permanently
  • 302 Moved Temporarily
• 4xx: Client Side Error
  • 400 Bad Request
  • 401 Not authorized
  • 403 Forbidden
  • 404 Not Found
• 5xx: Server Side Error
  • 500 Internal Server Error
  • 501 Not Implemented
  • 1xx - Hold On
  • 2xx - Done, here you have
  • 3xx - Leave, go to another place
  • 4xx - You incorrectly did something
  • 5xx - I incorrectly did something