HTTP Deep Dive — How a Web Request Actually Works

We now know:

Domain
 ↓
DNS
 ↓
IP
 ↓
Routing
 ↓
TCP
 ↓
Port 443
 ↓
Nginx

Now we need to understand what happens after the browser reaches Nginx.

That is the job of:

HTTP

1. What Is HTTP?

HTTP means:

Hypertext Transfer Protocol

It is the protocol used for communication between a web client and a web server.

Simplified:

Browser
   ↓
HTTP Request
   ↓
Web Server
   ↓
HTTP Response
   ↓
Browser

2. HTTPS

When HTTP is protected by TLS:

HTTP
 +
TLS
 =
HTTPS

So:

http://example.com

normally uses:

TCP 80

while:

https://example.com

normally uses:

TCP 443

3. The First Request

Suppose you open:

https://learn.cresignsys.com/about/

After DNS and the network connection are established, the browser sends an HTTP request.

Conceptually:

GET /about/ HTTP/1.1
Host: learn.cresignsys.com

There are additional headers in a real browser request.

4. HTTP Request

An HTTP request contains several important parts:

Request
├── Method
├── URL/path
├── Headers
└── Body

For example:

GET /about/

is the main request line.

5. HTTP Methods

The most important HTTP methods are:

GET
POST
PUT
PATCH
DELETE
HEAD
OPTIONS

For basic WordPress hosting, start with:

GET
POST

6. GET

GET generally means:

Give me this resource.

Example:

GET /about/

The browser is asking the server for the About page.

7. Another GET

For:

https://learn.cresignsys.com/contact/

the request may be:

GET /contact/ HTTP/1.1
Host: learn.cresignsys.com

8. POST

POST is commonly used to send data to the server.

For example:

Login form
Contact form
WordPress admin login
Comment submission

A simplified request:

POST /wp-login.php HTTP/1.1

The submitted data is normally in the request body.

9. Request Body

For example, a form submission might contain data such as:

username=admin
password=...

The actual request encoding and security depend on the application.

With HTTPS, the network transport is encrypted.

10. HTTP Headers

Headers provide additional information.

Example:

Host: learn.cresignsys.com
User-Agent: ...
Accept: text/html
Accept-Encoding: gzip, br

Headers tell the server about the request and tell the client how to interpret the response.

11. Host Header

This is extremely important for hosting.

Suppose the same VPS hosts:

siteA.com
siteB.com
siteC.com

All have:

203.0.113.25

The browser sends:

Host: siteB.com

Nginx can then choose the appropriate website.

12. Virtual Hosting

Therefore:

203.0.113.25
      │
      ├── siteA.com
      ├── siteB.com
      └── siteC.com

is possible.

Nginx uses hostname information to route the request to the correct server configuration.

13. Nginx Server Block

A simplified configuration:

server {
    listen 443 ssl;
    server_name siteB.com www.siteB.com;

    root /storage/websites/siteB.com/public;
}

The important relationship is:

Host: siteB.com
        ↓
server_name siteB.com
        ↓
document root

14. URL Structure

Consider:

https://learn.cresignsys.com/blog/post-1/?page=2

Break it down:

https://
learn.cresignsys.com
/blog/post-1/
?page=2

These components have different purposes.

15. Scheme

https://

is the scheme.

It tells the client to use HTTPS.

16. Host

learn.cresignsys.com

is the hostname.

DNS resolves this hostname.

17. Path

/blog/post-1/

is the path.

It identifies the requested resource within the website.

18. Query String

?page=2

is the query string.

It passes additional parameters.

Example:

/search/?q=wordpress

Here:

q=wordpress

is a query parameter.

19. Fragment

You might see:

/about/#services

The:

#services

is a URL fragment.

Normally, the fragment is handled by the browser and is not sent to the server as part of the HTTP request.

This distinction is important.

20. Complete URL

https://learn.cresignsys.com/about/?lang=en#history

Breakdown:

Scheme:
https

Host:
learn.cresignsys.com

Path:
/about/

Query:
lang=en

Fragment:
history

21. HTTP Response

After receiving the request, the server responds.

Example:

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

Then comes the response body:

<html>
...
</html>

22. Response Structure

An HTTP response contains:

Response
├── Status code
├── Headers
└── Body

23. Status Codes

HTTP status codes are grouped into categories:

1xx
2xx
3xx
4xx
5xx

You should memorize the most important ones.

24. 200

200 OK

means the request was successfully handled.

Example:

GET /
 ↓
200 OK

25. 201

201 Created

means a resource was successfully created.

This is common in APIs.

26. 204

204 No Content

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

27. 301

301 Moved Permanently

indicates a permanent redirect.

Example:

http://example.com
        ↓
301
        ↓
https://example.com

28. 302

302 Found

is commonly used for temporary redirects.

Redirect behavior is more nuanced across HTTP versions and applications, but the key idea is:

server
 ↓
redirect
 ↓
another URL

29. 304

304 Not Modified

is used with caching.

It tells the browser that the cached representation can still be used when the request conditions allow it.

30. 400

400 Bad Request

means the server considers the request malformed or invalid.

31. 401

401 Unauthorized

means authentication is required or failed.

Despite the name, this generally means:

Authentication is needed.

32. 403

403 Forbidden

means the server understood the request but refuses to authorize access.

Common causes:

permission
access rules
directory restrictions
application authorization

33. 404

404 Not Found

means the requested resource could not be found.

For example:

GET /does-not-exist/

may return:

404 Not Found

34. 405

405 Method Not Allowed

means the resource exists but does not allow the HTTP method used.

35. 408

408 Request Timeout

indicates the server timed out waiting for the request.

36. 429

429 Too Many Requests

usually means rate limiting has been triggered.

This can be generated by:

Nginx
application
CDN
API gateway
security layer

37. 500

500 Internal Server Error

means the server encountered an unexpected error.

For WordPress, possible causes include:

PHP error
plugin error
theme error
configuration error

38. 502

502 Bad Gateway

is particularly important in your hosting environment.

It often means a proxy such as Nginx could not obtain a valid response from its upstream service.

For WordPress:

Nginx
 ↓
PHP-FPM

If PHP-FPM is unavailable or misconfigured, you may get:

39. 503

503 Service Unavailable

means the server is currently unable to handle the request.

Possible reasons include:

overload
maintenance
upstream unavailable
application limits

40. 504

504 Gateway Timeout

means a gateway/proxy waited too long for an upstream response.

Example:

Nginx
 ↓
PHP-FPM
 ↓
MySQL

If the upstream operation takes too long, a timeout can occur.

41. Status Code Troubleshooting

Memorize this table:

Code	Meaning	Hosting clue
200	OK	Working
301	Permanent redirect	URL redirect
302	Temporary redirect	Redirect
304	Not modified	Cache
400	Bad request	Invalid request
401	Authentication required	Login/auth
403	Forbidden	Access/permissions
404	Not found	URL/resource
429	Too many requests	Rate limit
500	Server error	PHP/application
502	Bad gateway	PHP-FPM/upstream
503	Unavailable	Service/load
504	Gateway timeout	Slow upstream

42. `curl`

For web hosting, curl is one of your most important tools.

Test:

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

The -I option requests headers without downloading the full body in the usual way.

43. Example

You may see:

HTTP/2 200
server: nginx
content-type: text/html

Now you know:

DNS ✓
network ✓
TLS ✓
Nginx ✓
HTTP ✓

at least at a basic level.

44. Follow Redirects

Use:

curl -IL https://learn.cresignsys.com

The:

-L

option follows redirects.

You may see:

301
 ↓
https://...
 ↓
200

45. See More Details

Use:

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

This can show details about:

DNS connection
TCP connection
TLS
HTTP request
HTTP response

It is extremely useful for troubleshooting.

46. TLS + HTTP

When you run:

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

you can see the stages:

DNS
 ↓
TCP connection
 ↓
TLS handshake
 ↓
HTTP request
 ↓
HTTP response

This connects our previous lessons together.

47. HTTP Headers

Some important response headers include:

Content-Type
Content-Length
Cache-Control
Location
Set-Cookie
Server
ETag
Last-Modified

48. Content-Type

Example:

Content-Type: text/html

means the body is HTML.

Other examples:

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

49. Why Content-Type Matters

The browser uses the content type to determine how to interpret the response.

For example:

text/html

→ render as HTML.

image/png

→ interpret as PNG image.

50. Content-Length

Example:

Content-Length: 48291

This indicates the size of the response body in bytes in contexts where this header is used.

51. Cache-Control

Example:

Cache-Control: max-age=3600

This provides caching instructions.

Caching is extremely important for hosting performance.

52. Browser Cache

Suppose your website contains:

style.css
logo.png
script.js

Downloading them repeatedly wastes resources.

The browser can cache them.

Therefore:

First visit
 ↓
download
 ↓
cache

Later:

visit
 ↓
use cache

when the caching rules permit.

53. Server Cache

You can also cache on the server side.

For WordPress:

Browser
 ↓
Nginx
 ↓
cache
 ↓
HTML

can avoid invoking PHP for every request.

54. WordPress Without Cache

A request may look like:

Browser
 ↓
Nginx
 ↓
PHP-FPM
 ↓
WordPress
 ↓
MySQL
 ↓
WordPress
 ↓
PHP
 ↓
Nginx
 ↓
Browser

This involves significant processing.

55. WordPress With Page Cache

With an effective page cache:

Browser
 ↓
Nginx
 ↓
cached HTML
 ↓
Browser

The PHP/MySQL path can sometimes be avoided for cacheable requests.

56. Why This Matters for Hosting

Suppose you host:

100 websites

and each receives many requests.

If every request reaches:

PHP
+
MySQL

resource consumption can become substantial.

Caching can dramatically reduce backend work.

57. Cookies

HTTP can use:

Cookies

A server can send:

Set-Cookie: session=...

The browser stores the cookie according to its attributes and policies.

Later requests can include:

Cookie: session=...

58. Why WordPress Uses Cookies

WordPress uses cookies for functionality such as:

login
authentication
preferences
sessions

59. Login Example

Simplified:

Browser
 ↓
POST /wp-login.php
 ↓
WordPress
 ↓
authentication
 ↓
Set-Cookie
 ↓
Browser

Then:

Browser
 ↓
Cookie
 ↓
WordPress

allows WordPress to recognize the authenticated session.

60. HTTP Is Stateless

HTTP itself is fundamentally stateless.

That means each request can be processed independently.

Cookies and application-level session mechanisms allow applications to maintain continuity between requests.

61. Example

Without session information:

Request 1
Who are you?

Request 2
Who are you?

Request 3
Who are you?

With authentication cookies:

Request
 ↓
Cookie
 ↓
User identified

62. Security Attributes of Cookies

Important cookie attributes include:

Secure
HttpOnly
SameSite

Secure

Cookie should be sent over secure connections.

HttpOnly

Helps prevent client-side JavaScript from directly reading the cookie.

SameSite

Controls cross-site cookie sending behavior.

63. HTTP Compression

Web servers can compress responses.

Common compression mechanisms include:

gzip
Brotli

Example:

HTML
 ↓
compression
 ↓
smaller transfer
 ↓
browser
 ↓
decompression

64. Why Compression Helps

Suppose:

HTML = 500 KB

Compression might reduce the transferred size significantly.

Less data means:

less bandwidth
faster transfer

depending on network conditions and content.

65. HTTP/1.1

Traditional HTTP/1.1 uses textual requests and responses.

Example:

GET / HTTP/1.1
Host: example.com

It is still widely supported.

66. HTTP/2

HTTP/2 improves how multiple requests can be transported over a connection.

It supports concepts such as:

multiplexing
header compression
binary framing

67. HTTP/2 Multiplexing

Instead of treating requests as completely independent serial transfers at the HTTP layer, HTTP/2 can multiplex multiple streams over one connection.

Conceptually:

TCP connection
│
├── HTML stream
├── CSS stream
├── JS stream
├── image stream
└── API stream

This can improve efficiency.

68. HTTP/3

HTTP/3 uses:

HTTP/3
 ↓
QUIC
 ↓
UDP

rather than the traditional:

HTTP/2
 ↓
TLS
 ↓
TCP

HTTP/3 is an advanced topic, but it is useful to know that modern web hosting can involve it.

69. Your Nginx Server

Nginx can be configured to support modern HTTP versions depending on the build and configuration.

You don’t need to enable every feature immediately.

For your hosting platform, first make:

HTTP/1.1 or HTTP/2
+
HTTPS
+
PHP-FPM
+
WordPress

reliable.

70. HTTP Request to WordPress

Now let’s follow:

https://learn.cresignsys.com/about/

71. Step 1

Browser performs DNS:

learn.cresignsys.com
        ↓
IP

72. Step 2

Browser establishes network connectivity:

TCP
 ↓
443

73. Step 3

TLS handshake:

Browser
 ↕
Nginx

Certificate is validated according to the browser’s trust rules.

74. Step 4

Browser sends:

GET /about/ HTTP/2
Host: learn.cresignsys.com

The exact wire representation differs with HTTP/2, but conceptually this is the request.

75. Step 5

Nginx receives it.

Nginx examines:

Host
Path
Method
Headers

76. Step 6

Nginx determines:

server_name

matches:

learn.cresignsys.com

77. Step 7

Nginx determines the requested resource.

For a typical WordPress setup, a pretty URL such as:

/about/

may not correspond to a physical directory named:

/about/

78. WordPress Front Controller

WordPress commonly uses:

index.php

as its front controller.

Conceptually:

/about/
   ↓
Nginx rewrite
   ↓
index.php
   ↓
WordPress

79. Typical Nginx Concept

A WordPress configuration often contains logic conceptually similar to:

location / {
    try_files $uri $uri/ /index.php?$args;
}

Meaning:

Does the file exist?
        │
     yes│no
        ▼
serve file
        │
        └────→ index.php

The exact configuration should be adapted to your PHP-FPM and site architecture.

80. PHP-FPM

If Nginx determines the request needs PHP:

Nginx
 ↓
PHP-FPM

Nginx communicates with PHP-FPM through a configured FastCGI interface.

Commonly this is:

Unix socket

or:

TCP socket

81. Unix Socket

You may see something like:

/run/php/php8.x-fpm.sock

The exact PHP version and socket path depend on your installation.

Nginx uses the configured socket to communicate with PHP-FPM.

82. PHP-FPM Executes WordPress

PHP-FPM receives:

index.php

and executes PHP.

WordPress loads:

core
themes
plugins
configuration

and eventually queries MySQL where required.

83. MySQL

WordPress might execute database queries such as:

SELECT ...

The database returns:

posts
pages
users
settings
metadata

84. WordPress Generates HTML

PHP combines:

WordPress core
+
theme
+
plugins
+
database data

and produces an HTML response.

85. Response Returns

The flow reverses:

MySQL
 ↓
WordPress
 ↓
PHP-FPM
 ↓
Nginx
 ↓
TLS
 ↓
Internet
 ↓
Browser

86. Browser Receives HTML

The browser parses:

<html>
<head>
...
</head>
<body>
...
</body>
</html>

But the page usually contains references to additional resources.

For example:

CSS
JavaScript
images
fonts

87. Additional Requests

The browser may then request:

/style.css
/script.js
/logo.png
/font.woff2

So one page load can create many HTTP requests.

Conceptually:

HTML
 ├── CSS request
 ├── JS request
 ├── image request
 ├── font request
 └── API request

88. Why Websites Can Be Slow

A page may require:

1 HTML request
+
10 CSS/JS requests
+
50 images
+
5 fonts
+
API calls

Now the server handles many operations.

This is why:

caching
compression
CDN
image optimization
HTTP/2

matter.

89. Inspect Your Website

Run:

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

Then:

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

You are now capable of understanding much more of the output.

90. Check the Status

For example:

HTTP/2 200

means the HTTP exchange succeeded.

If you see:

HTTP/2 301

you know a redirect occurred.

If:

HTTP/2 502

look toward the Nginx → PHP-FPM/upstream layer.

91. Check Headers

Look for:

server:
content-type:
cache-control:
location:
set-cookie:

These give clues about how your site is operating.

92. Browser Developer Tools

Open your browser’s Developer Tools:

F12

Then:

Network

Reload the website.

You will see requests such as:

/
about/
style.css
script.js
logo.png

93. Network Tab

For each request you can inspect:

Status
Method
Domain
Path
Size
Time
Response headers
Request headers

This is one of the most useful tools for web hosting troubleshooting.

94. Example

Suppose:

/about/
200

but:

/style.css
404

The WordPress page itself works, but the CSS path is wrong.

95. Another Example

Suppose:

/about/
200

but:

/wp-content/uploads/image.jpg
403

Now investigate:

file permissions
directory permissions
Nginx rules
security rules

96. Another Example

Suppose:

/about/
502

Then investigate:

Nginx
 ↓
PHP-FPM

Check:

sudo systemctl status php*-fpm

and inspect relevant logs.

97. Logs

Your hosting platform must eventually teach you:

access logs
error logs
PHP logs
MySQL logs
system logs

For Nginx, common locations include:

/var/log/nginx/

The exact log configuration can differ.

98. Access Log

An access log records requests.

Conceptually:

client IP
timestamp
request
status
bytes
user agent

Example:

GET /about/ HTTP/2
200

This answers:

Did the request actually reach Nginx?

99. Error Log

The error log can show:

permission problems
upstream failures
configuration errors
connection errors

This answers:

What went wrong while processing the request?

100. The Hosting Troubleshooting Map

At this point you can diagnose:

Domain doesn't resolve
 ↓
DNS

Domain resolves but connection times out
 ↓
network/security

Connection refused
 ↓
listener/firewall/service

Nginx returns 404
 ↓
routing/document root/rewrite

Nginx returns 403
 ↓
permissions/access rules

Nginx returns 502
 ↓
PHP-FPM/upstream

WordPress returns 500
 ↓
PHP/plugin/theme/application

Database errors
 ↓
MySQL/WordPress database layer

101. Lesson 058 — Core Principle

The key idea is:

HTTP is the conversation between the browser and your web server.

The complete request path is now:

Domain
 ↓
DNS
 ↓
IP
 ↓
Routing
 ↓
TCP
 ↓
TLS
 ↓
HTTP Request
 ↓
Nginx
 ↓
PHP-FPM
 ↓
WordPress
 ↓
MySQL
 ↓
HTTP Response
 ↓
Browser

You are now moving from server administration into actual web-server engineering.

Next Lesson — 059

Nginx Deep Dive — How One Server Hosts Hundreds of Websites

We will build the next layer:

Nginx
 ↓
Master process
 ↓
Worker processes
 ↓
server blocks
 ↓
server_name
 ↓
listen
 ↓
root
 ↓
location
 ↓
try_files
 ↓
FastCGI
 ↓
PHP-FPM

Then we will connect it directly to your structure:

/storage/websites/
├── domain1.com/
├── domain2.com/
├── domain3.com/
└── ...

and design the architecture needed to turn your current server into a multi-domain hosting platform.

CresignSys Learn — Lesson 058

HTTP Deep Dive — How a Web Request Actually Works

HTTP

1. What Is HTTP?

2. HTTPS

3. The First Request

4. HTTP Request

5. HTTP Methods

6. GET

7. Another GET

8. POST

9. Request Body

10. HTTP Headers

11. Host Header

12. Virtual Hosting

13. Nginx Server Block

14. URL Structure

15. Scheme

16. Host

17. Path

18. Query String

19. Fragment

20. Complete URL

21. HTTP Response

22. Response Structure

23. Status Codes

24. 200

25. 201

26. 204

27. 301

28. 302

29. 304

30. 400

31. 401

32. 403

33. 404

34. 405

35. 408

36. 429

37. 500

38. 502

39. 503

40. 504

41. Status Code Troubleshooting

42. curl

43. Example

44. Follow Redirects

45. See More Details

46. TLS + HTTP

47. HTTP Headers

48. Content-Type

49. Why Content-Type Matters

50. Content-Length

51. Cache-Control

52. Browser Cache

53. Server Cache

54. WordPress Without Cache

55. WordPress With Page Cache

56. Why This Matters for Hosting

57. Cookies

Cookies

58. Why WordPress Uses Cookies

59. Login Example

60. HTTP Is Stateless

61. Example

62. Security Attributes of Cookies

Secure

HttpOnly

SameSite

63. HTTP Compression

64. Why Compression Helps

65. HTTP/1.1

66. HTTP/2

67. HTTP/2 Multiplexing

68. HTTP/3

69. Your Nginx Server

70. HTTP Request to WordPress

71. Step 1

72. Step 2

73. Step 3

42. `curl`