HTTP — From the Deepest Basics

We have now reached the protocol that actually carries the web request and web response.

The complete foundation is:

Domain
 ↓
DNS
 ↓
IP
 ↓
Routing
 ↓
TCP
 ↓
TLS
 ↓
HTTP

Now we study HTTP itself.

1. What Is HTTP?

HTTP means:

Hypertext Transfer Protocol

At its most basic level:

HTTP
=
Rules for exchanging web messages

A browser sends an HTTP request.

A web server sends an HTTP response.

Browser
   │
   │ HTTP Request
   ▼
Web Server
   │
   │ HTTP Response
   ▼
Browser

2. HTTP Is an Application-Layer Protocol

Remember the networking layers:

Application
    ↓
HTTP

Transport
    ↓
TCP

Internet
    ↓
IP

Link
    ↓
Ethernet / Wi-Fi

For traditional HTTPS:

HTTP
 ↓
TLS
 ↓
TCP
 ↓
IP
 ↓
Ethernet/Wi-Fi

3. HTTP Doesn’t Know About Ethernet

HTTP doesn’t directly care whether the connection uses:

Ethernet
Wi-Fi
Fiber
4G
5G
Cloud networking

HTTP simply operates above the transport/security layers.

That separation is one of the most powerful ideas in networking.

4. A Web Request

Suppose you open:

https://templates.cresignsys.com/

Conceptually, the browser sends:

GET / HTTP/1.1
Host: templates.cresignsys.com

There are additional headers in a real browser request.

5. `GET`

The first word:

GET

is an HTTP method.

It tells the server:

I want to retrieve a resource.

Other important methods include:

GET
POST
PUT
PATCH
DELETE
HEAD
OPTIONS

6. URL Path

The next part:

is the path.

For example:

https://templates.cresignsys.com/about

has:

Path:
/about

Another example:

https://templates.cresignsys.com/blog/hello

has:

Path:
/blog/hello

7. HTTP Version

You may see:

HTTP/1.1

This identifies the HTTP protocol version used for that request.

Modern websites may also use:

HTTP/2
HTTP/3

We will study these separately.

8. Host Header

A request can contain:

Host: templates.cresignsys.com

This tells the HTTP server which hostname the request is intended for.

This is extremely important when one IP hosts multiple websites.

9. One IP, Multiple Websites

Imagine:

203.0.113.10

hosts:

templates.cresignsys.com
learn.cresignsys.com
shop.cresignsys.com

The HTTP request can identify:

Host: templates.cresignsys.com

Nginx can then choose the corresponding virtual host.

Conceptually:

Same IP
   │
   ▼
Nginx
   │
   ├── Host: templates → Site A
   ├── Host: learn     → Site B
   └── Host: shop      → Site C

10. HTTP Headers

HTTP messages contain headers.

Example:

GET / HTTP/1.1
Host: templates.cresignsys.com
User-Agent: ...
Accept: text/html
Accept-Language: en-US
Connection: ...

Headers provide metadata about the request.

11. Header = Name + Value

Conceptually:

Header-Name: Header-Value

For example:

Host: templates.cresignsys.com

means:

Name:
Host

Value:
templates.cresignsys.com

12. Why Headers Exist

HTTP needs to communicate more than:

"I want this page."

It may need to communicate:

Which hostname?
What content can I accept?
What language?
What cookies do I have?
What authentication information?
What browser/client am I using?
What content format?

Headers provide this metadata.

13. HTTP Request Structure

Conceptually:

Request Line
     ↓
Headers
     ↓
Blank Line
     ↓
Optional Body

Example:

GET /about HTTP/1.1
Host: templates.cresignsys.com
Accept: text/html

The blank line separates headers from the optional body.

14. GET Usually Has No Request Body

A basic GET request often looks like:

GET / HTTP/1.1
Host: templates.cresignsys.com

No body is required.

The server receives the request and generates a response.

15. POST

POST is commonly used when the client sends data to the server.

For example:

POST /login HTTP/1.1
Host: templates.cresignsys.com
Content-Type: application/x-www-form-urlencoded
Content-Length: ...

username=abey&password=...

The exact request would depend on the application.

Important:

Never put a real password into a tutorial command or share it in chat.

16. Request Body

A request can have a body.

Conceptually:

Request
 ├── Method
 ├── Path
 ├── Headers
 └── Body

The body may contain:

Form data
JSON
XML
Images
Files
Other data

depending on the application.

17. JSON API Example

A modern web application might send:

POST /api/users HTTP/1.1
Host: example.com
Content-Type: application/json

{"name":"John","age":30}

The body is JSON.

This is extremely common in web APIs.

18. HTTP Response

The server responds.

For example:

HTTP/1.1 200 OK
Content-Type: text/html

<html>
...
</html>

The response contains:

Status line
 ↓
Headers
 ↓
Blank line
 ↓
Body

19. Status Code

The first important part of the response is:

This is the status code.

It tells the client broadly what happened.

20. HTTP Status Code Groups

HTTP status codes are grouped by their first digit.

1xx → Informational
2xx → Success
3xx → Redirection
4xx → Client-related error
5xx → Server-related error

Memorize this first.

21. 2xx — Success

Common examples:

200 OK
201 Created
204 No Content

22. 200 OK

The most familiar response:

HTTP/1.1 200 OK

means the request was successfully processed.

For a webpage:

Browser
 ↓
GET /
 ↓
Nginx/WordPress
 ↓
200 OK
 ↓
HTML

23. 201 Created

Often used after successfully creating a resource.

For example:

POST /users

might produce:

201 Created

This is common in APIs.

24. 204 No Content

Means the request succeeded but there is no response body to return.

Example:

DELETE /resource/123

could return:

204 No Content

25. 3xx — Redirects

Examples:

301 Moved Permanently
302 Found
303 See Other
307 Temporary Redirect
308 Permanent Redirect

These tell the client to look elsewhere or make another request according to the redirect semantics.

26. HTTP → HTTPS Redirect

A common web hosting configuration is:

http://templates.cresignsys.com

redirecting to:

https://templates.cresignsys.com

Conceptually:

Browser
 ↓
HTTP :80
 ↓
Nginx
 ↓
301/308
 ↓
HTTPS :443

This is an HTTP redirect.

It is not DNS.

27. 4xx — Client-Side Request Problems

Common examples:

400 Bad Request
401 Unauthorized
403 Forbidden
404 Not Found
405 Method Not Allowed
429 Too Many Requests

These generally indicate that the request cannot be successfully fulfilled as made, though the exact reason varies.

28. 400 Bad Request

The server cannot properly process the request because it is malformed or invalid.

Conceptually:

Browser
 ↓
Invalid request
 ↓
Server
 ↓
400

29. 401 Unauthorized

This generally indicates that authentication is required or has failed.

For example:

GET /private

could return:

401 Unauthorized

HTTP authentication mechanisms can then be involved.

30. 403 Forbidden

The server understood the request but refuses to fulfill it.

For example:

Browser
 ↓
GET /private
 ↓
Server
 ↓
403 Forbidden

31. 404 Not Found

The requested resource could not be found.

Example:

GET /abc123

might return:

404 Not Found

In WordPress, 404 behavior can involve Nginx configuration and WordPress’s routing system.

32. 5xx — Server Errors

Common examples:

500 Internal Server Error
502 Bad Gateway
503 Service Unavailable
504 Gateway Timeout

These are particularly important for web hosting.

33. 500

The server encountered an internal error.

For WordPress this could result from:

PHP error
Plugin error
Theme error
Application error
Server configuration

34. 502

Often associated with an upstream problem.

For your architecture:

Browser
 ↓
Nginx
 ↓
PHP-FPM

If Nginx cannot communicate properly with PHP-FPM:

Nginx
   X
PHP-FPM

you may receive:

502 Bad Gateway

35. 503

Usually indicates service unavailability.

Possible causes include:

Service stopped
Temporary overload
Maintenance
Application unavailable
Upstream unavailable

The exact cause depends on the configuration.

36. 504

A gateway or proxy waited too long for an upstream response.

Conceptually:

Nginx
 ↓
PHP-FPM / upstream
 ↓
too slow
 ↓
timeout
 ↓
504

37. HTTP Request Lifecycle

Let’s follow your website.

Browser
   ↓
GET /
   ↓
TLS
   ↓
Nginx
   ↓
Find server block
   ↓
Find resource
   ↓
Maybe PHP-FPM
   ↓
WordPress
   ↓
MySQL
   ↓
Generate response
   ↓
Nginx
   ↓
HTTP response
   ↓
Browser

38. HTTP and Nginx

Nginx is an HTTP server/reverse proxy.

It understands things such as:

GET
POST
Host
Content-Type
Cookies
HTTP status codes
URLs
Headers

This is why Nginx sits directly at the HTTP layer.

39. HTTP and PHP

PHP doesn’t normally receive raw Internet traffic directly.

Your architecture is more like:

Internet
 ↓
TLS
 ↓
Nginx
 ↓
FastCGI
 ↓
PHP-FPM
 ↓
PHP

Nginx handles the HTTP-facing connection.

PHP-FPM executes PHP code.

40. HTTP and WordPress

WordPress receives application-level information derived from the HTTP request.

For:

GET /about

WordPress can determine:

Requested URL
Query parameters
Cookies
Headers
User state

and then decide what content to generate.

41. HTTP Query Parameters

Consider:

https://templates.cresignsys.com/search?q=keyboard

The path is:

/search

The query string is:

?q=keyboard

Conceptually:

URL
 ├── Scheme
 ├── Host
 ├── Port
 ├── Path
 └── Query

42. Query String

Example:

/search?q=keyboard&page=2

contains:

q = keyboard
page = 2

The server/application can use these values.

43. Fragment

Consider:

https://example.com/page#section2

The:

#section2

is a URL fragment.

An important distinction:

The fragment is normally processed by the browser and is not sent to the server as part of the HTTP request.

So the HTTP request generally contains:

/page

not:

/page#section2

44. URL Structure

Let’s break down:

https://templates.cresignsys.com:443/about?x=10#top

into:

Scheme:
https

Host:
templates.cresignsys.com

Port:
443

Path:
/about

Query:
x=10

Fragment:
top

This is important web infrastructure knowledge.

45. HTTP Headers — Important Ones

Learn these:

Host
User-Agent
Accept
Content-Type
Content-Length
Authorization
Cookie
Set-Cookie
Cache-Control
Location
Referer
Origin

There are many more.

46. `Content-Type`

This tells the receiver what kind of content is being transmitted.

Examples:

text/html
text/css
application/javascript
application/json
image/png
image/jpeg
application/pdf

For example:

Content-Type: text/html

means the response contains HTML content.

47. HTML

A basic response might be:

HTTP/1.1 200 OK
Content-Type: text/html

<!doctype html>
<html>
<head>
<title>Hello</title>
</head>
<body>
<h1>Hello</h1>
</body>
</html>

The browser interprets the HTML.

48. CSS

The HTML can reference:

style.css

The browser then makes another HTTP request:

GET /style.css

The server responds:

Content-Type: text/css

This is an important realization:

Opening one webpage can generate many HTTP requests.

49. JavaScript

Similarly:

GET /app.js

might return:

Content-Type: application/javascript

The browser executes the JavaScript.

50. Images

The page may request:

GET /images/logo.png

The response may contain:

Content-Type: image/png

So one page can cause:

HTML request
 ↓
CSS requests
 ↓
JavaScript requests
 ↓
Image requests
 ↓
Font requests
 ↓
API requests

51. One Page = Many HTTP Requests

Conceptually:

Browser
 │
 ├── GET /
 ├── GET /style.css
 ├── GET /app.js
 ├── GET /logo.png
 ├── GET /font.woff2
 └── GET /api/data

This is why a webpage is not normally just “one request.”

52. Cookies

HTTP is fundamentally request/response based, while web applications often need to remember users between requests.

Cookies help.

Server response:

Set-Cookie: session=...

Browser stores the cookie.

Later:

Cookie: session=...

The browser sends it back to the server.

53. Cookie Flow

Server
 ↓
Set-Cookie
 ↓
Browser
 ↓
stores cookie
 ↓
Next request
 ↓
Cookie
 ↓
Server

This allows applications to maintain state across multiple requests.

54. WordPress and Cookies

WordPress can use cookies for things such as:

Login state
Sessions/authentication-related state
Preferences
Other application behavior

Plugins may also set cookies.

55. HTTP Is Stateless

A basic HTTP request doesn’t inherently contain memory of previous requests.

For example:

Request 1
Request 2
Request 3

are separate HTTP messages.

Applications add state using mechanisms such as:

Cookies
Sessions
Tokens
Databases

56. Authentication

HTTP applications can authenticate users through mechanisms including:

Cookies
Sessions
Authorization headers
Bearer tokens
Basic authentication
OAuth-related flows

Modern web applications often combine several technologies.

57. HTTPS Protects HTTP

Without TLS:

HTTP
 ↓
TCP
 ↓
IP

With HTTPS:

HTTP
 ↓
TLS
 ↓
TCP
 ↓
IP

TLS protects the HTTP traffic in transit.

So someone monitoring the network should not simply be able to read:

GET /private
Cookie: ...

from the encrypted connection.

58. HTTP vs HTTPS

HTTP:

Application data
 ↓
TCP

HTTPS:

Application data
 ↓
TLS encryption/authentication
 ↓
TCP

The application protocol remains HTTP.

TLS provides the security layer.

59. HTTP/1.0

Historically, HTTP/1.0 used a relatively simple request/response model.

Connections were often closed after a response unless connection reuse mechanisms were used.

HTTP evolved because modern websites became much more complex.

60. HTTP/1.1

HTTP/1.1 introduced important improvements including persistent connections and the standardized Host header behavior that enabled practical name-based virtual hosting.

A connection can carry multiple requests/responses sequentially.

Conceptually:

TCP connection
 ├── Request 1
 ├── Response 1
 ├── Request 2
 ├── Response 2
 └── ...

61. HTTP/1.1 Limitation

HTTP/1.1 messages on a single connection are fundamentally ordered.

This can contribute to:

Head-of-line blocking

at the HTTP message level.

Modern protocols address this differently.

62. HTTP/2

HTTP/2 changed the way HTTP messages are transported.

It supports:

Binary framing
Multiplexing
Header compression
Stream prioritization mechanisms

Conceptually:

One connection
      │
 ┌────┼────┬────┬────┐
 ▼    ▼    ▼    ▼    ▼
Req1 Req2 Req3 Req4 ...

Multiple streams can share one connection.

63. HTTP/3

HTTP/3 uses:

HTTP/3
 ↓
QUIC
 ↓
UDP
 ↓
IP

instead of the traditional:

HTTP/2
 ↓
TLS
 ↓
TCP
 ↓
IP

QUIC integrates TLS 1.3 into its transport design.

64. Important Evolution

Remember:

HTTP/1.1
   ↓
TCP

HTTP/2
   ↓
TCP + TLS

HTTP/3
   ↓
QUIC
   ↓
UDP

This is a simplified conceptual map; protocol negotiation and deployment details can vary.

65. How to Check HTTP

Run:

curl -I https://templates.cresignsys.com

This asks for response headers.

You may see something like:

HTTP/2 200
content-type: text/html
...

If HTTP/2 is negotiated.

66. Force HTTP/1.1

You can test:

curl --http1.1 -I https://templates.cresignsys.com

This helps you understand protocol negotiation.

67. Test HTTP/2

Try:

curl --http2 -I https://templates.cresignsys.com

Support depends on how your curl build and server are configured.

68. Test HTTP/3

Support depends on your curl build and server.

A modern curl build may support:

curl --http3 -I https://templates.cresignsys.com

If unsupported, curl will report that HTTP/3 isn’t available in that build/environment.

Don’t install anything yet just for this lesson.

69. Inspect the Response

Use:

curl -v https://templates.cresignsys.com

You may observe:

* Connected
* TLS handshake
* SSL certificate
> GET /
> Host: templates.cresignsys.com
< HTTP/...
< content-type: ...

This is where your previous lessons become visible in one command.

70. The Complete Request

Conceptually:

Browser
   │
   │ DNS
   ▼
IP address
   │
   │ TCP
   ▼
Connection
   │
   │ TLS
   ▼
Secure channel
   │
   │ HTTP
   ▼
GET /
Host: templates.cresignsys.com
   │
   ▼
Nginx

71. Nginx Receives the Request

Nginx can inspect:

Method
Path
Host
Headers
Body

Then it decides:

Static file?
Proxy?
PHP?
Redirect?
Error?

72. Example: Static Request

GET /logo.png

Nginx:

Request
 ↓
Document root
 ↓
logo.png
 ↓
Read file
 ↓
HTTP response

PHP is unnecessary.

73. Example: WordPress Request

GET /about/

Nginx may determine that the request should ultimately be handled by WordPress.

Conceptually:

GET /about/
 ↓
Nginx
 ↓
index.php
 ↓
PHP-FPM
 ↓
WordPress
 ↓
MySQL
 ↓
HTML
 ↓
Nginx
 ↓
Browser

74. HTTP Rewrite

WordPress commonly uses URL rewriting so URLs such as:

/about/

can be handled by:

index.php

rather than requiring a physical file:

/about/index.html

The exact behavior depends on your Nginx configuration.

75. HTTP Redirect in WordPress

WordPress or Nginx may redirect:

http://...

to:

https://...

or:

www.example.com

to:

example.com

These are HTTP-level behaviors.

DNS itself isn’t performing the redirect.

76. HTTP Caching

HTTP also contains caching mechanisms.

Important headers include:

Cache-Control
Expires
ETag
Last-Modified

Caching can occur at:

Browser
CDN
Reverse proxy
Web server

This is another major web-hosting topic.

77. ETag

An ETag is a representation identifier used for cache validation.

Conceptually:

First response:
ETag: "abc123"

Later the browser may ask:

If-None-Match: "abc123"

If the resource hasn’t changed, the server can respond:

304 Not Modified

This can avoid retransmitting the full resource.

78. 304 Not Modified

A 304 response means the cached representation can be reused under the request’s conditional caching rules.

Conceptually:

Browser cache
      │
      │ Is my copy still valid?
      ▼
Server
      │
      │ 304
      ▼
Browser
      │
      ▼
Use cached copy

79. HTTP Compression

Servers can compress content.

Common mechanisms include:

gzip
Brotli

The browser advertises what it supports.

For example:

Accept-Encoding: gzip, br

The server may respond with:

Content-Encoding: br

depending on configuration.

80. Why Compression Matters

Suppose HTML is:

500 KB

Compression may significantly reduce the amount transmitted.

This improves:

Bandwidth usage
Page transfer time
Server efficiency

Actual gains depend on the content.

81. HTTP Content Negotiation

The browser can tell the server what it can accept.

Examples:

Accept:
Accept-Encoding:
Accept-Language:

The server can select an appropriate representation.

Conceptually:

Browser
 ↓
I support:
HTML
Brotli
English
 ↓
Server
 ↓
Best representation

82. The Web Is a Chain of Protocols

We can now see:

DNS
 ↓
IP
 ↓
TCP
 ↓
TLS
 ↓
HTTP
 ↓
HTML
 ↓
CSS
 ↓
JavaScript
 ↓
Application

Each technology solves a different problem.

83. The Most Important Distinction

Memorize this:

DNS
"What IP?"

IP
"Where?"

TCP
"Reliable connection."

TLS
"Secure/authenticated channel."

HTTP
"Web request/response."

HTML
"Page structure."

CSS
"Page presentation."

JavaScript
"Page behavior."

PHP
"Server-side application execution."

MySQL
"Data storage."

This is the conceptual backbone of web hosting.

84. Your Actual Hosting Stack

For your Ubuntu VPS:

Internet
   ↓
DNS
   ↓
Public IP
   ↓
Cloud networking
   ↓
TCP 443
   ↓
TLS
   ↓
Nginx
   ↓
FastCGI
   ↓
PHP-FPM
   ↓
WordPress
   ↓
MySQL
   ↓
Filesystem

Now we can start studying each connection between these components.

85. Practical Exercise

Run:

curl -I https://templates.cresignsys.com

Then:

curl -v https://templates.cresignsys.com

Then:

curl --http1.1 -I https://templates.cresignsys.com

Then, if supported:

curl --http2 -I https://templates.cresignsys.com

Look for:

HTTP version
Status code
Content-Type
Server
Location
Cache-Control
Set-Cookie

Do not worry if some headers differ from examples.

86. One Complete Request

Your entire journey now looks like:

USER
 │
 ▼
BROWSER
 │
 │ templates.cresignsys.com
 ▼
DNS
 │
 ▼
IP ADDRESS
 │
 ▼
ROUTING
 │
 ▼
TCP 443
 │
 ▼
TLS
 │
 ├── Certificate
 ├── SNI
 └── Session keys
 │
 ▼
HTTP
 │
 ├── GET
 ├── Host
 ├── Headers
 └── Body
 │
 ▼
NGINX
 │
 ├── Static file
 │
 └── PHP-FPM
       │
       ▼
    WORDPRESS
       │
       ▼
     MYSQL
       │
       ▼
    RESPONSE
       │
       ▼
     NGINX
       │
       ▼
      TLS
       │
       ▼
      TCP
       │
       ▼
    INTERNET
       │
       ▼
    BROWSER

Lesson 029 Summary

You should now understand:

HTTP
Request
Response
Methods
Headers
Body
Status codes
Cookies
Query strings
Redirects
Caching
Content-Type
HTTP/1.1
HTTP/2
HTTP/3

And most importantly:

DNS
 ↓
IP
 ↓
TCP
 ↓
TLS
 ↓
HTTP
 ↓
Nginx
 ↓
PHP-FPM
 ↓
WordPress
 ↓
MySQL

Next Lesson — 030

HTTP Request → Nginx → PHP-FPM → WordPress

We will trace one actual WordPress page request byte-by-byte conceptually:

GET /
 ↓
TLS decryption
 ↓
Nginx parses request
 ↓
server_name matching
 ↓
location matching
 ↓
try_files
 ↓
index.php
 ↓
FastCGI
 ↓
PHP-FPM
 ↓
WordPress bootstrap
 ↓
wp-config.php
 ↓
MySQL
 ↓
Theme
 ↓
HTML
 ↓
Nginx
 ↓
TLS
 ↓
Browser

This is where your understanding changes from “I know web hosting terms” to “I understand how a WordPress hosting server actually processes a request.”

CresignSys Learn — Lesson 029

HTTP — From the Deepest Basics

1. What Is HTTP?

Hypertext Transfer Protocol

2. HTTP Is an Application-Layer Protocol

3. HTTP Doesn’t Know About Ethernet

4. A Web Request

5. GET

6. URL Path

7. HTTP Version

8. Host Header

9. One IP, Multiple Websites

10. HTTP Headers

11. Header = Name + Value

12. Why Headers Exist

13. HTTP Request Structure

14. GET Usually Has No Request Body

15. POST

16. Request Body

17. JSON API Example

18. HTTP Response

19. Status Code

20. HTTP Status Code Groups

21. 2xx — Success

22. 200 OK

23. 201 Created

24. 204 No Content

25. 3xx — Redirects

26. HTTP → HTTPS Redirect

27. 4xx — Client-Side Request Problems

28. 400 Bad Request

29. 401 Unauthorized

30. 403 Forbidden

31. 404 Not Found

32. 5xx — Server Errors

33. 500

34. 502

35. 503

36. 504

37. HTTP Request Lifecycle

38. HTTP and Nginx

39. HTTP and PHP

40. HTTP and WordPress

41. HTTP Query Parameters

42. Query String

43. Fragment

44. URL Structure

45. HTTP Headers — Important Ones

46. Content-Type

47. HTML

48. CSS

49. JavaScript

50. Images

51. One Page = Many HTTP Requests

52. Cookies

53. Cookie Flow

54. WordPress and Cookies

55. HTTP Is Stateless

56. Authentication

57. HTTPS Protects HTTP

58. HTTP vs HTTPS

59. HTTP/1.0

60. HTTP/1.1

61. HTTP/1.1 Limitation

62. HTTP/2

63. HTTP/3

64. Important Evolution

65. How to Check HTTP

66. Force HTTP/1.1

67. Test HTTP/2

68. Test HTTP/3

69. Inspect the Response

70. The Complete Request

71. Nginx Receives the Request

72. Example: Static Request

73. Example: WordPress Request

74. HTTP Rewrite

75. HTTP Redirect in WordPress

76. HTTP Caching

77. ETag

5. `GET`

46. `Content-Type`