HTTP — The Language of the Web

We have now studied:

Domain
 ↓
DNS
 ↓
IP
 ↓
TCP
 ↓
TLS

Now we reach the protocol that actually carries the web request:

HTTP

1. What Is HTTP?

HTTP means:

Hypertext Transfer Protocol

It is an application-layer protocol used for communication between clients and web servers.

For your website:

Browser
   ↓
HTTPS
   ↓
HTTP
   ↓
Nginx

2. HTTP Is Not HTTPS

These are related but different:

HTTP
=
web application protocol

HTTPS
=
HTTP
+
TLS

So:

HTTPS
 │
 ├── TLS
 │    └── encryption/security
 │
 └── HTTP
      └── web requests/responses

3. What Does HTTP Actually Do?

HTTP defines how a client says:

Give me this resource.

and how the server says:

Here is the result.

For example:

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

The server may respond:

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

followed by the webpage.

4. Client and Server

HTTP normally has two primary participants:

Client
   ↓
Request
   ↓
Server
   ↓
Response
   ↓
Client

For your website:

Chrome
   ↓
Nginx

5. HTTP Request

A request tells the server what the client wants.

Example:

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

This means approximately:

Get / from templates.cresignsys.com.

6. HTTP Response

The server responds.

Example:

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

<html>
...
</html>

7. Request Structure

A simplified HTTP request contains:

Request
│
├── Method
├── Target/path
├── HTTP version
├── Headers
└── Optional body

Example:

GET /about HTTP/1.1
Host: templates.cresignsys.com
User-Agent: Chrome
Accept: text/html

8. Method

The first word:

GET

is the HTTP method.

Common methods:

GET
POST
PUT
PATCH
DELETE
HEAD
OPTIONS

9. GET

GET means approximately:

Retrieve a representation of a resource.

Example:

GET /about HTTP/1.1

The browser is asking for:

/about

10. POST

POST is commonly used to submit data to a server.

For example:

POST /login HTTP/1.1

with a request body containing form data or JSON.

Conceptually:

Browser
 ↓
POST
 ↓
Server
 ↓
Process submitted data

11. PUT

PUT is commonly used when the client wants to create or replace a representation at a specified resource.

For APIs:

PUT /users/123

might mean:

Replace/update the representation of user 123.

12. PATCH

PATCH is generally used for partial modification.

For example:

PATCH /users/123

could change only:

email

without replacing the entire resource.

13. DELETE

DELETE requests removal of a resource.

Example:

DELETE /users/123

The server decides whether the operation is permitted and how it is handled.

14. HEAD

HEAD is similar to GET but asks for the response headers without the response body.

Useful for checking:

Status
Content-Type
Content-Length
Cache headers
Last-Modified

without downloading the complete content.

15. OPTIONS

OPTIONS asks about supported communication options for a resource/server.

It is also important in browser CORS workflows.

16. URL

Consider:

https://templates.cresignsys.com/about?lang=en

Break it down:

https://
   ↓
scheme

templates.cresignsys.com
   ↓
host

/about
   ↓
path

?lang=en
   ↓
query

17. Scheme

The scheme:

https

tells the client what protocol arrangement is being requested.

For ordinary web traffic:

http
https

18. Host

The host is:

templates.cresignsys.com

This is the hostname.

It connects our previous DNS lesson to HTTP.

19. Path

The path:

/about

identifies the requested resource within the server/application namespace.

Other examples:

/
 /about
 /contact
 /wp-admin/
 /wp-login.php

20. Query String

Example:

/products?id=25

The query is:

id=25

Another:

/search?q=wordpress&page=2

Query parameters are often used to pass request-specific information.

21. Fragment

You may see:

https://example.com/page#section2

The:

#section2

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

This is an important distinction.

22. HTTP Headers

Headers carry metadata.

Example:

Host: templates.cresignsys.com
User-Agent: Chrome
Accept: text/html
Accept-Encoding: gzip, br
Cookie: session=...

Think of headers as:

Information about the request or response.

23. Host Header

In HTTP/1.1, the Host header identifies the intended host.

Example:

Host: templates.cresignsys.com

This is extremely important for shared hosting.

24. Why Host Matters

One server can host:

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

The same IP can receive all three.

The HTTP host information helps Nginx select the appropriate virtual server configuration.

Conceptually:

IP:443
  │
  ├── templates.cresignsys.com
  ├── shop.cresignsys.com
  └── learn.cresignsys.com

25. SNI vs Host

These are related but different.

SNI

Used during TLS negotiation:

TLS
 ↓
SNI = templates.cresignsys.com

Host

Used by HTTP:

HTTP
 ↓
Host: templates.cresignsys.com

So:

TLS layer
 ↓
SNI

HTTP layer
 ↓
Host

26. User-Agent

The User-Agent header identifies information about the client software.

For example:

User-Agent: Mozilla/5.0 ...

Servers can use it for compatibility, analytics, or other purposes.

It should not be treated as a strong security identity.

27. Accept

The browser can tell the server what response media types it prefers.

Example:

Accept: text/html

It can contain multiple values and quality preferences.

28. Accept-Encoding

The browser may tell the server which content encodings it supports.

For example:

Accept-Encoding: gzip, br

The server may then compress the response when appropriate.

29. Content-Type

Content-Type tells the receiver what kind of representation is being sent.

Example:

Content-Type: text/html

Other examples:

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

30. Content-Length

This indicates the size of a message body in bytes when used.

Example:

Content-Length: 15432

Modern HTTP can also use other mechanisms for delimiting message content.

31. HTTP Response

A response contains:

Response
│
├── Status
├── Headers
└── Body

Example:

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

<html>
...
</html>

32. Status Code

The status code tells the client what happened.

Examples:

33. 200

200 OK

Generally means the request succeeded.

34. 201

201 Created

Commonly used when a request successfully creates a resource.

Especially common in APIs.

35. 204

204 No Content

The request succeeded but there is no response content to return.

36. 301

301 Moved Permanently

The resource has been permanently redirected to another URL.

For example:

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

37. 302

302 Found

A redirect response.

There are several redirect status codes, each with specific semantics.

38. 304

304 Not Modified

This is related to caching.

It can tell the browser:

You can use your existing cached copy.

This can save bandwidth.

39. 400

400 Bad Request

The server considers the request malformed or invalid.

40. 401

401 Unauthorized

Despite its name, this generally means the request lacks valid authentication credentials for the protected resource.

41. 403

403 Forbidden

The server understood the request but refuses to authorize it.

42. 404

404 Not Found

The requested resource could not be found.

For WordPress:

/wp-admin/

might work while:

/does-not-exist

returns 404.

43. 405

405 Method Not Allowed

The server/resource doesn’t support the HTTP method used for that resource.

Example:

DELETE /article

when the endpoint only allows:

GET

44. 429

429 Too Many Requests

Often used for rate limiting.

For example:

Client
 ↓
1000 requests
 ↓
Server
 ↓
429

45. 500

500 Internal Server Error

This generally means the server encountered an unexpected condition while processing the request.

In WordPress, causes can include:

PHP fatal error
Plugin problem
Theme problem
Configuration error

46. 502

502 Bad Gateway

This often occurs when a gateway/proxy such as Nginx receives an invalid response from an upstream service.

For your architecture:

Browser
 ↓
Nginx
 ↓
PHP-FPM

If Nginx cannot properly communicate with PHP-FPM, a 502 can result.

47. 503

503 Service Unavailable

Often means the service is temporarily unable to handle the request.

Possible causes include:

Service stopped
Overload
Maintenance
Upstream unavailable

48. 504

504 Gateway Timeout

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

For example:

Nginx
 ↓
PHP-FPM
 ↓
application hangs

Nginx may eventually return:

49. Status Code Families

Remember:

1xx
Informational

2xx
Success

3xx
Redirection

4xx
Client/request-related errors

5xx
Server-side failures

50. HTTP Body

The body contains the actual content.

For a webpage:

<html>
  <body>
    Hello
  </body>
</html>

For an API:

{
  "name": "Abey",
  "status": "active"
}

51. HTTP Is Not Only HTML

HTTP can transport:

HTML
CSS
JavaScript
JSON
Images
Fonts
PDF
Video
API data

HTTP is a general application protocol.

52. One Web Page Is Many HTTP Requests

When you open:

https://templates.cresignsys.com

the browser may request:

/
style.css
app.js
logo.png
font.woff2
api/data

So one page can produce many HTTP requests.

53. Example

Conceptually:

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

Each resource can have its own HTTP response.

54. Browser Rendering

The browser receives:

HTML

then discovers resources:

CSS
JavaScript
Images
Fonts

and requests them.

Eventually it builds the visual page.

55. Static vs Dynamic

A file such as:

style.css

can often be served directly by Nginx.

But a WordPress page may require:

Nginx
 ↓
PHP-FPM
 ↓
WordPress
 ↓
MySQL

56. Static Request

Example:

GET /style.css

Nginx can potentially do:

Nginx
 ↓
Filesystem
 ↓
style.css
 ↓
HTTP response

No PHP is required.

57. Dynamic WordPress Request

Example:

GET /about/

could involve:

Nginx
 ↓
PHP-FPM
 ↓
WordPress
 ↓
Plugins/themes
 ↓
MySQL
 ↓
HTML generation
 ↓
PHP-FPM
 ↓
Nginx
 ↓
Browser

58. This Explains Web Server Performance

Static content can often be served very quickly.

Dynamic content can require:

PHP
Database
Plugins
Theme processing
External API calls

Each adds work.

59. Cookies

HTTP is fundamentally stateless.

A server does not automatically remember previous requests.

Cookies provide one common mechanism for maintaining state.

Example:

Cookie: session=abc123

60. Set-Cookie

The server can send:

Set-Cookie: session=abc123; Secure; HttpOnly

The browser stores the cookie and can send it on subsequent matching requests.

61. Cookie Flow

First request
     ↓
Server
     ↓
Set-Cookie
     ↓
Browser stores cookie
     ↓
Next request
     ↓
Cookie: session=...

62. Why WordPress Uses Cookies

WordPress uses cookies for things such as:

Login sessions
Authentication state
User preferences

So:

Browser
 ↓
WordPress cookie
 ↓
WordPress
 ↓
recognizes session

63. Secure Cookie

A cookie can have:

Secure

meaning it should only be sent over secure connections.

This is important for authentication cookies.

64. HttpOnly

A cookie can also use:

HttpOnly

which prevents ordinary JavaScript from reading the cookie through the browser’s document.cookie interface.

This can reduce exposure to certain client-side attacks, although it doesn’t make an application automatically secure.

65. SameSite

Another important cookie attribute:

SameSite

It controls when cookies are sent in cross-site contexts.

Values commonly include:

Strict
Lax
None

This is important for modern web security and CSRF defenses.

66. Sessions

A session is an application concept.

For example:

Browser
 ↓
session cookie
 ↓
Server
 ↓
session data

The cookie may contain an identifier rather than the entire session state.

67. HTTP Authentication

HTTP also has authentication mechanisms.

For example:

Authorization: Bearer <token>

or:

Authorization: Basic ...

Modern applications frequently use token-based mechanisms for APIs.

68. HTTP Is Stateless

Suppose:

Request 1

and:

Request 2

The protocol itself doesn’t automatically imply:

These are the same human.

Applications use:

Cookies
Sessions
Tokens
Authentication

to create stateful experiences.

69. HTTP Caching

HTTP has powerful caching mechanisms.

The browser may store:

HTML
CSS
JS
Images
API responses

depending on cache directives.

70. Cache-Control

A server can send:

Cache-Control: max-age=3600

This gives caching instructions.

Other directives include:

no-cache
no-store
private
public
must-revalidate

Each has specific semantics.

71. Why Caching Matters

Without caching:

Browser
 ↓
Server
 ↓
download logo

every time.

With caching:

Browser
 ↓
local cached logo

when permitted.

This reduces:

Bandwidth
Latency
Server load

72. ETag

A server can provide an:

ETag

Example:

ETag: "abc123"

The browser can later send:

If-None-Match: "abc123"

The server can respond:

304 Not Modified

if the resource hasn’t changed.

73. Last-Modified

Another caching mechanism is:

Last-Modified: ...

The client may later send:

If-Modified-Since: ...

The server can return:

304 Not Modified

when appropriate.

74. Compression

HTTP responses can be compressed.

The browser might send:

Accept-Encoding: gzip, br

The server may respond with:

Content-Encoding: br

or:

Content-Encoding: gzip

75. Compression Flow

HTML
 ↓
Compression
 ↓
compressed bytes
 ↓
TLS
 ↓
Internet
 ↓
Browser
 ↓
decompression
 ↓
HTML

This reduces transfer size.

76. HTTP/1.1

The traditional HTTP version you’ll encounter frequently is:

HTTP/1.1

Example:

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

It is text-oriented and widely supported.

77. HTTP/2

HTTP/2 introduced major performance improvements.

Conceptually:

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

It uses binary framing and supports multiplexing.

78. HTTP/2 Multiplexing

Instead of requiring a separate HTTP connection for each resource, multiple streams can share a connection.

TCP connection
│
├── Stream 1
├── Stream 3
├── Stream 5
└── Stream 7

This reduces connection overhead.

79. HTTP/3

HTTP/3 changes the transport architecture:

HTTP/1.1
 ↓
TCP

HTTP/2
 ↓
TCP

HTTP/3
 ↓
QUIC
 ↓
UDP

We will study QUIC deeply later.

80. HTTP Version Stack

Memorize:

HTTP/1.1
 ↓
TCP
 ↓
TLS for HTTPS

HTTP/2
 ↓
TCP
 ↓
TLS

HTTP/3
 ↓
QUIC
 ↓
UDP

81. Nginx’s Role

Your Nginx server is sitting between the network and your application.

Conceptually:

Internet
   ↓
TCP/TLS
   ↓
Nginx
   ↓
HTTP processing
   ↓
┌───────────────┐
│               │
▼               ▼
Static       PHP-FPM
files            │
                 ▼
              WordPress
                 │
                 ▼
               MySQL

82. Nginx Receives the Request

Suppose:

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

Nginx receives it.

It needs to decide:

Which server?
Which location?
Static or dynamic?
Where should the request go?

83. `server_name`

Your Nginx configuration may contain:

server_name templates.cresignsys.com;

This tells Nginx that this server block handles that hostname.

84. `location`

Nginx then evaluates URL paths against location rules.

Example:

location / {
    ...
}

This can define how requests should be processed.

85. Static File

For a static file:

GET /logo.png

Nginx might map:

/logo.png

to:

/storage/websites/templates.cresignsys.com/public/logo.png

Then return the file.

86. PHP Request

For a PHP-backed request, Nginx may pass the request to:

PHP-FPM

using FastCGI.

Conceptually:

Browser
 ↓
HTTP
 ↓
Nginx
 ↓
FastCGI
 ↓
PHP-FPM
 ↓
PHP

87. PHP-FPM

PHP-FPM means:

PHP FastCGI Process Manager

It manages PHP worker processes.

For WordPress:

Nginx
 ↓
PHP-FPM
 ↓
WordPress PHP

88. WordPress

WordPress then processes the request.

Conceptually:

WordPress
│
├── Core
├── Theme
├── Plugins
└── Database queries

It can generate HTML dynamically.

89. MySQL

WordPress often needs database data:

WordPress
 ↓
MySQL
 ↓
posts
users
settings
metadata
options

The result comes back:

MySQL
 ↓
WordPress
 ↓
PHP-FPM
 ↓
Nginx

90. Final HTTP Response

Nginx sends the result back:

WordPress
 ↓
HTML
 ↓
Nginx
 ↓
TLS
 ↓
TCP
 ↓
Internet
 ↓
Browser

91. Complete Request

This is one of the most important diagrams in your hosting education:

                    USER
                     │
                     ▼
                  BROWSER
                     │
                     ▼
                    DNS
                     │
                     ▼
                  IP ADDRESS
                     │
                     ▼
                    TCP
                     │
                     ▼
                    TLS
                     │
                     ▼
                   HTTP
                     │
                     ▼
                  NGINX
                     │
              ┌──────┴──────┐
              │             │
              ▼             ▼
          Static File    PHP-FPM
                            │
                            ▼
                         WordPress
                            │
                            ▼
                           MySQL
                            │
                            ▼
                         Response
                            │
                            ▼
                          NGINX
                            │
                            ▼
                           TLS
                            │
                            ▼
                           TCP
                            │
                            ▼
                         BROWSER

92. Practical Command

You can inspect HTTP headers with:

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

This asks for response headers.

You might see:

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

The exact output depends on your configuration.

93. Detailed Request

Use:

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

This is extremely useful because it exposes much of the connection process.

Conceptually:

DNS
 ↓
TCP
 ↓
TLS
 ↓
HTTP

94. Inspect Only HTTP Headers

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

Look for:

HTTP status
Content-Type
Cache-Control
Server
Location
Set-Cookie
Content-Encoding

95. Inspect Redirects

Use:

curl -I -L http://templates.cresignsys.com

-L follows redirects.

You may see:

HTTP/1.1 301
Location: https://templates.cresignsys.com/

followed by:

HTTP/2 200

96. Test a Specific Path

curl -I https://templates.cresignsys.com/wp-login.php

This lets you see how a particular endpoint responds.

97. HTTP Error Investigation

If you see:

don’t immediately blame TLS.

The chain is:

DNS ✓
TCP ✓
TLS ✓
HTTP ✓
Nginx ✓
PHP-FPM ✗

possibly.

If you see:

the problem may be:

Nginx routing
WordPress routing
Missing file
Application route

98. The Layered Diagnostic Method

Always ask:

1. Does DNS resolve?
2. Can I reach the IP?
3. Is TCP 443 reachable?
4. Does TLS succeed?
5. What HTTP status is returned?
6. What does Nginx log?
7. What does PHP-FPM log?
8. What does WordPress report?
9. What does MySQL report?

This method will save enormous time when managing your hosting server.

99. The Core HTTP Vocabulary

Memorize:

HTTP
=
web application protocol

Request
=
client → server

Response
=
server → client

Method
=
operation requested

Header
=
metadata

Body
=
actual message content

Status code
=
result of request

Cookie
=
client-side state mechanism

Cache
=
stored response/resource

Host
=
requested HTTP hostname

100. The Whole Web Hosting Picture

You have now built a much deeper understanding:

                     WEB HOSTING
                          │
       ┌──────────────────┼──────────────────┐
       ▼                  ▼                  ▼
      DNS                TCP                TLS
       │                  │                  │
   Name → IP         Reliable stream     Secure channel
                          │                  │
                          └────────┬─────────┘
                                   ▼
                                  HTTP
                                   │
                                   ▼
                                  NGINX
                                   │
                    ┌──────────────┴──────────────┐
                    ▼                             ▼
               Static files                   PHP-FPM
                                                  │
                                                  ▼
                                              WordPress
                                                  │
                                                  ▼
                                                MySQL

Lesson 041 Summary

The most important concept is:

HTTP = the language used by web applications.

A simple request:

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

becomes:

Browser
 ↓
HTTP
 ↓
TLS encryption
 ↓
TCP
 ↓
IP
 ↓
Internet
 ↓
Nginx

Then Nginx decides:

Static file?
     ↓
    YES → filesystem

Dynamic?
     ↓
    YES → PHP-FPM → WordPress → MySQL

The response travels back through the same lower layers.

Next Lesson — 042

Nginx — From HTTP Request to `server {}`

We will now enter the actual web-server configuration on your Ubuntu VPS.

We will understand:

server {
    listen 443 ssl;
    server_name templates.cresignsys.com;

    root /storage/websites/templates.cresignsys.com/public;

    ssl_certificate ...;
    ssl_certificate_key ...;

    location / {
        ...
    }

    location ~ \.php$ {
        ...
    }
}

and trace exactly how Nginx processes:

https://templates.cresignsys.com/
https://templates.cresignsys.com/wp-admin/
https://templates.cresignsys.com/wp-login.php
https://templates.cresignsys.com/style.css

from TCP connection → TLS → server block → location → filesystem/PHP-FPM → response.

CresignSys Learn — Lesson 041

HTTP — The Language of the Web

HTTP

1. What Is HTTP?

Hypertext Transfer Protocol

2. HTTP Is Not HTTPS

3. What Does HTTP Actually Do?

4. Client and Server

5. HTTP Request

6. HTTP Response

7. Request Structure

8. Method

9. GET

10. POST

11. PUT

12. PATCH

13. DELETE

14. HEAD

15. OPTIONS

16. URL

17. Scheme

18. Host

19. Path

20. Query String

21. Fragment

22. HTTP Headers

23. Host Header

24. Why Host Matters

25. SNI vs Host

SNI

Host

26. User-Agent

27. Accept

28. Accept-Encoding

29. Content-Type

30. Content-Length

31. HTTP Response

32. Status Code

33. 200

34. 201

35. 204

36. 301

37. 302

38. 304

39. 400

40. 401

41. 403

42. 404

43. 405

44. 429

45. 500

46. 502

47. 503

48. 504

49. Status Code Families

50. HTTP Body

51. HTTP Is Not Only HTML

52. One Web Page Is Many HTTP Requests

53. Example

54. Browser Rendering

55. Static vs Dynamic

56. Static Request

57. Dynamic WordPress Request

58. This Explains Web Server Performance

59. Cookies

60. Set-Cookie

61. Cookie Flow

62. Why WordPress Uses Cookies

63. Secure Cookie

64. HttpOnly

65. SameSite

66. Sessions

67. HTTP Authentication

68. HTTP Is Stateless

69. HTTP Caching

70. Cache-Control

71. Why Caching Matters

72. ETag

ETag

73. Last-Modified

83. `server_name`

84. `location`

Nginx — From HTTP Request to `server {}`