Giao thức Truyền tải Siêu văn bản

HTTP (tiếng Anh: HyperText Transfer Protocol - Giao thức truyền tải siêu văn bản) là một giao thức lớp ứng dụng thuộc hệ thống giao thức cho thông tin siêu phương tiện phân tán và hợp tác. Đây là nền tảng cơ bản để trao đổi và liên lạc dữ liệu trên World Wide Web, nơi các tài liệu siêu văn bản có thể chứa liên kết dẫn đến tài nguyên số khác mà người dùng có thể truy cập dễ dàng bằng cách nhấp chuột hoặc chạm vào màn hình cảm ứng khi duyệt web. HTTP cho phép người dùng truy cập và tải về các tài nguyên như văn bản HTML, văn bản, video, hình ảnh của các trang web và hiển thị chúng trên trình duyệt.

Tim Berners-Lee là người đã khởi xướng việc phát triển HTTP vào năm 1989 tại CERN. Ý tưởng về HTTP được trình bày trong một tài liệu cơ bản, mô tả hoạt động tương tác giữa máy khách và máy chủ trong phiên bản thử nghiệm đầu tiên của HTTP, phiên bản 0.9. Sau đó, phiên bản này được phát triển thành phiên bản chính thức 1.0.

Quá trình phát triển các RFC HTTP ban đầu được thực hiện nhờ sự hợp tác của Lực lượng Đặc nhiệm Kỹ thuật Internet (IETF) và World Wide Web Consortium (W3C). Sau đó, trách nhiệm phát triển được chuyển hoàn toàn cho IETF.

HTTP/1 đã được hoàn thiện và xuất bản tài liệu chính thức (phiên bản 1.0) vào năm 1996. Sau đó, HTTP tiếp tục được cải tiến và phát triển, với phiên bản 1.1 ra mắt vào năm 1997, và các đặc tính kỹ thuật được nâng cấp vào các năm 1999, 2014 và 2022.

Phiên bản bảo mật của HTTP, HTTPS, hiện được áp dụng rộng rãi trên hơn 80% các trang web. HTTP/2, với hiệu suất cải tiến so với HTTP 'trên dây', đã được đưa vào sử dụng từ năm 2015. Tính đến tháng 4 năm 2023, HTTP/2 đã được triển khai trên 39% các trang web và được hầu hết các trình duyệt web hỗ trợ (chiếm 97% người dùng). Phiên bản này được hỗ trợ bởi các máy chủ web lớn thông qua Bảo mật tầng truyền tải (TLS) và sử dụng tiện ích mở rộng Application-Layer Protocol Negotiation (ALPN), yêu cầu sử dụng TLS 1.2 hoặc phiên bản mới hơn.

HTTP/3, kế thừa của HTTP/2, đã được triển khai vào năm 2022. Phiên bản này đã được sử dụng trên 26% các trang web và được nhiều trình duyệt hỗ trợ. HTTP/3 sử dụng QUIC thay vì TCP cho giao thức truyền tải cơ bản. Giống như HTTP/2, nó không làm lỗi thời các phiên bản trước đó. Hỗ trợ cho HTTP/3 đã được thêm vào Cloudflare và Google Chrome từ tháng 9 năm 2019, và có thể kích hoạt trong các phiên bản ổn định của Chrome và Firefox. HTTP/3 cung cấp độ trễ thấp hơn và tốc độ tải trang nhanh hơn so với HTTP/2, trong một số trường hợp có thể nhanh gấp ba lần so với HTTP/1.1.

Khái quát kỹ thuật

HTTP hoạt động theo mô hình giao thức yêu cầu-phản hồi trong kiến trúc khách - chủ. Khách có thể là trình duyệt web do người dùng yêu cầu, trong khi chủ có thể là máy chủ web trên đám mây hoặc máy chủ lưu trữ cục bộ điều khiển nhiều trang web. Khách gửi yêu cầu HTTP đến máy chủ, và máy chủ (cung cấp tài nguyên như tập tin HTML hoặc thực hiện các chức năng khác) sẽ phản hồi thông điệp cho khách. Thông điệp phản hồi chứa thông tin về kết quả yêu cầu và đôi khi bao gồm dữ liệu yêu cầu.

Trình duyệt web là ví dụ phổ biến của user agent (UA). Các user agent khác có thể bao gồm các công cụ tự động lập chỉ mục của bộ máy tìm kiếm (web crawler), hệ thống duyệt tìm bằng giọng nói, ứng dụng di động hoặc phần mềm khác có khả năng truy cập, tải xuống và hiển thị nội dung web.

HTTP được thiết kế để tối ưu hóa các thành phần mạng trung gian và cải thiện giao tiếp giữa máy khách và máy chủ. Các trang web có lưu lượng cao thường sử dụng máy chủ bộ đệm web (web caching) để cung cấp nội dung thay cho máy chủ gốc, giúp giảm thời gian phản hồi. Trình duyệt web lưu trữ các tài nguyên web đã truy cập trước đó vào bộ nhớ đệm và tái sử dụng chúng để giảm tải mạng. Máy chủ proxy HTTP trong mạng riêng có thể giúp kết nối khách mà không cần địa chỉ có thể định tuyến toàn cầu bằng cách chuyển tiếp thông điệp tới máy chủ bên ngoài.

Để các nút HTTP trung gian như proxy và web cache có thể hoạt động hiệu quả, một số tiêu đề HTTP (trong yêu cầu/phản hồi HTTP) được quản lý theo từng bước (hop-by-hop), trong khi những tiêu đề khác được quản lý từ đầu đến cuối (tức là chỉ liên quan đến một khách đầu nguồn và một máy chủ đích).

HTTP là giao thức lớp ứng dụng hoạt động trong khuôn khổ bộ giao thức Internet, và cũng được coi là giao thức lớp vận chuyển cơ bản và đáng tin cậy. Trong phiên bản HTTP/3 mới nhất, Transmission Control Protocol (TCP) không còn được sử dụng, mặc dù các phiên bản cũ vẫn còn phổ biến. HTTP được thiết kế để hoạt động với các giao thức không đáng tin cậy như User Datagram Protocol (UDP), và HTTP/3 được xây dựng dựa trên công nghệ này, chẳng hạn như HTTPU và Simple Service Discovery Protocol (SSDP).

Vị trí và tài nguyên trong HTTP được xác định thông qua đường dẫn URL (Uniform Resource Locator), sử dụng các giao thức URI http và https. Theo RFC 3986, các URL được mã hóa thành siêu liên kết trong tài liệu HTML, tạo thành các tài liệu siêu văn bản liên kết với nhau.

Trong phiên bản HTTP/1.0, mỗi yêu cầu tài nguyên đều yêu cầu một kết nối TCP riêng đến cùng một máy chủ.

Phiên bản HTTP/1.1 cải tiến việc sử dụng kết nối TCP, cho phép một kết nối được dùng nhiều lần để gửi nhiều yêu cầu tài nguyên khác nhau (như trang HTML, khung, hình ảnh, mã nguồn,...). Điều này giúp giảm độ trễ, vì việc thiết lập các kết nối TCP tiêu tốn nhiều tài nguyên, đặc biệt khi lưu lượng truy cập cao.

HTTP/2 là phiên bản nâng cấp của HTTP/1.1, giữ nguyên mô hình khách-chủ và phương thức giao thức nhưng với những điểm khác biệt như sau:

• Ứng dụng mã hóa siêu dữ liệu nhị phân (tiêu đề HTTP) để tiết kiệm không gian hơn so với định dạng văn bản;
• Chỉ sử dụng một kết nối TCP/IP duy nhất (thường là kết nối mã hóa) cho mỗi tên miền máy chủ, thay vì từ 2 đến 8 kết nối TCP/IP;
• Sử dụng một hoặc nhiều luồng hai chiều cho mỗi kết nối TCP/IP, giúp chia nhỏ và truyền các yêu cầu/phản hồi HTTP thành các gói nhỏ, gần như giải quyết được vấn đề HOLB (head-of-line blocking);
• Thêm khả năng 'đẩy', cho phép máy chủ gửi dữ liệu đến máy khách khi có dữ liệu mới mà không cần khách hàng phải yêu cầu dữ liệu mới định kỳ (không cần phương pháp polling).

Vì vậy, việc truyền tải qua HTTP/2 giảm thiểu độ trễ đáng kể và thường có tốc độ nhanh hơn so với HTTP/1.1.

HTTP/3 là sự nâng cấp của HTTP/2, sử dụng giao thức truyền tải QUIC + UDP thay cho TCP. Trong khi TCP/IP trước đây đã được sử dụng, HTTP/3 chỉ dựa trên lớp IP (xây dựng trên UDP như TCP), giúp cải thiện tốc độ truyền tải trung bình và giảm thiểu hiện tượng tắc nghẽn kết nối TCP không thường xuyên, điều này có thể tạm thời ngăn cản hoặc làm chậm luồng dữ liệu của tất cả các luồng (một dạng khác của 'head of line blocking').

Lịch sử

Khái niệm về siêu văn bản được Ted Nelson phát triển vào năm 1965 trong dự án Xanadu, lấy cảm hứng từ ý tưởng về hệ thống quản lý thông tin dựa trên vi phim 'memex' trong luận án 'As We May Think' của ông vào năm 1945. Tim Berners-Lee và nhóm nghiên cứu tại CERN được công nhận với việc phát minh ra HTTP gốc, cùng với HTML và các công nghệ hỗ trợ cho máy chủ web và trình duyệt web. HTTP được thiết kế để bổ sung cho dự án sáng tạo khác của Berners-Lee: 'WorldWideWeb', công bố lần đầu vào năm 1989 và ngày nay được biết đến với tên gọi World Wide Web.

Máy chủ web đầu tiên được khởi động vào năm 1990. Lúc đó, giao thức chỉ hỗ trợ một phương thức duy nhất, gọi là GET, dùng để yêu cầu lấy dữ liệu từ một trang web trên máy chủ. Phản hồi từ máy chủ luôn luôn là một trang HTML được định dạng.

Tóm tắt các cột mốc quan trọng của các phiên bản HTTP

HTTP/0.9

Vào năm 1991, phiên bản đầu tiên của HTTP được công bố dưới dạng tài liệu ngắn gọn, dài chưa đến 700 từ, được gọi là HTTP/0.9. Phiên bản này chỉ hỗ trợ phương thức GET, cho phép người dùng chỉ có thể lấy tài liệu HTML từ máy chủ mà không hỗ trợ các định dạng tệp khác hoặc tải lên dữ liệu.

HTTP/1.0-nháp

Bắt đầu từ năm 1992, một tài liệu mới được soạn thảo để định hình sự phát triển của giao thức cơ bản thành phiên bản hoàn thiện tiếp theo. Tài liệu này hỗ trợ cả phương thức GET đơn giản của phiên bản 0.9 và yêu cầu GET đầy đủ với phiên bản HTTP của máy khách. Đây là bản nháp đầu tiên trong nhiều bản nháp của HTTP/1.0, trước khi hoàn thiện phiên bản chính thức HTTP/1.0.

Nhóm làm việc HTTP W3C

Vào đầu năm 1995, sau khi đồng thuận về các tính năng mới cần thiết của giao thức HTTP, nhóm làm việc HTTP (HTTP WG), do Dave Raggett đứng đầu, được thành lập để chuẩn hóa và mở rộng giao thức. Mục tiêu là cải thiện các tác vụ mở rộng, trao đổi thông tin phong phú hơn và tăng cường bảo mật thông qua việc bổ sung các phương thức và trường Header.

Nhóm HTTP WG dự định phát hành các phiên bản HTTP/1.0 và HTTP/1.1 trong năm 1995, nhưng do khối lượng công việc lớn, lịch trình phải kéo dài hơn một năm.

HTTP WG cũng dự định phát triển một phiên bản HTTP trong tương lai xa, gọi là HTTP-NG (HTTP Next Generation), để giải quyết các vấn đề còn tồn tại của các phiên bản trước, như hiệu suất và độ trễ thấp. Tuy nhiên, công việc này chỉ bắt đầu sau một vài năm và không bao giờ hoàn thành.

HTTP/1.0

Vào tháng 5 năm 1996, RFC 1945 được công bố, đánh dấu sự hoàn thiện của phiên bản HTTP/1.0, bao gồm tất cả các đặc tính đã được sử dụng trong 4 năm qua. Phiên bản này đã trở thành tiêu chuẩn cho nhiều trình duyệt và máy chủ web.

Vào đầu năm 1996, các nhà phát triển bắt đầu tích hợp các phần mở rộng không chính thức của HTTP/1.0 (như kết nối duy trì) vào sản phẩm của họ, dựa trên các bản nháp của HTTP/1.1 sắp tới.

HTTP/1.1

Kể từ đầu năm 1996, các trình duyệt web và nhà phát triển máy chủ lớn bắt đầu triển khai các tính năng mới của HTTP/1.1 theo các đặc tính kỹ thuật dự thảo. Người dùng cuối nhanh chóng chấp nhận các phiên bản mới. Đến tháng 3 năm 1996, một công ty lưu trữ web báo cáo rằng hơn 40% trình duyệt sử dụng HTTP/1.1 để kích hoạt lưu trữ ảo. Đến tháng 6 năm 1996, 65% các trình duyệt truy cập vào máy chủ của công ty đó đều tuân thủ HTTP/1.1.

Vào tháng 1 năm 1997, RFC 2068 được phát hành chính thức, định hình các đặc tính kỹ thuật của HTTP/1.1.

Đến tháng 6 năm 1999, RFC 2616 được phát hành để cập nhật và cải thiện HTTP/1.1 dựa trên đặc tính kỹ thuật trước đó.

Nhóm làm việc HTTP-NG W3C

Tiếp nối kế hoạch của Nhóm làm việc HTTP năm 1995, vào năm 1997, nhóm làm việc HTTP-NG được thành lập để phát triển HTTP-NG (HTTP New Generation). Một số bản nháp và đề xuất cho giao thức mới đã được đưa ra để tích hợp tính năng ghép kênh trong một kết nối TCP/IP duy nhất. Tuy nhiên, nhóm đã ngừng hoạt động vào năm 1999 và chuyển giao các vấn đề kỹ thuật cho IETF.

Nhóm làm việc IETF HTTP tái hoạt động

Vào năm 2007, nhóm làm việc HTTP IETF (HTTP WG bis hoặc HTTPbis) được khởi động lại để sửa đổi và làm rõ các đặc tính kỹ thuật của HTTP/1.1, đồng thời phát triển các đặc tính kỹ thuật của HTTP/2 (được gọi là httpbis).

SPDY: giao thức HTTP không chính thức phát triển bởi Google

Vào năm 2009, Google công bố đã phát triển và thử nghiệm một giao thức nhị phân mới gọi là SPDY, nhằm tăng tốc đáng kể lưu lượng truy cập web, đặc biệt giữa trình duyệt web và máy chủ. SPDY đã chứng minh sự cải thiện tốc độ so với HTTP/1.1 và nhanh chóng được áp dụng bởi Chromium và các trình duyệt lớn khác.

Nhiều ý tưởng về ghép kênh các luồng HTTP qua một kết nối TCP/IP đã được lấy từ nhiều nguồn, bao gồm cả dự án của nhóm làm việc W3C HTTP-NG.

HTTP/2

Từ tháng 1 đến tháng 3 năm 2012, nhóm công tác HTTP (HTTPbis) công bố sẽ tập trung vào việc phát triển HTTP/2 và hoàn thiện các đặc tính kỹ thuật của HTTP/1.1. Họ đã quyết định phát triển HTTP/2 từ SPDY sau khi cân nhắc các yếu tố cần thiết.

Vào tháng 5 năm 2015, HTTP/2 được công bố qua RFC 7540 và nhanh chóng được áp dụng bởi các trình duyệt web hỗ trợ SPDY và sau đó là các máy chủ web.

Các bản cập nhật năm 2014 cho HTTP/1.1

Vào tháng 6 năm 2014, nhóm làm việc HTTP phát hành các đặc tính kỹ thuật HTTP/1.1 trong sáu phần cập nhật RFC 2616 đã lỗi thời:

• RFC 7230, HTTP/1.1: Cú pháp và định tuyến thông điệp
• RFC 7231, HTTP/1.1: Ngữ nghĩa và Nội dung
• RFC 7232, HTTP/1.1: Yêu cầu có điều kiện
• RFC 7233, HTTP/1.1: Yêu cầu phạm vi
• RFC 7234, HTTP/1.1: Bộ nhớ đệm
• RFC 7235, HTTP/1.1: Xác thực

Ngừng hỗ trợ HTTP/0.9

Trong phụ lục A của RFC 7230, HTTP/0.9 đã bị khai tử hoàn toàn đối với các máy chủ hỗ trợ phiên bản HTTP/1.1 (và cao hơn):

Vì HTTP/0.9 không hỗ trợ các trường Header trong yêu cầu, nên không có cơ chế nào để sử dụng máy chủ ảo dựa trên tên (chọn tài nguyên qua trường Header Máy chủ). Bất kỳ máy chủ nào sử dụng máy chủ ảo dựa trên tên đều phải ngừng hỗ trợ HTTP/0.9. Trên thực tế, nhiều yêu cầu được gán nhầm là HTTP/0.9 thực chất là các yêu cầu HTTP/1.x bị xây dựng không đúng cách do máy khách không mã hóa đúng mục tiêu yêu cầu.

Từ năm 2016, các nhà quản lý sản phẩm, nhà phát triển user agent (như trình duyệt) và máy chủ web đã bắt đầu có kế hoạch ngừng hỗ trợ HTTP/0.9, chủ yếu vì những lý do sau:

• Đơn giản đến mức không cần tài liệu RFC (chỉ cần tài liệu gốc là đủ);
• Thiếu tiêu đề HTTP và nhiều tính năng bảo mật hiện đại;
• Không còn phổ biến từ năm 1999 trở đi (vì HTTP/1.0 và HTTP/1.1) và chỉ còn được dùng bởi các phần cứng mạng rất cũ như router cổ lỗ sĩ.

HTTP/3

Vào năm 2020, bản thảo đầu tiên của HTTP/3 được công bố và nhanh chóng được các trình duyệt web và máy chủ lớn đưa vào sử dụng.

Vào ngày 6 tháng 6 năm 2022, IETF chính thức chuẩn hóa HTTP/3 với RFC 9114.

Cập nhật và tái cấu trúc năm 2022

Vào tháng 6 năm 2022, một loạt RFC đã được phát hành, thay thế nhiều tài liệu cũ và đưa ra những thay đổi nhỏ, đồng thời tái cấu trúc mô tả ngữ nghĩa HTTP thành tài liệu riêng biệt.

• RFC 9110, Ngữ nghĩa HTTP
• RFC 9111, Bộ nhớ đệm HTTP
• RFC 9112, HTTP/1.1
• RFC 9113, HTTP/2
• RFC 9114, HTTP/3
• RFC 9204, QPACK: Nén trường cho HTTP/3
• RFC 9218, Chế độ ưu tiên mở rộng cho HTTP

HTTP Session

Session (phiên làm việc) là một khái niệm phổ biến trong lập trình web kết nối với cơ sở dữ liệu. Đặc biệt, các chức năng như đăng nhập và đăng xuất người dùng thường không thể thực hiện nếu không có session. Ví dụ bao gồm email, giao dịch ngân hàng, v.v.

HTTPS:\\ Xác thực

Các phương thức yêu cầu HTTP

Phương thức yêu cầu HTTP chỉ định hành động cần thực hiện đối với tài nguyên được xác định bởi Request-URI đã cung cấp

GET

Phương thức GET được sử dụng để truy xuất thông tin từ máy chủ qua một URI đã chỉ định. Các yêu cầu GET chỉ nhận dữ liệu và không thay đổi bất kỳ thông tin nào trên máy chủ.

HEAD

Tương tự phương thức GET, nhưng kèm theo truyền tải thông tin trạng thái và phần header.

POST

Phương thức POST dùng các mẫu HTML để gửi dữ liệu đến máy chủ, chẳng hạn như thông tin người dùng, tập tin tải lên, và các dữ liệu khác.

PUT

Cập nhật tất cả các đại diện hiện tại của tài nguyên mục tiêu bằng nội dung được tải lên.

DELETE

Xóa bỏ toàn bộ các đại diện hiện có của tài nguyên được chỉ định bởi URI.

CONNECT

Tạo một kết nối tunnel đến máy chủ được chỉ định bởi URI đã cung cấp.

OPTIONS

Mô tả các chức năng giao tiếp liên quan đến tài nguyên mục tiêu.

TRACE

Thực hiện một vòng lặp kiểm tra, xác nhận thông báo dọc theo đường dẫn đến tài nguyên mục tiêu.

HTTP Response

Khi máy chủ nhận và xử lý một HTTP Request, nó sẽ phản hồi bằng một HTTP Response chứa các thành phần sau đây:

• Đầu tiên là dòng trạng thái (Status-Line)
• Có thể có một hoặc nhiều trường Header (General | Response | Entity) theo sau CRLF
• Tiếp theo là một dòng trống đánh dấu kết thúc các trường header
• Cuối cùng là phần thân thông báo tùy chọn

Phản hồi từ máy chủ

Dưới đây là một ví dụ về HTTP Response:

HTTP/1.1 200 OK
Date: Mon, ngày 23 tháng 5 năm 2005 22:38:34 GMT
Content-Type: text/html; charset=UTF-8
Content-Encoding: UTF-8
Content-Length: 138
Last-Modified: Wed, 08 Jan 2003 23:11:55 GMT
Server: Apache/1.3.3.7 (Unix) (Red-Hat/Linux)
ETag: '3f80f-1b6-3e1cb03b'
Accept-Ranges: bytes
Connection: close

<html>
<head>
  <title>Trang Ví Dụ</title>
</head>
<body>
  Xin chào, đây là một tài liệu HTML rất đơn giản.
</body>
</html>

Dòng Status-Line: Dòng Status-Line bao gồm phiên bản giao thức (HTTP-Version), mã trạng thái số (Status-Code) và một cụm từ văn bản mô tả trạng thái. Các phần tử này được phân cách bởi dấu cách.

Mã trạng thái HTTP

Mã trạng thái HTTP là phản hồi mà máy chủ gửi lại mỗi khi nhận được một yêu cầu HTTP.

Mã trạng thái Status-Code là một số nguyên gồm 3 chữ số, trong đó chữ số đầu tiên chỉ ra loại phản hồi, còn hai chữ số cuối không ảnh hưởng đến phân loại. Có 5 nhóm chính cho chữ số đầu tiên như sau:

Điều này cho thấy yêu cầu đã được nhận và quá trình đang tiếp tục được thực hiện.

Mã trạng thái này cho thấy máy chủ đã nhận được phần đầu của yêu cầu và đang chờ nhận phần còn lại.

Yêu cầu từ phía khách hàng yêu cầu máy chủ chuyển đổi giao thức và máy chủ đã đồng ý thực hiện điều này.

Điều này có nghĩa là yêu cầu đã được nhận, hiểu và xử lý thành công.

Yêu cầu đã được máy chủ xử lý một cách thành công

Yêu cầu đã được thực hiện thành công và máy chủ đã tạo ra một tài nguyên mới.

Máy chủ đã nhận yêu cầu, nhưng vẫn chưa thực hiện xử lý.

Yêu cầu đã được xử lý thành công, nhưng thông tin trả về có thể đến từ nguồn khác.

Máy chủ đã xử lý yêu cầu thành công, nhưng không gửi về bất kỳ nội dung nào.

Máy chủ đã xử lý yêu cầu thành công nhưng không trả lại nội dung. Khác với phản hồi 204, phản hồi này yêu cầu người yêu cầu phải đặt lại tài liệu.

Máy chủ đã xử lý thành công một phần của yêu cầu.

Điều này có nghĩa là một hành động khác cần được thực hiện để hoàn tất yêu cầu.

Trang web yêu cầu đã được chuyển đến một địa chỉ URL mới vĩnh viễn.

Trang yêu cầu đã được di chuyển tạm thời đến một địa chỉ URL mới.

Trang yêu cầu không có thay đổi nào kể từ lần yêu cầu trước đó. Khi máy chủ gửi phản hồi này, nó không kèm theo nội dung trang.

Điều này có nghĩa là yêu cầu chứa cú pháp không hợp lệ hoặc không thể thực hiện.

Máy chủ không thể hiểu yêu cầu gửi đến.

Yêu cầu phải được xác thực. Máy chủ có thể phản hồi yêu cầu nhập tài khoản và mật khẩu (thường gặp khi client yêu cầu trang đăng nhập).

Máy chủ từ chối yêu cầu (thường là do đăng nhập không thành công).

Máy chủ không thể tìm trang yêu cầu. Ví dụ, mã này được trả về khi yêu cầu một trang không tồn tại trên máy chủ.

Phương thức yêu cầu không được hỗ trợ trên máy chủ.

Máy chủ tạo ra phản hồi mà không thể chấp nhận được bởi Client.

Yêu cầu Client phải xác thực qua một proxy. Phản hồi này cũng cung cấp thông tin về proxy mà Client cần sử dụng.

Yêu cầu mất nhiều thời gian hơn thời gian chờ phản hồi của máy chủ

Máy chủ gặp phải xung đột khi thực hiện yêu cầu và cần cung cấp thông tin chi tiết về các xung đột này. Mã này có thể được trả về khi yêu cầu PUT mâu thuẫn với một yêu cầu trước đó, kèm theo danh sách các khác biệt giữa các yêu cầu.

Phản hồi này chỉ ra rằng tài nguyên yêu cầu đã bị xóa vĩnh viễn. Đây là một mã tương tự như 404 (Không tìm thấy), nhưng thường được dùng khi tài nguyên không còn tồn tại. Nếu tài nguyên đã di chuyển vĩnh viễn, mã 301 nên được sử dụng để chỉ định vị trí mới của nó.

Yêu cầu phải có thông tin về độ dài nội dung (Content-Length). Máy chủ sẽ từ chối yêu cầu nếu thông tin này không được cung cấp.

Máy chủ không đáp ứng một hoặc nhiều điều kiện tiên quyết mà client đã chỉ định trong yêu cầu.

Máy chủ không thể xử lý yêu cầu vì kích thước của nó vượt quá khả năng xử lý của máy chủ.

URI trong yêu cầu (thường là một URL) quá dài để máy chủ có thể xử lý.

Máy chủ trả về mã trạng thái này khi yêu cầu phạm vi không có sẵn cho tài nguyên yêu cầu.

Máy chủ không thể thực hiện yêu cầu vì không đáp ứng được các tiêu đề kỳ vọng.

Điều này cho thấy máy chủ đã gặp sự cố khi thực hiện một yêu cầu mặc dù nó có vẻ khả thi.

Máy chủ gặp sự cố và không thể hoàn thành yêu cầu.

Máy chủ thiếu chức năng cần thiết để xử lý yêu cầu. Ví dụ, mã này có thể được trả về nếu máy chủ không hỗ trợ phương thức yêu cầu.

Khi hoạt động như một gateway hoặc proxy, máy chủ nhận được phản hồi không hợp lệ từ máy chủ phía sau.

Máy chủ hiện không có sẵn do bị quá tải hoặc đang trong thời gian bảo trì. Đây thường là một tình trạng tạm thời.

Máy chủ hoạt động như một gateway hoặc proxy nhưng không nhận được phản hồi kịp thời từ máy chủ phía sau.

Máy chủ không hỗ trợ phiên bản giao thức HTTP được sử dụng trong yêu cầu.

Dưới đây là danh sách tất cả các mã trạng thái HTTP được nêu trong tài liệu giao thức HTTP từ trang w3c

Các trường Header phản hồi HTTP

Các trường Header phản hồi cho phép máy chủ gửi thêm thông tin về phản hồi mà không thể bao gồm trong dòng Status-Line. Các trường này cung cấp thông tin về máy chủ và về việc truy cập từ xa tới nguồn được xác định bởi Request-URI:

response-header = Accept-Ranges; 
                       | Age     ; 
                       | ETag    ; 
                       | Location; 
                       | Proxy-Authenticate; 
                       | Retry-After; 
                       | Server;
                       | Vary    ; 
                       | WWW-Authenticate;

LƯU TRỮ HTTP

Kết nối mã hóa

Có hai phương pháp phổ biến để mã hóa kết nối HTTP: HTTP Secure (HTTPS = HTTP + SSL) hoặc kết hợp HTTP với Transport Layer Security (TLS).

Liên quan

• FTP
• HTTPS
• UDP
• TCP/IP

Ghi chú

Liên kết bên ngoài

1. Giao thức HTTP w3c.org. Xem tại: https://www.w3.org/Protocols/
2. Giao thức Truyền siêu văn bản trên Wikipedia: https://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol
3. Bản RFC 2616: https://tools.ietf.org/html/rfc2616