Scribd
Upload
14 views12 pages

HTTP 1 Vs 1.1 Vs 2.0 Vs 3.o

The document states that the training data is current only until October 2023. It implies that any developments or information arising after this date are not included. This limitation is important for understanding the context and relevance of the information provided.

Uploaded by

Suresh Shenoy
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
14 views12 pages

HTTP 1 Vs 1.1 Vs 2.0 Vs 3.o

The document states that the training data is current only until October 2023. It implies that any developments or information arising after this date are not included. This limitation is important for understanding the context and relevance of the information provided.

Uploaded by

Suresh Shenoy
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 12

✅HTTP/1.

0 (1996)
✅ Key Features:

 Simple request/response model


 Each request opens a new TCP connection
 No persistent connections by default
 No support for modern features like caching, compression, pipelining

📦 Example:

Client requests an image from a website:

GET /image.jpg HTTP/1.0


Host: www.example.com
❌ Limitation:

If a page has 10 images, the browser makes 10 separate TCP connections,


causing high latency.

✅🔹 HTTP/1.1 (1997 - widely used today)


✅ Key Features:

 Persistent Connections (keep-alive)


 Chunked Transfer Encoding
 Request Pipelining (limited support)
 More headers and caching controls

📦 Example:

Client loads a full HTML page and images over a single TCP connection:

GET /index.html HTTP/1.1


Host: www.example.com
Connection: keep-alive

Then:

GET /image1.jpg HTTP/1.1


Host: www.example.com

GET /image2.jpg HTTP/1.1


Host: www.example.com
✅ Benefit:

Reduces connection overhead, better than HTTP/1.0.


❌ Limitation:

Requests are still processed sequentially (head-of-line blocking).

✅🔹 HTTP/2 (2015)
✅ Key Features:

 Multiplexing: Multiple requests/responses in parallel over a single


connection
 Binary Protocol (faster parsing, less overhead)
 Header Compression (HPACK)
 Server Push (send resources before client asks)

📦 Example:

Browser requests HTML, CSS, JS, and images:

 All are sent simultaneously over a single TCP connection.


 Responses can arrive out of order.

No change for developers in HTTP request syntax:

GET /page.html HTTP/2


Host: www.example.com
✅ Benefit:

 Faster page loads


 Ideal for content-heavy pages

❌ Limitation:

Still uses TCP, which suffers from head-of-line blocking at the transport level.

✅🔹 HTTP/3 (2022)
✅ Key Features:

 Based on QUIC protocol (UDP-based, developed by Google)


 0-RTT connection setup (faster handshakes)
 No head-of-line blocking
 Built-in encryption (like HTTPS by default)

📦 Example:

Browser connects to a site using HTTP/3:


:method: GET
:scheme: https
:authority: www.example.com
:path: /home

All data is encrypted and sent over UDP (QUIC).

✅ Benefit:

 Faster connection setup


 Better for mobile networks and high-latency environments

⚠️Note:

Requires server support and browser compatibility (most modern browsers


support it).

🔁 Summary Comparison

HTTP/
Feature HTTP/1.1 HTTP/2 HTTP/3
1.0

✅ (Multiplexed over
Connection reuse ❌ ✅ (Keep-Alive) ✅ (Multiplexed)
QUIC)

Transport protocol TCP TCP TCP UDP (via QUIC)

Request
❌ Limited ✅ ✅
pipelining

Head-of-line ❌ (at app


❌ ❌ ✅ (solved via QUIC)
blocking level)

Server Push ❌ ❌ ✅ ✅

Optional Optional
Encryption ❌ Mandatory
(HTTPS) (HTTPS)

✅ HTTP/1.0 Request Example

http

GET /index.html HTTP/1.0


Host: www.example.com
User-Agent: Mozilla/4.0
Accept: text/html, text/plain, */*

✅ HTTP/1.0 Response Example


HTTP/1.0 200 OK
Date: Sun, 18 May 2025 10:00:00 GMT
Server: Apache/1.3.29 (Unix)
Content-Type: text/html
Content-Length: 1234
Connection: close

<!DOCTYPE html>
<html>
<head>
<title>Welcome</title>
</head>
<body>
<h1>Hello, world!</h1>
<p>This is a basic HTML page served over HTTP/1.0.</p>
</body>
</html>

Explanation of Response Segments:

 HTTP/1.0 200 OK: Status line – version, status code, reason phrase
 Date: Date and time the response was sent
 Server: Information about the server
 Content-Type: MIME type of the response body
 Content-Length: Size in bytes of the body
 Connection: close: Signals the connection will be closed after the response
(default behavior in HTTP/1.0)

🔁 Behavior in HTTP/1.0:

 The connection is closed after each request/response.


 To request multiple resources (e.g., images, scripts), new connections
are made each time.
 No support for chunked transfer encoding or pipelining.

✅ HTTP/1.0 POST Request Example

POST /submit-form HTTP/1.0


Host: www.example.com
User-Agent: Mozilla/4.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 32
Connection: close

username=alice&password=secret
🔍 Explanation of Request Segments:
Segment Description

POST /submit-form HTTP/1.0 Request line: method, path, HTTP version

Host Not part of HTTP/1.0 spec, but widely supported in practice


Segment Description

User-Agent Identifies the client software

Content-Type Format of the body (here it's form data)

Content-Length Required to tell the server how much body to read

Connection: close Explicitly closes the connection after the response

Blank line Required before the body starts

Body Contains the form data (URL-encoded)

✅ HTTP/1.0 Response Example

HTTP/1.0 200 OK
Date: Sun, 18 May 2025 12:00:00 GMT
Server: Apache/1.3.41 (Unix)
Content-Type: text/html
Content-Length: 122
Connection: close

<html>
<head><title>Success</title></head>
<body>
<h1>Form submitted successfully</h1>
</body>
</html>
🔍 Response Segments:
Segment Description

HTTP/1.0 200 OK Status line: protocol version, status code, message

Date Timestamp of the response

Server Server version and software

Content-Type MIME type of the response body

Content-Length Length of response body in bytes

Connection Server confirms the connection will be closed

🧠 Notes About HTTP/1.0 POST:


 Content-Length is mandatory for POST requests.
 Host is not part of the original HTTP/1.0 spec, but most servers require it for virtual hosting.
 No chunked encoding, pipelining, or persistent connections unless explicitly added via
keep-alive.

✅ 1. PUT Request and Response


🟦 Request (HTTP/1.0 PUT)
PUT /data/item123.json HTTP/1.0
Host: www.example.com
User-Agent: CustomClient/1.0
Content-Type: application/json
Content-Length: 51
Connection: close

{
"id": 123,
"name": "Updated Item",
"price": 45.99
}
🟩 Response (Server Response)
HTTP/1.0 200 OK
Date: Sun, 18 May 2025 13:00:00 GMT
Server: Apache/1.3.42
Content-Type: application/json
Content-Length: 36
Connection: close

{"message": "Item updated successfully"}

✅ 2. DELETE Request and Response


🟦 Request (HTTP/1.0 DELETE)
DELETE /data/item123.json HTTP/1.0
Host: www.example.com
User-Agent: CustomClient/1.0
Connection: close
🟩 Response
http

HTTP/1.0 200 OK
Date: Sun, 18 May 2025 13:05:00 GMT
Server: Apache/1.3.42
Content-Type: application/json
Content-Length: 36
Connection: close

{"message": "Item deleted successfully"}

✅ 3. OPTIONS Request and Response


🟦 Request (HTTP/1.0 OPTIONS)
OPTIONS /data/item123.json HTTP/1.0
Host: www.example.com
User-Agent: CustomClient/1.0
Connection: close
🟩 Response
HTTP/1.0 200 OK
Date: Sun, 18 May 2025 13:10:00 GMT
Server: Apache/1.3.42
Allow: GET, POST, PUT, DELETE, OPTIONS
Content-Length: 0
Connection: close

🔍 Summary Table
Method Purpose

PUT Uploads a resource (create or replace)

DELETE Deletes the specified resource

OPTIONS Queries supported methods or CORS info

✅ HTTP/1.1 Request Example

GET /products/item123.html HTTP/1.1


Host: www.example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)
Accept:
text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Connection: keep-alive
Upgrade-Insecure-Requests: 1
Referer: https://www.example.com/products/
🔍 Explanation of Request Segments:
Segment Description

GET /products/item123.html HTTP/1.1 Request line: method, path, HTTP version

Host: www.example.com Required in HTTP/1.1, identifies the virtual host

User-Agent Identifies the client software (browser)

Accept Content types the client can process

Accept-Language Preferred languages for the response

Accept-Encoding Supported encodings (e.g. gzip, br)

Connection: keep-alive Reuse TCP connection (default in HTTP/1.1)

Upgrade-Insecure-Requests Tells the server the client prefers HTTPS

Referer Page from which this request originated


🔹 No body for a GET request, but if it were a POST, a body would follow after an empty line.

✅ HTTP/1.1 Response Example

HTTP/1.1 200 OK
Date: Sun, 18 May 2025 11:00:00 GMT
Server: Apache/2.4.58 (Ubuntu)
Content-Type: text/html; charset=UTF-8
Content-Encoding: gzip
Content-Length: 512
Cache-Control: max-age=3600
ETag: "abc123etag"
Last-Modified: Sat, 17 May 2025 14:00:00 GMT
Connection: keep-alive
Vary: Accept-Encoding

<!DOCTYPE html>
<html>
<head>
<title>Product Details</title>
</head>
<body>
<h1>Item #123</h1>
<p>This is a sample product page.</p>
</body>
</html>
🔍 Explanation of Response Segments:
Segment Description

HTTP/1.1 200 OK Status line: protocol version, status code, reason phrase

Date Server date and time

Server Web server information

Content-Type MIME type and charset

Content-Encoding Encoding used (gzip compression here)

Content-Length Size of the body in bytes

Cache-Control Caching instructions

ETag Unique version identifier for the resource

Last-Modified Last time the resource was changed

Connection Keep the connection alive (or close)

Vary Instructs caches to vary responses based on Accept-Encoding

🔁 Behavior in HTTP/1.1
 Persistent connections by default via keep-alive
 Chunked transfer encoding supported when size is unknown
 Much better header support than HTTP/1.0
 Host header is mandatory

⚙️HTTP/1.1 (Text-Based)
🔷 GET Request
GET /api/products/123 HTTP/1.1
Host: www.example.com
User-Agent: CustomClient/1.1
Accept: application/json
Connection: keep-alive
✅ Response
HTTP/1.1 200 OK
Date: Sun, 18 May 2025 13:30:00 GMT
Content-Type: application/json
Content-Length: 51
Connection: keep-alive

{
"id": 123,
"name": "Sample Item",
"price": 25.50
}

🔷 POST Request
POST /api/products HTTP/1.1
Host: www.example.com
User-Agent: CustomClient/1.1
Content-Type: application/json
Content-Length: 52
Connection: keep-alive

{
"name": "New Product",
"price": 39.99
}
✅ Response
HTTP/1.1 201 Created
Date: Sun, 18 May 2025 13:31:00 GMT
Location: /api/products/124
Content-Type: application/json
Content-Length: 38
Connection: keep-alive

{"message": "Product created", "id": 124}

🔷 PUT Request
PUT /api/products/123 HTTP/1.1
Host: www.example.com
User-Agent: CustomClient/1.1
Content-Type: application/json
Content-Length: 51
Connection: keep-alive
{
"id": 123,
"name": "Updated Item",
"price": 45.99
}
✅ Response
HTTP/1.1 200 OK
Date: Sun, 18 May 2025 13:32:00 GMT
Content-Type: application/json
Content-Length: 36
Connection: keep-alive

{"message": "Item updated successfully"}

🔷 DELETE Request
DELETE /api/products/123 HTTP/1.1
Host: www.example.com
User-Agent: CustomClient/1.1
Connection: keep-alive
✅ Response
HTTP/1.1 200 OK
Date: Sun, 18 May 2025 13:33:00 GMT
Content-Type: application/json
Content-Length: 36
Connection: keep-alive

{"message": "Item deleted successfully"}

🔷 OPTIONS Request
OPTIONS /api/products HTTP/1.1
Host: www.example.com
User-Agent: CustomClient/1.1
Connection: keep-alive
✅ Response
HTTP/1.1 204 No Content
Allow: GET, POST, PUT, DELETE, OPTIONS
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS
Connection: keep-alive
Content-Length: 0

🚀 HTTP/2.0 (Binary Protocol, Conceptual Format)


Note: HTTP/2 uses binary frames; the following shows conceptual pseudo-header format used
internally.

🔷 GET (HTTP/2)

:method: GET
:scheme: https
:authority: www.example.com
:path: /api/products/123
accept: application/json

✅ Response:

:status: 200
content-type: application/json
content-length: 51

{"id":123,"name":"Sample Item","price":25.50}

🔷 POST (HTTP/2)
:method: POST
:scheme: https
:authority: www.example.com
:path: /api/products
content-type: application/json
content-length: 52

{"name": "New Product", "price": 39.99}

✅ Response:

:status: 201
location: /api/products/124
content-type: application/json

{"message": "Product created", "id": 124}

✅ PUT / DELETE / OPTIONS follow same structure with :method: PUT, :method: DELETE, etc.

🌐 HTTP/3 (QUIC)
HTTP/3 is almost identical to HTTP/2 in terms of request structure, but it runs over UDP using QUIC
instead of TCP.

🔷 GET (HTTP/3)

:method: GET
:scheme: https
:authority: www.example.com
:path: /api/products/123
accept: application/json

✅ Response:

:status: 200
content-type: application/json

{"id":123,"name":"Sample Item","price":25.50}
 All methods (GET, POST, PUT, DELETE, OPTIONS) use the same pseudo-header format.
 Headers are compressed using QPACK.
 QUIC enables zero-round-trip (0-RTT), fast TLS 1.3, and better connection migration.

🔁 Summary Table
Feature HTTP/1.1 HTTP/2 HTTP/3

Transport TCP TCP UDP + QUIC

Format Text-based Binary + pseudo-headers Binary + pseudo-headers

Multiplexing ❌ No ✅ Yes ✅ Yes

Header Compression ❌ No ✅ HPACK ✅ QPACK

TLS Requirement Optional Optional Mandatory (TLS 1.3)

Head-of-Line Block ❌ Yes ✅ Reduced ✅ Eliminated

Connection Resume ❌ No ❌ No ✅ Yes (mobility support)

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy