HTTP - Hướng dẫn nhanh

Giao thức truyền siêu văn bản (HTTP) là một giao thức cấp ứng dụng dành cho các hệ thống thông tin siêu phương tiện phân tán, cộng tác. Đây là nền tảng cho giao tiếp dữ liệu cho World Wide Web (tức là internet) kể từ năm 1990. HTTP là một giao thức chung và không trạng thái có thể được sử dụng cho các mục đích khác cũng như sử dụng mở rộng các phương thức yêu cầu, mã lỗi và tiêu đề của nó.

Về cơ bản, HTTP là một giao thức truyền thông dựa trên TCP / IP, được sử dụng để cung cấp dữ liệu (tệp HTML, tệp hình ảnh, kết quả truy vấn, v.v.) trên World Wide Web. Cổng mặc định là TCP 80, nhưng các cổng khác có thể được sử dụng. Nó cung cấp một cách thức chuẩn hóa để các máy tính giao tiếp với nhau. Đặc tả HTTP chỉ định cách dữ liệu yêu cầu của khách hàng sẽ được xây dựng và gửi đến phục vụ cũng như cách máy chủ phản hồi lại những yêu cầu này.

Tính năng cơ bản

Có ba tính năng cơ bản sau đây làm cho HTTP trở thành một giao thức đơn giản nhưng mạnh mẽ:

HTTP is connectionless:Ứng dụng khách HTTP tức là. trình duyệt khởi tạo một yêu cầu HTTP và sau khi một yêu cầu được thực hiện, máy khách sẽ ngắt kết nối khỏi máy chủ và chờ phản hồi. Máy chủ xử lý yêu cầu và thiết lập lại kết nối với máy khách để gửi phản hồi trở lại.
HTTP is media independent:Điều này có nghĩa là, bất kỳ loại dữ liệu nào cũng có thể được gửi bằng HTTP miễn là cả máy khách và máy chủ đều biết cách xử lý nội dung dữ liệu. Điều này là bắt buộc đối với máy khách cũng như máy chủ để chỉ định loại nội dung bằng kiểu MIME thích hợp.
HTTP is stateless:Như đã đề cập ở trên, HTTP là một giao thức không có kết nối và đây là kết quả trực tiếp cho thấy HTTP là một giao thức không trạng thái. Máy chủ và máy khách chỉ biết về nhau khi có yêu cầu hiện tại. Sau đó, cả hai người đều quên nhau. Do bản chất này của giao thức, cả ứng dụng khách và trình duyệt đều không thể lưu giữ thông tin giữa các yêu cầu khác nhau trên các trang web.

HTTP / 1.0 sử dụng một kết nối mới cho mỗi trao đổi yêu cầu / phản hồi trong đó kết nối HTTP / 1.1 có thể được sử dụng cho một hoặc nhiều trao đổi yêu cầu / phản hồi.

Kiến trúc cơ bản

Sơ đồ sau đây cho thấy một kiến trúc rất cơ bản của một ứng dụng web và mô tả vị trí của HTTP:

Giao thức HTTP là một giao thức yêu cầu / phản hồi dựa trên kiến trúc dựa trên máy khách / máy chủ trong đó trình duyệt web, rô bốt và công cụ tìm kiếm, v.v. hoạt động giống như máy khách HTTP và máy chủ Web hoạt động như máy chủ.

Khách hàng

Máy khách HTTP gửi yêu cầu tới máy chủ dưới dạng phương thức yêu cầu, URI và phiên bản giao thức, theo sau là một thông báo giống MIME chứa các công cụ sửa đổi yêu cầu, thông tin máy khách và nội dung cơ thể có thể có qua kết nối TCP / IP.

Người phục vụ

Máy chủ HTTP phản hồi bằng một dòng trạng thái, bao gồm phiên bản giao thức của thông báo và mã thành công hoặc lỗi, sau đó là thông báo giống MIME chứa thông tin máy chủ, thông tin về thực thể và nội dung cơ thể thực thể có thể có.

Chương này sẽ liệt kê một số Thông số Giao thức HTTP quan trọng và cú pháp của chúng theo cách chúng được sử dụng trong giao tiếp. Ví dụ: định dạng cho ngày tháng, định dạng URL, v.v. Điều này sẽ giúp bạn xây dựng các thông báo yêu cầu và phản hồi trong khi viết các chương trình máy khách hoặc máy chủ HTTP. Bạn sẽ thấy cách sử dụng đầy đủ các tham số này trong các chương tiếp theo trong khi giải thích cấu trúc thông báo cho các yêu cầu và phản hồi HTTP.

Phiên bản HTTP

HTTP sử dụng một <major>.<minor>lược đồ đánh số để chỉ ra các phiên bản của giao thức. Phiên bản của thông báo HTTP được chỉ ra bởi trường HTTP-Version trong dòng đầu tiên. Đây là cú pháp chung của việc chỉ định số phiên bản HTTP:

HTTP-Version   = "HTTP" "/" 1*DIGIT "." 1*DIGIT

Thí dụ

HTTP/1.0

or

HTTP/1.1

Số nhận dạng tài nguyên đồng nhất (URI)

Số nhận dạng tài nguyên thống nhất (URI) được định dạng đơn giản, chuỗi không phân biệt chữ hoa chữ thường chứa tên, vị trí, v.v. để xác định tài nguyên, ví dụ: trang web, dịch vụ web, v.v. Cú pháp chung của URI được sử dụng cho HTTP như sau:

URI = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]]

Đây nếu port trống hoặc không được cung cấp, cổng 80 được giả định cho HTTP và trống abs_path tương đương với một abs_pathcủa "/". Các ký tự khác với những ký tự trongreserved và unsafe bộ tương đương với mã hóa ""% "HEX HEX" của chúng.

Thí dụ

Hai URI sau là tương đương:

http://abc.com:80/~smith/home.html
http://ABC.com/%7Esmith/home.html
http://ABC.com:/%7esmith/home.html

Định dạng ngày / giờ

Tất cả các tem ngày / giờ HTTP PHẢI được thể hiện bằng Giờ trung bình Greenwich (GMT), không có ngoại lệ. Các ứng dụng HTTP được phép sử dụng bất kỳ biểu hiện nào sau đây của ba biểu tượng dấu ngày / giờ:

Sun, 06 Nov 1994 08:49:37 GMT  ; RFC 822, updated by RFC 1123
Sunday, 06-Nov-94 08:49:37 GMT ; RFC 850, obsoleted by RFC 1036
Sun Nov  6 08:49:37 1994       ; ANSI C's asctime() format

Bộ nhân vật

Bạn sử dụng bộ ký tự để chỉ định bộ ký tự mà khách hàng thích. Nhiều bộ ký tự có thể được liệt kê cách nhau bằng dấu phẩy. Nếu giá trị không được chỉ định, giá trị mặc định là US-ASCII.

Thí dụ

Sau đây là các bộ ký tự hợp lệ:

US-ASCII

or

ISO-8859-1

or 

ISO-8859-7

Mã hóa nội dung

Giá trị mã hóa nội dung cho biết một thuật toán mã hóa đã được sử dụng để mã hóa nội dung trước khi chuyển nội dung đó qua mạng. Mã nội dung chủ yếu được sử dụng để cho phép tài liệu được nén hoặc chuyển đổi một cách hữu ích mà không làm mất danh tính.

Tất cả các giá trị mã hóa nội dung đều không phân biệt chữ hoa chữ thường. HTTP / 1.1 sử dụng các giá trị mã hóa nội dung trong trường tiêu đề Chấp nhận mã hóa và Mã hóa nội dung mà chúng ta sẽ thấy trong các chương tiếp theo.

Thí dụ

Sau đây là các lược đồ mã hóa hợp lệ:

Accept-encoding: gzip

or

Accept-encoding: compress

or 

Accept-encoding: deflate

Các loại phương tiện

HTTP sử dụng Các loại phương tiện Internet trong Content-Type và Accepttrường tiêu đề để cung cấp tính năng nhập dữ liệu mở và có thể mở rộng và thương lượng kiểu. Tất cả các giá trị kiểu phương tiện được đăng ký với Cơ quan cấp số được ấn định trên Internet ((IANA). Sau đây là cú pháp chung để chỉ định loại phương tiện:

media-type     = type "/" subtype *( ";" parameter )

Tên thuộc tính type, subtype và tham số không phân biệt chữ hoa chữ thường.

Thí dụ

Accept: image/gif

Thẻ ngôn ngữ

HTTP sử dụng các thẻ ngôn ngữ trong Accept-Language và Content-Languagelĩnh vực. Thẻ ngôn ngữ bao gồm 1 hoặc nhiều phần: Thẻ ngôn ngữ chính và một loạt thẻ phụ có thể trống:

language-tag  = primary-tag *( "-" subtag )

Khoảng trắng không được phép trong thẻ và tất cả các thẻ đều không phân biệt chữ hoa chữ thường.

Thí dụ

Các thẻ mẫu bao gồm:

en, en-US, en-cockney, i-cherokee, x-pig-latin

Trong đó bất kỳ thẻ chính gồm hai chữ cái nào là chữ viết tắt của ngôn ngữ ISO-639 và bất kỳ thẻ phụ nào có hai chữ cái đầu tiên là mã quốc gia ISO-3166.

HTTP dựa trên mô hình kiến trúc máy khách-máy chủ và một giao thức yêu cầu / phản hồi không trạng thái hoạt động bằng cách trao đổi thông điệp qua kết nối TCP / IP đáng tin cậy.

"Máy khách" HTTP là một chương trình (trình duyệt Web hoặc bất kỳ máy khách nào khác) thiết lập kết nối với máy chủ nhằm mục đích gửi một hoặc nhiều thông báo yêu cầu HTTP. "Máy chủ" HTTP là một chương trình (thường là một máy chủ web như Apache Web Server hoặc Internet Information Services IIS, v.v.) chấp nhận các kết nối để phục vụ các yêu cầu HTTP bằng cách gửi các thông báo phản hồi HTTP.

HTTP sử dụng Mã định danh tài nguyên đồng nhất (URI) để xác định một tài nguyên nhất định và thiết lập kết nối. Sau khi kết nối được thiết lập,HTTP messagesđược chuyển ở định dạng tương tự như định dạng được sử dụng bởi thư Internet [RFC5322] và Tiện ích mở rộng thư Internet đa năng (MIME) [RFC2045]. Những thông báo này bao gồmrequests từ máy khách đến máy chủ và responses từ máy chủ đến máy khách sẽ có định dạng sau:

HTTP-message   = <Request> | <Response> ; HTTP/1.1 messages

Yêu cầu HTTP và phản hồi HTTP sử dụng định dạng thông báo chung của RFC 822 để truyền dữ liệu cần thiết. Định dạng thông báo chung này bao gồm bốn mục sau.


     
      A Start-line
 Zero or more header fields followed by CRLF
 An empty line (i.e., a line with nothing preceding the CRLF) indicating the end of the header fields
 Optionally a message-body

Phần sau sẽ giải thích từng thực thể được sử dụng trong thông điệp HTTP.

Dòng bắt đầu tin nhắn

Dòng bắt đầu sẽ có cú pháp chung sau:

start-line = Request-Line | Status-Line

Chúng ta sẽ thảo luận về Dòng yêu cầu và Dòng trạng thái trong khi thảo luận về các thông báo HTTP Request và HTTP Response tương ứng. Bây giờ, hãy xem các ví dụ về dòng bắt đầu trong trường hợp yêu cầu và phản hồi:

GET /hello.htm HTTP/1.1     (This is Request-Line sent by the client)

HTTP/1.1 200 OK             (This is Status-Line sent by the server)

Trường tiêu đề

Trường giới hạn HTTP cung cấp thông tin bắt buộc về yêu cầu hoặc phản hồi hoặc về đối tượng được gửi trong nội dung thư. Có bốn loại tiêu đề thư HTTP sau:

General-header: Các trường tiêu đề này có khả năng áp dụng chung cho cả thông báo yêu cầu và phản hồi.
Request-header: Các trường tiêu đề này chỉ có thể áp dụng cho các thông báo yêu cầu.
Response-header: Các trường tiêu đề này chỉ có thể áp dụng cho các thông báo phản hồi.
Entity-header: Các trường tiêu đề này xác định siêu thông tin về phần thân thực thể hoặc nếu không có phần nội dung nào

Tất cả các tiêu đề được đề cập ở trên đều tuân theo cùng một định dạng chung và mỗi trường tiêu đề bao gồm một tên theo sau bởi dấu hai chấm (:) và giá trị trường như sau:

message-header = field-name ":" [ field-value ]

Sau đây là các ví dụ về các trường tiêu đề khác nhau:

User-Agent: curl/7.16.3 libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3
Host: www.example.com
Accept-Language: en, mi
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache
Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT
ETag: "34aa387-d-1568eb00"
Accept-Ranges: bytes
Content-Length: 51
Vary: Accept-Encoding
Content-Type: text/plain

Nội dung Thư

Phần nội dung thông báo là tùy chọn đối với thông báo HTTP nhưng nếu nó có sẵn thì nó được sử dụng để mang phần thân thực thể được liên kết với yêu cầu hoặc phản hồi. Nếu cơ thể thực thể được liên kết thì thườngContent-Type và Content-Length dòng tiêu đề chỉ định bản chất của phần nội dung được liên kết.

Nội dung thư là phần chứa dữ liệu yêu cầu HTTP thực tế (bao gồm dữ liệu biểu mẫu và dữ liệu được tải lên, v.v.) và dữ liệu phản hồi HTTP từ máy chủ (bao gồm tệp, hình ảnh, v.v.). Sau đây là nội dung đơn giản của nội dung thư:

<html>
<body>
<h1>Hello, World!</h1>
</body>
</html>

Máy khách HTTP gửi một yêu cầu HTTP đến máy chủ ở dạng thông báo yêu cầu bao gồm định dạng sau:


     
      A Request-line
 Zero or more header (General|Request|Entity) fields followed by CRLF
 An empty line (i.e., a line with nothing preceding the CRLF) indicating the end of the header fields
 Optionally a message-body

Phần sau sẽ giải thích từng thực thể được sử dụng trong thông điệp HTTP.

Dòng yêu cầu tin nhắn

Dòng Yêu cầu bắt đầu bằng một mã thông báo phương thức, tiếp theo là URI Yêu cầu và phiên bản giao thức, và kết thúc bằng CRLF. Các phần tử được phân tách bằng ký tự SP khoảng trắng.

Request-Line   = Method SP Request-URI SP HTTP-Version CRLF

Hãy thảo luận về từng phần được đề cập trong Dòng yêu cầu.

Phương thức yêu cầu

Yêu cầu Method chỉ ra phương pháp được thực hiện trên tài nguyên được xác định bởi Request-URI. Phương thức có phân biệt chữ hoa và chữ thường ans nên luôn được đề cập là chữ hoa. Sau đây là các phương thức được hỗ trợ trong HTTP / 1.1

SN	Phương pháp và Mô tả
1	GET Phương thức GET được sử dụng để truy xuất thông tin từ máy chủ đã cho bằng cách sử dụng một URI nhất định. Các yêu cầu sử dụng GET chỉ nên truy xuất dữ liệu và không có tác dụng nào khác đối với dữ liệu.
2	HEAD Tương tự như GET, nhưng chỉ chuyển dòng trạng thái và phần tiêu đề.
3	POST Yêu cầu POST được sử dụng để gửi dữ liệu đến máy chủ, ví dụ như thông tin khách hàng, tải tệp lên, v.v. bằng cách sử dụng các biểu mẫu HTML.
4	PUT Thay thế tất cả các bản trình bày hiện tại của tài nguyên đích bằng nội dung đã tải lên.
5	DELETE Loại bỏ tất cả các đại diện hiện tại của tài nguyên đích do URI cung cấp.
6	CONNECT Thiết lập một đường hầm đến máy chủ được xác định bởi một URI nhất định.
7	OPTIONS Mô tả các tùy chọn giao tiếp cho tài nguyên mục tiêu.
số 8	TRACE Thực hiện kiểm tra lặp lại thông báo dọc theo đường dẫn đến tài nguyên đích.

Yêu cầu-URI

URI Yêu cầu là Định danh tài nguyên đồng nhất và xác định tài nguyên để áp dụng yêu cầu. Sau đây là các biểu mẫu được sử dụng phổ biến nhất để chỉ định một URI:

Request-URI = "*" | absoluteURI | abs_path | authority

SN	Phương pháp và Mô tả
1	Dấu hoa thị được sử dụng khi yêu cầu HTTP không áp dụng cho một tài nguyên cụ thể mà cho chính máy chủ và chỉ được phép khi phương thức được sử dụng không nhất thiết phải áp dụng cho một tài nguyên. Ví dụ: OPTIONS HTTP/1.1**
2	Các absoluteURIđược sử dụng khi yêu cầu HTTP được gửi tới proxy. Proxy được yêu cầu để chuyển tiếp yêu cầu hoặc dịch vụ nó từ một bộ nhớ cache hợp lệ và trả lại phản hồi. Ví dụ: GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.1
3	Dạng phổ biến nhất của Request-URI được sử dụng để xác định tài nguyên trên máy chủ gốc hoặc cổng. Ví dụ: một khách hàng muốn truy xuất tài nguyên trên trực tiếp từ máy chủ gốc sẽ tạo kết nối TCP tới cổng 80 của máy chủ "www.w3.org" và gửi các dòng: GET /pub/WWW/TheProject.html HTTP/1.1 Host: www.w3.org Lưu ý rằng đường dẫn tuyệt đối không được để trống; nếu không có trong URI ban đầu, nó PHẢI được cung cấp là "/" (máy chủ gốc)

Yêu cầu trường tiêu đề

Chúng ta sẽ nghiên cứu General-header và Entity-header trong một chương riêng biệt khi chúng ta sẽ tìm hiểu các trường tiêu đề HTTP. Bây giờ, hãy kiểm tra các trường tiêu đề Yêu cầu là gì.

Các trường tiêu đề yêu cầu cho phép máy khách chuyển thông tin bổ sung về yêu cầu và về chính máy khách đến máy chủ. Các trường này hoạt động như các công cụ sửa đổi yêu cầu và có sẵn các trường tiêu đề Yêu cầu quan trọng sau đây có thể được sử dụng dựa trên yêu cầu.

Accept-Charset
Accept-Encoding
Accept-Language
Authorization
Expect
From
Host
If-Match
If-Modified-Since
If-None-Match
If-Range
If-Unmodified-Since
Max-Forwards
Proxy-Authorization
Range
Referer
TE
User-Agent

Bạn có thể giới thiệu các trường tùy chỉnh của mình trong trường hợp bạn định viết Máy khách và Máy chủ web tùy chỉnh của riêng mình.

Yêu cầu các ví dụ về tin nhắn

Bây giờ, hãy tập hợp tất cả lại với nhau để tạo thành một yêu cầu HTTP để tìm nạp hello.htm trang từ máy chủ web đang chạy trên tutorialspoint.com

GET /hello.htm HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.tutorialspoint.com
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Connection: Keep-Alive

Ở đây, chúng tôi không gửi bất kỳ dữ liệu yêu cầu nào đến máy chủ vì chúng tôi đang tìm nạp trang HTML kế hoạch từ máy chủ. Kết nối là một tiêu đề chung được sử dụng ở đây và phần còn lại của tiêu đề là tiêu đề yêu cầu. Sau đây là một ví dụ khác trong đó chúng tôi gửi dữ liệu biểu mẫu đến máy chủ bằng cách sử dụng nội dung thông báo yêu cầu:

POST /cgi-bin/process.cgi HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.tutorialspoint.com
Content-Type: application/x-www-form-urlencoded
Content-Length: length
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Connection: Keep-Alive

licenseID=string&content=string&/paramsXML=string

Tại đây, URL /cgi-bin/process.cgi đã cho sẽ được sử dụng để xử lý dữ liệu đã chuyển và theo đó một phản hồi sẽ được gửi lại. Đâycontent-type cho máy chủ biết rằng dữ liệu được truyền là dữ liệu biểu mẫu web đơn giản và lengthsẽ là độ dài thực tế của dữ liệu được đưa vào nội dung thư. Ví dụ sau cho thấy cách bạn có thể chuyển XML kế hoạch đến máy chủ web của mình:

POST /cgi-bin/process.cgi HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.tutorialspoint.com
Content-Type: text/xml; charset=utf-8
Content-Length: length
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Connection: Keep-Alive

<?xml version="1.0" encoding="utf-8"?>
<string xmlns="http://clearforest.com/">string</string>

Sau khi nhận và diễn giải một thông báo yêu cầu, một máy chủ sẽ trả lời bằng một thông báo phản hồi HTTP:


     
      A Status-line
 Zero or more header (General|Response|Entity) fields followed by CRLF
 An empty line (i.e., a line with nothing preceding the CRLF) indicating the end of the header fields
 Optionally a message-body

Phần sau sẽ giải thích từng thực thể được sử dụng trong thông điệp HTTP.

Dòng trạng thái tin nhắn

Dòng trạng thái bao gồm phiên bản giao thức theo sau là mã trạng thái số và cụm từ văn bản liên quan của nó. Các phần tử được phân tách bằng ký tự SP khoảng trắng.

Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF

Hãy thảo luận về từng phần được đề cập trong Dòng trạng thái.

Phiên bản HTTP

Máy chủ hỗ trợ HTTP phiên bản 1.1 sẽ trả về thông tin phiên bản sau:

HTTP-Version = HTTP/1.1

Mã trạng thái

Phần tử Mã trạng thái là một số nguyên có 3 chữ số trong đó chữ số đầu tiên của Mã trạng thái xác định loại phản hồi và hai chữ số cuối cùng không có bất kỳ vai trò phân loại nào. Có 5 giá trị cho chữ số đầu tiên:

SN	Mã và Mô tả
1	1xx: Informational Điều này có nghĩa là đã nhận được yêu cầu và tiếp tục quá trình.
2	2xx: Success Điều này có nghĩa là hành động đã được nhận, hiểu và chấp nhận thành công.
3	3xx: Redirection Điều này có nghĩa là phải thực hiện thêm hành động để hoàn thành yêu cầu.
4	4xx: Client Error Điều này có nghĩa là yêu cầu chứa cú pháp sai hoặc không thể thực hiện được
5	5xx: Server Error Máy chủ không thực hiện được yêu cầu hợp lệ

Mã trạng thái HTTP có thể mở rộng và các ứng dụng HTTP không bắt buộc phải hiểu ý nghĩa của tất cả các mã trạng thái đã đăng ký. Danh sách tất cả các mã trạng thái đã được đưa ra trong một chương riêng biệt để bạn tham khảo.

Trường tiêu đề phản hồi

Chúng ta sẽ nghiên cứu General-header và Entity-header trong một chương riêng biệt khi chúng ta sẽ tìm hiểu các trường tiêu đề HTTP. Bây giờ, hãy kiểm tra các trường tiêu đề Phản hồi là gì.

Các trường tiêu đề phản hồi cho phép máy chủ chuyển thông tin bổ sung về phản hồi mà không thể được đặt trong Dòng trạng thái. Các trường tiêu đề này cung cấp thông tin về máy chủ và về quyền truy cập thêm vào tài nguyên được xác định bởi URI yêu cầu.

Accept-Ranges
Age
ETag
Location
Proxy-Authenticate
Retry-After
Server
Vary
WWW-Authenticate

Bạn có thể giới thiệu các trường tùy chỉnh của mình trong trường hợp bạn định viết Máy khách và Máy chủ Web tùy chỉnh của riêng mình.

Ví dụ về tin nhắn phản hồi

Bây giờ, hãy tập hợp tất cả lại với nhau để tạo thành một phản hồi HTTP cho một yêu cầu tìm nạp hello.htm trang từ máy chủ web đang chạy trên tutorialspoint.com

HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache/2.2.14 (Win32)
Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT
Content-Length: 88
Content-Type: text/html
Connection: Closed

<html>
<body>
<h1>Hello, World!</h1>
</body>
</html>

Sau đây là một ví dụ về thông báo phản hồi HTTP hiển thị tình trạng lỗi khi máy chủ web không thể tìm thấy trang được yêu cầu:

HTTP/1.1 404 Not Found
Date: Sun, 18 Oct 2012 10:36:20 GMT
Server: Apache/2.2.14 (Win32)
Content-Length: 230
Connection: Closed
Content-Type: text/html; charset=iso-8859-1
   
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html>
<head>
   <title>404 Not Found</title>
</head>
<body>
   <h1>Not Found</h1>
   <p>The requested URL /t.html was not found on this server.</p>
</body>
</html>

Sau đây là ví dụ về thông báo phản hồi HTTP hiển thị tình trạng lỗi khi máy chủ web gặp phải phiên bản HTTP sai trong yêu cầu HTTP nhất định:

HTTP/1.1 400 Bad Request
Date: Sun, 18 Oct 2012 10:36:20 GMT
Server: Apache/2.2.14 (Win32)
Content-Length: 230
Content-Type: text/html; charset=iso-8859-1
Connection: Closed
   
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html>
<head>
   <title>400 Bad Request</title>
</head>
<body>
   <h1>Bad Request</h1>
   <p>Your browser sent a request that this server could not understand.<p>
   <p>The request line contained invalid characters following the protocol string.<p>
</body>
</html>

Tập hợp các phương thức chung cho HTTP / 1.1 được định nghĩa bên dưới và tập hợp này có thể được mở rộng dựa trên yêu cầu. Các tên phương thức này có phân biệt chữ hoa chữ thường và chúng phải được viết hoa.

SN	Phương pháp và Mô tả
1	GET Phương thức GET được sử dụng để truy xuất thông tin từ máy chủ đã cho bằng cách sử dụng một URI nhất định. Các yêu cầu sử dụng GET chỉ nên truy xuất dữ liệu và không có tác dụng nào khác đối với dữ liệu.
2	HEAD Tương tự như GET, nhưng chỉ chuyển dòng trạng thái và phần tiêu đề.
3	POST Yêu cầu POST được sử dụng để gửi dữ liệu đến máy chủ, ví dụ như thông tin khách hàng, tải tệp lên, v.v. bằng cách sử dụng các biểu mẫu HTML.
4	PUT Thay thế tất cả các bản trình bày hiện tại của tài nguyên đích bằng nội dung đã tải lên.
5	DELETE Loại bỏ tất cả các đại diện hiện tại của tài nguyên đích do URI cung cấp.
6	CONNECT Thiết lập một đường hầm đến máy chủ được xác định bởi một URI nhất định.
7	OPTIONS Mô tả các tùy chọn giao tiếp cho tài nguyên mục tiêu.
số 8	TRACE Thực hiện kiểm tra lặp lại thông báo dọc theo đường dẫn đến tài nguyên đích.

Phương pháp GET

Yêu cầu GET lấy dữ liệu từ máy chủ web bằng cách chỉ định các tham số trong phần URL của yêu cầu. Đây là phương pháp chính được sử dụng để truy xuất tài liệu. Sau đây là một ví dụ đơn giản sử dụng phương thức GET để tìm nạp hello.htm:

GET /hello.htm HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.tutorialspoint.com
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Connection: Keep-Alive

Sau đây sẽ là phản hồi của máy chủ đối với yêu cầu GET ở trên:

HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache/2.2.14 (Win32)
Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT
ETag: "34aa387-d-1568eb00"
Vary: Authorization,Accept
Accept-Ranges: bytes
Content-Length: 88
Content-Type: text/html
Connection: Closed

<html>
<body>
<h1>Hello, World!</h1>
</body>
</html>

Phương pháp HEAD

Phương thức HEAD có chức năng giống như GET, ngoại trừ việc máy chủ trả lời bằng dòng phản hồi và tiêu đề, nhưng không có phần thân thực thể. Sau đây là một ví dụ đơn giản sử dụng phương thức HEAD để tìm nạp thông tin tiêu đề về hello.htm:

HEAD /hello.htm HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.tutorialspoint.com
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Connection: Keep-Alive

Sau đây sẽ là phản hồi của máy chủ đối với yêu cầu GET ở trên:

HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache/2.2.14 (Win32)
Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT
ETag: "34aa387-d-1568eb00"
Vary: Authorization,Accept
Accept-Ranges: bytes
Content-Length: 88
Content-Type: text/html
Connection: Closed

Bạn có thể nhận thấy rằng ở đây máy chủ không gửi bất kỳ dữ liệu nào sau tiêu đề.

Phương pháp ĐĂNG

Phương thức POST được sử dụng khi bạn muốn gửi một số dữ liệu đến máy chủ, ví dụ như cập nhật tệp, dữ liệu biểu mẫu, v.v. Sau đây là một ví dụ đơn giản sử dụng phương thức POST để gửi dữ liệu biểu mẫu đến máy chủ sẽ được xử lý bởi process.cgi và cuối cùng một phản hồi sẽ được trả về:

POST /cgi-bin/process.cgi HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.tutorialspoint.com
Content-Type: text/xml; charset=utf-8
Content-Length: 88
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Connection: Keep-Alive

<?xml version="1.0" encoding="utf-8"?>
<string xmlns="http://clearforest.com/">string</string>

Tập lệnh phía máy chủ process.cgi xử lý dữ liệu được truyền và gửi phản hồi sau:

HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache/2.2.14 (Win32)
Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT
ETag: "34aa387-d-1568eb00"
Vary: Authorization,Accept
Accept-Ranges: bytes
Content-Length: 88
Content-Type: text/html
Connection: Closed

<html>
<body>
<h1>Request Processed Successfully</h1>
</body>
</html>

Phương pháp PUT

Phương thức PUT được sử dụng để yêu cầu máy chủ lưu trữ phần thân thực thể được bao gồm tại một vị trí được chỉ định bởi URL nhất định. Máy chủ yêu cầu ví dụ sau để lưu phần thân thực thể đã cho vàohello.htm tại thư mục gốc của máy chủ:

PUT /hello.htm HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.tutorialspoint.com
Accept-Language: en-us
Connection: Keep-Alive
Content-type: text/html
Content-Length: 182

<html>
<body>
<h1>Hello, World!</h1>
</body>
</html>

Máy chủ sẽ lưu trữ entity-body nhất định trong hello.htm và sẽ gửi lại phản hồi sau cho khách hàng:

HTTP/1.1 201 Created
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache/2.2.14 (Win32)
Content-type: text/html
Content-length: 30
Connection: Closed

<html>
<body>
<h1>The file was created.</h1>
</body>
</html>

Phương pháp DELETE

Phương thức DELETE được sử dụng để yêu cầu máy chủ xóa tệp tại vị trí được chỉ định bởi URL nhất định. Ví dụ sau yêu cầu máy chủ xóa tệp đã chohello.htm tại thư mục gốc của máy chủ:

DELETE /hello.htm HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.tutorialspoint.com
Accept-Language: en-us
Connection: Keep-Alive

Máy chủ sẽ xóa tệp được đề cập hello.htm và sẽ gửi lại phản hồi sau cho khách hàng:

HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache/2.2.14 (Win32)
Content-type: text/html
Content-length: 30
Connection: Closed

<html>
<body>
<h1>URL deleted.</h1>
</body>
</html>

Phương pháp CONNECT

Phương thức CONNECT được ứng dụng khách sử dụng để thiết lập kết nối mạng với máy chủ web qua HTTP. Ví dụ sau yêu cầu kết nối với máy chủ web đang chạy trên host tutorialspoint.com:

CONNECT www.tutorialspoint.com HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)

Kết nối được thiết lập với máy chủ và phản hồi sau được gửi lại máy khách:

HTTP/1.1 200 Connection established
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache/2.2.14 (Win32)

Phương pháp OPTIONS

Phương thức OPTIONS được ứng dụng khách sử dụng để tìm ra phương thức HTTP và các tùy chọn khác được máy chủ web hỗ trợ. Máy khách có thể chỉ định một URL cho phương thức OPTIONS hoặc dấu hoa thị (*) để chỉ toàn bộ máy chủ. Ví dụ sau yêu cầu danh sách các phương pháp được hỗ trợ bởi máy chủ web chạy trên tutorialspoint.com:

OPTIONS * HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)

Máy chủ sẽ gửi thông tin dựa trên cấu hình hiện tại của máy chủ, ví dụ:

HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache/2.2.14 (Win32)
Allow: GET,HEAD,POST,OPTIONS,TRACE
Content-Type: httpd/unix-directory

Phương pháp TRACE

Phương thức TRACE được sử dụng để chuyển nội dung của HTTP Request trở lại người yêu cầu, phương thức này có thể được sử dụng cho mục đích gỡ lỗi tại thời điểm phát triển. Ví dụ sau đây cho thấy cách sử dụng phương thức TRACE:

TRACE / HTTP/1.1
Host: www.tutorialspoint.com
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)

Máy chủ sẽ gửi thông báo sau để đáp ứng yêu cầu trên:

HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache/2.2.14 (Win32)
Content-Type: message/http
Content-Length: 39
Connection: Closed

TRACE / HTTP/1.1
Host: www.tutorialspoint.com
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)

Phần tử Mã trạng thái trong phản hồi của máy chủ, là một số nguyên có 3 chữ số trong đó chữ số đầu tiên của Mã trạng thái xác định loại phản hồi và hai chữ số cuối cùng không có bất kỳ vai trò phân loại nào. Có 5 giá trị cho chữ số đầu tiên:

SN	Mã và Mô tả
1	1xx: Informational Điều này có nghĩa là đã nhận được yêu cầu và tiếp tục quá trình.
2	2xx: Success Điều này có nghĩa là hành động đã được nhận, hiểu và chấp nhận thành công.
3	3xx: Redirection Điều này có nghĩa là phải thực hiện thêm hành động để hoàn thành yêu cầu.
4	4xx: Client Error Điều này có nghĩa là yêu cầu chứa cú pháp sai hoặc không thể thực hiện được
5	5xx: Server Error Máy chủ không thực hiện được yêu cầu hợp lệ

Mã trạng thái HTTP có thể mở rộng và các ứng dụng HTTP không bắt buộc phải hiểu ý nghĩa của tất cả các mã trạng thái đã đăng ký. Sau đây là danh sách tất cả các mã trạng thái.

1xx: Thông tin

Thông điệp:	Sự miêu tả:
100 Tiếp tục	Máy chủ mới chỉ nhận được một phần yêu cầu, nhưng miễn là nó chưa bị từ chối, máy khách nên tiếp tục với yêu cầu
101 Giao thức chuyển đổi	Máy chủ chuyển giao thức

2xx: Thành công

Thông điệp:	Sự miêu tả:
200 được	Yêu cầu là OK
201 Tạo	Yêu cầu đã hoàn tất và một tài nguyên mới được tạo
202 được chấp nhận	Yêu cầu được chấp nhận để xử lý, nhưng quá trình xử lý chưa hoàn tất
203 Thông tin không có thẩm quyền	Thông tin trong tiêu đề thực thể là từ bản sao cục bộ hoặc của bên thứ ba, không phải từ máy chủ gốc.
204 Không có nội dung	Mã trạng thái và tiêu đề được đưa ra trong phản hồi, nhưng không có phần thân thực thể trong phản hồi.
205 Đặt lại nội dung	Trình duyệt phải xóa biểu mẫu được sử dụng cho giao dịch này để có thêm thông tin đầu vào.
206 Nội dung một phần	Máy chủ đang trả về một phần dữ liệu có kích thước được yêu cầu. Được sử dụng để phản hồi yêu cầu chỉ định tiêu đề Phạm vi . Máy chủ phải chỉ định phạm vi được bao gồm trong phản hồi với tiêu đề Phạm vi nội dung .

3xx: Chuyển hướng

Thông điệp:	Sự miêu tả:
300 Nhiều lựa chọn	Một danh sách liên kết. Người dùng có thể chọn một liên kết và đi đến vị trí đó. Tối đa năm địa chỉ
301 Đã di chuyển vĩnh viễn	Trang được yêu cầu đã chuyển sang một url mới
302 Tìm thấy	Trang được yêu cầu đã tạm thời chuyển sang một url mới
303 Xem Khác	Trang được yêu cầu có thể được tìm thấy dưới một url khác
304 Không sửa đổi	Đây là mã phản hồi cho tiêu đề If-Modified-Since hoặc If-None-Match , nơi URL chưa được sửa đổi kể từ ngày được chỉ định.
305 Sử dụng Proxy	URL được yêu cầu phải được truy cập thông qua proxy được đề cập trong tiêu đề Vị trí .
306 Không sử dụng	Mã này đã được sử dụng trong phiên bản trước. Nó không còn được sử dụng, nhưng mã được bảo lưu
307 Chuyển hướng tạm thời	Trang được yêu cầu đã tạm thời chuyển sang một url mới

4xx: Lỗi máy khách

Thông điệp:	Sự miêu tả:
400 Yêu cầu Không hợp lệ	Máy chủ không hiểu yêu cầu
401 trái phép	Trang được yêu cầu cần có tên người dùng và mật khẩu
402 Yêu cầu Thanh toán	Bạn chưa thể sử dụng mã này
403 bị cấm	Truy cập bị cấm vào trang được yêu cầu
404 không tìm thấy	Máy chủ không thể tìm thấy trang được yêu cầu
Phương pháp 405 không được phép	Phương thức được chỉ định trong yêu cầu không được phép
406 Không được chấp nhận	Máy chủ chỉ có thể tạo phản hồi không được máy khách chấp nhận
407 Yêu cầu xác thực proxy	Bạn phải xác thực bằng máy chủ proxy trước khi yêu cầu này có thể được phục vụ
480 Thời gian yêu cầu hết giờ	Yêu cầu mất nhiều thời gian hơn máy chủ được chuẩn bị để chờ
409 Xung đột	Không thể hoàn thành yêu cầu do xung đột
410 đi	Trang được yêu cầu không còn nữa
411 Độ dài Yêu cầu	"Nội dung-Độ dài" không được xác định. Máy chủ sẽ không chấp nhận yêu cầu nếu không có nó
412 Điều kiện tiên quyết không thành công	Điều kiện tiên quyết được đưa ra trong yêu cầu được máy chủ đánh giá là sai
413 Đối tượng yêu cầu quá lớn	Máy chủ sẽ không chấp nhận yêu cầu vì thực thể yêu cầu quá lớn
414 Url yêu cầu quá dài	Máy chủ sẽ không chấp nhận yêu cầu do url quá dài. Xảy ra khi bạn chuyển đổi yêu cầu "đăng" thành yêu cầu "nhận" với thông tin truy vấn dài
415 Loại phương tiện không được hỗ trợ	Máy chủ sẽ không chấp nhận yêu cầu, vì loại phương tiện không được hỗ trợ
416 Phạm vi được yêu cầu không được đáp ứng	Phạm vi byte được yêu cầu không có sẵn và nằm ngoài giới hạn.
Chương 417 không thành công	Kỳ vọng được đưa ra trong trường tiêu đề yêu cầu Expect không thể được máy chủ này đáp ứng.

5xx: Lỗi máy chủ

Thông điệp:	Sự miêu tả:
500 Lỗi máy chủ nội bộ	Yêu cầu không được hoàn thành. Máy chủ gặp tình trạng không mong muốn
501 Không được triển khai	Yêu cầu không được hoàn thành. Máy chủ không hỗ trợ chức năng cần thiết
502 Cổng xấu	Yêu cầu không được hoàn thành. Máy chủ nhận được phản hồi không hợp lệ từ máy chủ ngược dòng
Lỗi 503: Dịch vụ không khả dụng	Yêu cầu không được hoàn thành. Máy chủ tạm thời quá tải hoặc ngừng hoạt động
504 Gateway Timeout	Cổng vào đã hết thời gian
Phiên bản 505 HTTP không được hỗ trợ	Máy chủ không hỗ trợ phiên bản "giao thức http"

General-header: Các trường tiêu đề này có khả năng áp dụng chung cho cả thông báo yêu cầu và phản hồi.
Client Request-header: Các trường tiêu đề này chỉ có thể áp dụng cho các thông báo yêu cầu.
Server Response-header: Các trường tiêu đề này chỉ có thể áp dụng cho các thông báo phản hồi.
Entity-header: Các trường tiêu đề này xác định siêu thông tin về phần thân thực thể hoặc nếu không có phần nội dung nào

Tiêu đề chung

Kiểm soát bộ nhớ đệm

Trường tiêu đề chung của Cache-Control được sử dụng để chỉ định các lệnh mà tất cả hệ thống bộ nhớ đệm PHẢI tuân theo. Sau đây là cú pháp:

Cache-Control : cache-request-directive|cache-response-directive

Máy khách hoặc máy chủ HTTP có thể sử dụng Cache-controltiêu đề chung để chỉ định các tham số cho bộ đệm hoặc để yêu cầu một số loại tài liệu từ bộ đệm. Các chỉ thị bộ nhớ đệm được chỉ định trong danh sách được phân tách bằng dấu phẩy. Ví dụ:

Cache-control: no-cache

Có các chỉ thị yêu cầu bộ nhớ cache quan trọng sau đây có thể được khách hàng sử dụng trong yêu cầu HTTP của nó:

SN	Chỉ thị và mô tả yêu cầu bộ nhớ cache
1	no-cache Bộ đệm ẩn không được sử dụng phản hồi để đáp ứng yêu cầu tiếp theo mà không được xác thực lại thành công với máy chủ gốc.
2	no-store Bộ nhớ đệm không nên lưu trữ bất kỳ thứ gì về yêu cầu máy khách hoặc phản hồi của máy chủ.
3	max-age = seconds Cho biết rằng khách hàng sẵn sàng chấp nhận phản hồi có tuổi không lớn hơn thời gian được chỉ định tính bằng giây.
4	max-stale [ = seconds ] Cho biết rằng khách hàng sẵn sàng chấp nhận phản hồi đã vượt quá thời gian hết hạn. Nếu giây được đưa ra, nó không được hết hạn quá thời gian đó.
5	min-fresh = seconds Cho biết rằng khách hàng sẵn sàng chấp nhận phản hồi có thời gian làm mới không nhỏ hơn tuổi hiện tại cộng với thời gian được chỉ định tính bằng giây.
6	no-transform Không chuyển đổi phần thân thực thể.
7	only-if-cached Không lấy dữ liệu mới. Bộ đệm ẩn chỉ có thể gửi một tài liệu nếu nó nằm trong bộ đệm và không nên liên hệ với máy chủ gốc để xem có bản sao mới hơn hay không.

Có các chỉ thị phản hồi bộ nhớ cache quan trọng sau đây có thể được máy chủ sử dụng trong phản hồi HTTP của nó:

SN	Chỉ thị và mô tả yêu cầu bộ nhớ cache
1	public Cho biết rằng phản hồi có thể được lưu vào bộ nhớ đệm bất kỳ.
2	private Cho biết rằng tất cả hoặc một phần của thông báo phản hồi được dành cho một người dùng duy nhất và không được lưu vào bộ nhớ đệm bằng bộ nhớ đệm dùng chung.
3	no-cache Bộ đệm ẩn không được sử dụng phản hồi để đáp ứng yêu cầu tiếp theo mà không được xác thực lại thành công với máy chủ gốc.
4	no-store Bộ nhớ đệm không nên lưu trữ bất kỳ thứ gì về yêu cầu máy khách hoặc phản hồi của máy chủ.
5	no-transform Không chuyển đổi phần thân thực thể.
6	must-revalidate Bộ nhớ đệm phải xác minh tình trạng của tài liệu cũ trước khi sử dụng và không nên sử dụng tài liệu hết hạn.
7	proxy-revalidate Chỉ thị ủy quyền xác thực lại có cùng ý nghĩa với chỉ thị phải xác thực lại, ngoại trừ nó không áp dụng cho bộ nhớ đệm tác nhân người dùng không được chia sẻ.
số 8	max-age = seconds Cho biết rằng khách hàng sẵn sàng chấp nhận phản hồi có tuổi không lớn hơn thời gian được chỉ định tính bằng giây.
9	s-maxage = seconds Độ tuổi tối đa được chỉ định bởi chỉ thị này sẽ ghi đè tuổi tối đa được chỉ định bởi chỉ thị tuổi tối đa hoặc tiêu đề Expires. Chỉ thị s-maxage luôn bị bộ đệm riêng bỏ qua.

Kết nối

Trường tiêu đề chung của Kết nối cho phép người gửi chỉ định các tùy chọn mong muốn cho kết nối cụ thể đó và không được giao tiếp bằng proxy qua các kết nối khác. Sau đây là cú pháp đơn giản của việc sử dụng tiêu đề kết nối:

Connection : "Connection"

HTTP / 1.1 xác định tùy chọn kết nối "đóng" để người gửi báo hiệu rằng kết nối sẽ bị đóng sau khi hoàn thành phản hồi. Ví dụ:

Connection: Closed

Theo mặc định, HTTP 1.1 sử dụng kết nối liên tục, nơi kết nối không tự động đóng sau một giao dịch. Mặt khác, HTTP 1.0 không có các kết nối liên tục theo mặc định. Nếu một ứng dụng khách 1.0 muốn sử dụng các kết nối liên tục, nó sẽ sử dụngkeep-alive tham số như sau:

Connection: keep-alive

Ngày

Sun, 06 Nov 1994 08:49:37 GMT  ; RFC 822, updated by RFC 1123
Sunday, 06-Nov-94 08:49:37 GMT ; RFC 850, obsoleted by RFC 1036
Sun Nov  6 08:49:37 1994       ; ANSI C's asctime() format

Đây là định dạng đầu tiên được ưu tiên nhất.

Pragma

Trường tiêu đề chung Pragma được sử dụng để bao gồm các chỉ thị cụ thể về triển khai có thể áp dụng cho bất kỳ người nhận nào trong chuỗi yêu cầu / phản hồi. Ví dụ:

Pragma: no-cache

Chỉ thị duy nhất được định nghĩa trong HTTP / 1.0 là chỉ thị không có bộ nhớ cache và được duy trì trong HTTP 1.1 để tương thích ngược. Không có chỉ thị Pragma mới nào sẽ được xác định trong tương lai.

Giới thiệu tóm tắt

Giá trị trường chung của đoạn giới thiệu chỉ ra rằng tập hợp các trường tiêu đề nhất định có trong đoạn giới thiệu của một thông báo được mã hóa bằng mã hóa truyền phân đoạn. Sau đây là cú pháp của trường tiêu đề đoạn giới thiệu:

Trailer : field-name

Các trường tiêu đề thư được liệt kê trong trường tiêu đề Đoạn giới thiệu không được bao gồm các trường tiêu đề sau:

Transfer-Encoding
Content-Length
Trailer

Chuyển mã hóa

Trường tiêu đề chung Mã hóa Chuyển cho biết kiểu chuyển đổi nào đã được áp dụng cho nội dung thư để chuyển một cách an toàn giữa người gửi và người nhận. Điều này không giống với mã hóa nội dung vì mã hóa truyền là một thuộc tính của thông báo, không phải của phần thân thực thể. Sau đây là cú pháp của trường tiêu đề Mã hóa chuyển:

Transfer-Encoding: chunked

Tất cả các giá trị mã hóa chuyển giao đều không phân biệt chữ hoa chữ thường.

Nâng cấp

Các nâng cấp chung-header cho phép khách hàng để xác định những giao thức truyền thông thêm nó hỗ trợ và muốn sử dụng nếu phát hiện máy chủ nó thích hợp với các giao thức chuyển đổi. Ví dụ:

Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11

Trường tiêu đề Nâng cấp nhằm cung cấp một cơ chế đơn giản để chuyển đổi từ HTTP / 1.1 sang một số giao thức không tương thích khác

Thông qua

Các Via chung tiêu đề phải được sử dụng bởi các cổng và proxy để chỉ các giao thức trung gian và người nhận. Ví dụ: một thông báo yêu cầu có thể được gửi từ một tác nhân người dùng HTTP / 1.0 tới một proxy nội bộ có tên mã là "fred", sử dụng HTTP / 1.1 để chuyển tiếp yêu cầu tới một proxy công cộng tại nothing.com, nó sẽ hoàn thành yêu cầu bằng chuyển tiếp nó đến máy chủ gốc tại www.ics.uci.edu. Yêu cầu mà www.ics.uci.edu nhận được sau đó sẽ có trường tiêu đề Via sau:

Via: 1.0 fred, 1.1 nowhere.com (Apache/1.1)

Trường tiêu đề Nâng cấp nhằm cung cấp một cơ chế đơn giản để chuyển đổi từ HTTP / 1.1 sang một số giao thức không tương thích khác

Cảnh báo

Các cảnh báo chung-header được sử dụng để thực hiện thêm thông tin về tình trạng, chuyển đổi một thông điệp mà có thể không được phản ánh trong thông điệp. Một phản hồi có thể mang nhiều hơn một tiêu đề Cảnh báo.

Warning : warn-code SP warn-agent SP warn-text SP warn-date

Tiêu đề Yêu cầu của Khách hàng

Chấp nhận

Trường tiêu đề yêu cầu Chấp nhận có thể được sử dụng để chỉ định một số loại phương tiện được chấp nhận cho phản hồi. Sau đây là cú pháp chung:

Accept: type/subtype [q=qvalue]

Nhiều loại phương tiện có thể được liệt kê phân tách bằng dấu phẩy và qvalue tùy chọn thể hiện mức chất lượng chấp nhận được cho các loại phương tiện chấp nhận trên thang điểm từ 0 đến 1. Sau đây là một ví dụ:

Accept: text/plain; q=0.5, text/html, text/x-dvi; q=0.8, text/x-c

Điều này sẽ được hiểu là text/html và text/x-c là các loại phương tiện được ưu tiên, nhưng nếu chúng không tồn tại, thì hãy gửi text/x-dvi và nếu không tồn tại, hãy gửi text/plain thực thể.

Bộ ký tự chấp nhận

Trường tiêu đề yêu cầu Accept-Charset có thể được sử dụng để chỉ ra những bộ ký tự nào được chấp nhận cho phản hồi. Sau đây là cú pháp chung:

Accept-Charset: character_set [q=qvalue]

Nhiều bộ ký tự có thể được liệt kê phân tách bằng dấu phẩy và qvalue tùy chọn thể hiện mức chất lượng có thể chấp nhận được cho các bộ ký tự không ưu tiên trên thang điểm từ 0 đến 1. Sau đây là một ví dụ:

Accept-Charset: iso-8859-5, unicode-1-1; q=0.8

Giá trị đặc biệt "*", nếu có trong Accept-Charset trường, khớp với mọi bộ ký tự và nếu không Accept-Charset có tiêu đề, mặc định là bất kỳ bộ ký tự nào cũng được chấp nhận.

Chấp nhận mã hóa

Trường tiêu đề yêu cầu Mã hóa Chấp nhận tương tự như Chấp nhận, nhưng hạn chế mã hóa nội dung được chấp nhận trong phản hồi. Sau đây là cú pháp chung:

Accept-Encoding: encoding types

Sau đây là các ví dụ:

Accept-Encoding: compress, gzip
Accept-Encoding:
Accept-Encoding: *
Accept-Encoding: compress;q=0.5, gzip;q=1.0
Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0

Chấp nhận ngôn ngữ

Trường tiêu đề yêu cầu Chấp nhận ngôn ngữ tương tự như Chấp nhận, nhưng hạn chế tập hợp các ngôn ngữ tự nhiên được ưu tiên làm phản hồi cho yêu cầu. Sau đây là cú pháp chung:

Accept-Language: language [q=qvalue]

Nhiều ngôn ngữ có thể được liệt kê phân tách bằng dấu phẩy và qvalue tùy chọn thể hiện mức chất lượng có thể chấp nhận được cho các ngôn ngữ không ưa thích trên thang điểm từ 0 đến 1. Sau đây là một ví dụ:

Accept-Language: da, en-gb;q=0.8, en;q=0.7

Ủy quyền

Các Authorization giá trị trường yêu cầu-header bao gồm các thông tin chứa thông tin xác thực của các đại lý người dùng cho lĩnh vực tài nguyên được yêu cầu. Sau đây là cú pháp chung:

Authorization : credentials

Đặc tả HTTP / 1.0 xác định lược đồ ủy quyền CƠ BẢN, trong đó tham số ủy quyền là chuỗi username:password được mã hóa trong cơ sở 64. Sau đây là một ví dụ:

Authorization: BASIC Z3Vlc3Q6Z3Vlc3QxMjM=

Giá trị được giải mã thành là guest:guest123 Ở đâu guest là ID người dùng và guest123 là mật khẩu.

Bánh quy

Các Cookie giá trị trường yêu cầu-header chứa một cặp tên / giá trị của thông tin được lưu trữ cho URL đó. Sau đây là cú pháp chung:

Cookie: name=value

Nhiều cookie có thể được chỉ định phân tách bằng dấu chấm phẩy như sau:

Cookie: name1=value1;name2=value2;name3=value3

Chờ đợi

Trường tiêu đề yêu cầu Expect được sử dụng để chỉ ra rằng các hành vi máy chủ cụ thể được khách hàng yêu cầu. Sau đây là cú pháp chung:

Expect : 100-continue | expectation-extension

Nếu máy chủ nhận được yêu cầu chứa trường Kỳ vọng bao gồm tiện ích mở rộng kỳ vọng mà máy chủ không hỗ trợ, máy chủ phải phản hồi với trạng thái 417 (Không thành công).

Từ

Các Từ yêu cầu-header trường chứa một địa chỉ e-mail Internet cho người sử dụng con người điều khiển các đại lý người dùng yêu cầu. Sau đây là một ví dụ đơn giản:

From: [email protected]

Trường tiêu đề này có thể được sử dụng cho mục đích ghi nhật ký và như một phương tiện để xác định nguồn gốc của các yêu cầu không hợp lệ hoặc không mong muốn.

Tổ chức

Trường tiêu đề yêu cầu máy chủ được sử dụng để chỉ định máy chủ Internet và số cổng của tài nguyên được yêu cầu. Sau đây là cú pháp chung:

Host : "Host" ":" host [ ":" port ] ;

A hostmà không có bất kỳ thông tin cổng nào có nghĩa là cổng mặc định, là 80. Ví dụ: một yêu cầu trên máy chủ gốc cho http://www.w3.org/pub/WWW/ sẽ là:

GET /pub/WWW/ HTTP/1.1
Host: www.w3.org

If-Match

Trường tiêu đề yêu cầu If-Match được sử dụng với một phương thức để làm cho nó có điều kiện. Tiêu đề này yêu cầu máy chủ thực hiện phương thức được yêu cầu chỉ khi giá trị nhất định trong thẻ này khớp với các thẻ thực thể nhất định được đại diện bởiETag. Sau đây là cú pháp chung:

If-Match : entity-tag

Dấu hoa thị (*) khớp với bất kỳ thực thể nào và giao dịch chỉ tiếp tục nếu thực thể đó tồn tại. Sau đây là những ví dụ có thể có:

If-Match: "xyzzy"
If-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
If-Match: *

Nếu không có thẻ thực thể nào khớp hoặc nếu "*" được cung cấp và không có thực thể hiện tại nào tồn tại, máy chủ không được thực hiện phương thức được yêu cầu và phải trả về phản hồi 412 (Điều kiện tiên quyết không thành công).

If-Modified-Since

Trường tiêu đề yêu cầu If-Modified-Since được sử dụng với một phương thức để làm cho nó có điều kiện. Nếu URL được yêu cầu chưa được sửa đổi kể từ thời điểm được chỉ định trong trường này, một thực thể sẽ không được trả về từ máy chủ; thay vào đó, phản hồi 304 (không được sửa đổi) sẽ được trả lại mà không có bất kỳ nội dung thư nào. Sau đây là cú pháp chung:

If-Modified-Since : HTTP-date

Một ví dụ về trường là:

If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT

Nếu-Không-Khớp

Trường tiêu đề yêu cầu If-None-Match được sử dụng với một phương thức để làm cho nó có điều kiện. Tiêu đề này yêu cầu máy chủ thực hiện phương thức được yêu cầu chỉ khi một trong các giá trị nhất định trong thẻ này khớp với các thẻ thực thể nhất định được đại diện bởiETag. Sau đây là cú pháp chung:

If-None-Match : entity-tag

Dấu hoa thị (*) khớp với bất kỳ thực thể nào và giao dịch chỉ tiếp tục nếu thực thể đó không tồn tại. Sau đây là những ví dụ có thể có:

If-None-Match: "xyzzy"
If-None-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
If-None-Match: *

Nếu-Phạm vi

Trường tiêu đề yêu cầu If-Range có thể được sử dụng với GET có điều kiện để chỉ yêu cầu một phần của đối tượng bị thiếu, nếu nó chưa được thay đổi và toàn bộ đối tượng nếu nó đã thay đổi. Sau đây là cú pháp chung:

If-Range : entity-tag | HTTP-date

Có thể sử dụng thẻ thực thể hoặc ngày để xác định một phần thực thể đã nhận được. Ví dụ:

If-Range: Sat, 29 Oct 1994 19:43:31 GMT

Ở đây nếu tài liệu chưa được sửa đổi kể từ ngày nhất định, máy chủ sẽ trả về phạm vi byte được cung cấp bởi tiêu đề Phạm vi, ngược lại, nó trả về tất cả tài liệu mới.

Nếu-Không sửa đổi-Kể từ

Trường tiêu đề yêu cầu If-Unmodified-Since được sử dụng với một phương thức để làm cho nó có điều kiện. Sau đây là cú pháp chung:

If-Unmodified-Since : HTTP-date

Nếu tài nguyên được yêu cầu chưa được sửa đổi kể từ thời điểm được chỉ định trong trường này, máy chủ sẽ thực hiện thao tác được yêu cầu như thể tiêu đề If-Unmodified-Since không xuất hiện. Ví dụ:

If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT

Nếu yêu cầu thông thường sẽ dẫn đến bất kỳ điều gì khác ngoài trạng thái 2xx hoặc 412, thì tiêu đề If-Unmodified-Since sẽ bị bỏ qua.

Chuyển tiếp tối đa

Trường tiêu đề yêu cầu Max-Forwards cung cấp một cơ chế với các phương thức TRACE và OPTIONS để giới hạn số lượng proxy hoặc cổng có thể chuyển tiếp yêu cầu đến máy chủ gửi đến tiếp theo. Sau đây là cú pháp chung:

Max-Forwards : n

Giá trị Chuyển tiếp Tối đa là một số nguyên thập phân cho biết số lần còn lại thông báo yêu cầu này có thể được chuyển tiếp. Điều này rất hữu ích cho việc gỡ lỗi bằng phương thức TRACE, tránh các vòng lặp vô hạn. Ví dụ:

Max-Forwards : 5

Trường tiêu đề Max-Forwards có thể bị bỏ qua đối với tất cả các phương thức khác được xác định trong đặc tả HTTP.

Ủy quyền proxy

Trường tiêu đề yêu cầu Ủy quyền proxy cho phép máy khách tự nhận dạng (hoặc người dùng của nó) đối với một proxy yêu cầu xác thực. Sau đây là cú pháp chung:

Proxy-Authorization : credentials

Giá trị trường Ủy quyền proxy bao gồm thông tin xác thực chứa thông tin xác thực của tác nhân người dùng cho proxy và / hoặc lĩnh vực của tài nguyên được yêu cầu.

Phạm vi

Trường tiêu đề yêu cầu phạm vi chỉ định (các) phạm vi một phần của nội dung được yêu cầu từ tài liệu. Sau đây là cú pháp chung:

Range: bytes-unit=first-byte-pos "-" [last-byte-pos]

Giá trị byte-pos đầu tiên trong byte-range-spec cung cấp độ lệch byte của byte đầu tiên trong một dải. Giá trị byte-pos cuối cùng cung cấp độ lệch byte của byte cuối cùng trong phạm vi; nghĩa là, các vị trí byte được chỉ định là bao gồm. Bạn có thể chỉ định một đơn vị byte vì byte hiệu số Byte bắt đầu từ 0. Sau đây là một ví dụ đơn giản:

- The first 500 bytes 
Range: bytes=0-499

- The second 500 bytes
Range: bytes=500-999

- The final 500 bytes
Range: bytes=-500

- The first and last bytes only
Range: bytes=0-0,-1

Nhiều phạm vi có thể được liệt kê, phân tách bằng dấu phẩy. Nếu thiếu chữ số đầu tiên trong (các) phạm vi byte được phân tách bằng dấu phẩy, phạm vi này được giả định là sẽ đếm từ cuối tài liệu. Nếu chữ số thứ hai bị thiếu, phạm vi là byte n đến cuối tài liệu.

Người giới thiệu

Trường tiêu đề yêu cầu giới thiệu cho phép máy khách chỉ định địa chỉ (URI) của tài nguyên mà từ đó URL đã được yêu cầu. Sau đây là cú pháp chung:

Referer : absoluteURI | relativeURI

Sau đây là một ví dụ đơn giản:

Referer: http://www.tutorialspoint.org/http/index.htm

Nếu giá trị trường là một URI tương đối, thì nó phải được hiểu tương đối với URI yêu cầu .

TE

Trường tiêu đề yêu cầu TE cho biết nó sẵn sàng chấp nhận mã hóa truyền mở rộng nào trong phản hồi và liệu nó có sẵn sàng chấp nhận các trường đoạn giới thiệu trong mã hóa chuyển đoạn phân đoạn hay không . Sau đây là cú pháp chung:

TE   : t-codings

Sự hiện diện của từ khóa "đoạn giới thiệu" cho biết rằng khách hàng sẵn sàng chấp nhận các trường đoạn giới thiệu bằng mã hóa chuyển đoạn và nó được chỉ định một trong hai cách:

TE: deflate
TE:
TE: trailers, deflate;q=0.5

Nếu TE lĩnh vực có giá trị là rỗng hoặc nếu không có trường TE là hiện nay, việc chuyển mã hóa chỉ là chửi rủa . Một tin nhắn không có mã chuyển giao luôn được chấp nhận.

Đại lý người dùng

Trường tiêu đề yêu cầu Tác nhân người dùng chứa thông tin về tác nhân người dùng khởi tạo yêu cầu. Sau đây là cú pháp chung:

User-Agent : product | comment

Thí dụ:

User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)

Tiêu đề phản hồi của máy chủ

Chấp nhận phạm vi

Trường tiêu đề phản hồi Chấp nhận phạm vi cho phép máy chủ chỉ ra việc chấp nhận các yêu cầu phạm vi đối với tài nguyên. Sau đây là cú pháp chung:

Accept-Ranges  : range-unit | none

Ví dụ: một máy chủ chấp nhận các yêu cầu phạm vi byte có thể gửi

Accept-Ranges: bytes

Máy chủ không chấp nhận bất kỳ loại yêu cầu phạm vi nào cho tài nguyên có thể gửi:

Accept-Ranges: none

Điều này sẽ khuyên khách hàng không cố gắng yêu cầu phạm vi.

Tuổi tác

Trường tiêu đề phản hồi Độ tuổi truyền đạt ước tính của người gửi về lượng thời gian kể từ khi phản hồi (hoặc xác thực lại) được tạo tại máy chủ gốc. Sau đây là cú pháp chung:

Age : delta-seconds

Giá trị tuổi là số nguyên thập phân không âm, biểu thị thời gian tính bằng giây. Sau đây là một ví dụ đơn giản:

Age: 1030

Máy chủ HTTP / 1.1 bao gồm bộ đệm phải bao gồm trường tiêu đề Tuổi trong mọi phản hồi được tạo từ bộ đệm riêng của nó.

ETag

Trường tiêu đề phản hồi ETag cung cấp giá trị hiện tại của thẻ thực thể cho biến thể được yêu cầu. Sau đây là cú pháp chung:

ETag :  entity-tag

Sau đây là các ví dụ đơn giản:

ETag: "xyzzy"
ETag: W/"xyzzy"
ETag: ""

Vị trí

Trường tiêu đề phản hồi vị trí được sử dụng để chuyển hướng người nhận đến một vị trí khác với URI yêu cầu để hoàn thành. Sau đây là cú pháp chung:

Location : absoluteURI

Sau đây là một ví dụ đơn giản:

Location: http://www.tutorialspoint.org/http/index.htm

Trường tiêu đề Nội dung-Vị trí khác với Vị trí ở chỗ Nội dung-Vị trí xác định vị trí ban đầu của thực thể được đính kèm trong yêu cầu.

Proxy-Authenticate

Trường tiêu đề phản hồi Proxy-Authenticate phải được đưa vào như một phần của phản hồi 407 (Yêu cầu xác thực proxy). Sau đây là cú pháp chung:

Proxy-Authenticate  : challenge

Thử lại sau

Trường tiêu đề phản hồi Thử lại Sau khi có thể được sử dụng với phản hồi 503 (Dịch vụ Không khả dụng) để cho biết thời gian dịch vụ dự kiến sẽ không khả dụng cho ứng dụng khách yêu cầu. Sau đây là cú pháp chung:

Retry-After : HTTP-date | delta-seconds

Sau đây là hai ví dụ đơn giản:

Retry-After: Fri, 31 Dec 1999 23:59:59 GMT
Retry-After: 120

Trong ví dụ sau, độ trễ là 2 phút.

Người phục vụ

Trường tiêu đề phản hồi Máy chủ chứa thông tin về phần mềm được máy chủ gốc sử dụng để xử lý yêu cầu. Sau đây là cú pháp chung:

Server : product | comment

Sau đây là một ví dụ đơn giản:

Server: Apache/2.2.14 (Win32)

Nếu phản hồi đang được chuyển tiếp qua proxy, ứng dụng proxy không được sửa đổi tiêu đề phản hồi của Máy chủ.

Set-Cookie

Trường tiêu đề phản hồi Set-Cookie chứa một cặp thông tin tên / giá trị cần giữ lại cho URL này. Sau đây là cú pháp chung:

Set-Cookie: NAME=VALUE; OPTIONS

Tiêu đề phản hồi Set-Cookie bao gồm mã thông báo Set-Cookie :, theo sau là danh sách một hoặc nhiều cookie được phân tách bằng dấu phẩy. Dưới đây là các giá trị có thể bạn có thể chỉ định làm tùy chọn:

SN	Tùy chọn và Mô tả
1	Comment=comment Tùy chọn này có thể được sử dụng để chỉ định bất kỳ nhận xét nào được liên kết với cookie.
2	Domain=domain Thuộc tính Domain chỉ định miền mà cookie hợp lệ.
3	Expires=Date-time Ngày cookie sẽ hết hạn. Nếu ô này trống, cookie sẽ hết hạn khi khách truy cập thoát khỏi trình duyệt
4	Path=path Thuộc tính Đường dẫn chỉ định tập hợp con các URL mà cookie này áp dụng.
5	Secure Điều này hướng dẫn tác nhân người dùng chỉ trả lại cookie dưới một kết nối an toàn.

Sau đây là một ví dụ về tiêu đề cookie đơn giản do máy chủ tạo:

Set-Cookie: name1=value1,name2=value2; Expires=Wed, 09 Jun 2021 10:18:14 GMT

Thay đổi

Trường tiêu đề phản hồi thay đổi chỉ định rằng thực thể có nhiều nguồn và do đó có thể thay đổi theo (các) danh sách tiêu đề yêu cầu được chỉ định. Sau đây là cú pháp chung:

Vary : field-name

Bạn có thể chỉ định nhiều tiêu đề được phân tách bằng dấu phẩy và giá trị dấu hoa thị "*" báo hiệu rằng các tham số không xác định không giới hạn ở tiêu đề yêu cầu. Sau đây là một ví dụ đơn giản:

Vary: Accept-Language, Accept-Encoding

Ở đây các tên trường không phân biệt chữ hoa chữ thường.

WWW-Xác thực

Trường tiêu đề phản hồi WWW-Xác thực phải được bao gồm trong thông báo phản hồi 401 (Không được phép). Giá trị trường bao gồm ít nhất một thử thách cho biết (các) lược đồ xác thực và các tham số áp dụng cho URI yêu cầu. Sau đây là cú pháp chung:

WWW-Authenticate : challenge

WWW- Giá trị trường xác thực vì nó có thể chứa nhiều thử thách hoặc nếu nhiều trường tiêu đề WWW-Xác thực được cung cấp, bản thân nội dung của thử thách có thể chứa danh sách các tham số xác thực được phân tách bằng dấu phẩy. Sau đây là một ví dụ đơn giản:

WWW-Authenticate: BASIC realm="Admin"

Tiêu đề thực thể

Cho phép

Trường Tiêu đề thực thể Cho phép liệt kê tập hợp các phương pháp được hỗ trợ bởi tài nguyên được URI yêu cầu xác định. Sau đây là cú pháp chung:

Allow : Method

Bạn có thể chỉ định nhiều phương thức được phân tách bằng dấu phẩy. Sau đây là một ví dụ đơn giản:

Allow: GET, HEAD, PUT

Trường này không thể ngăn khách hàng thử các phương pháp khác.

Mã hóa nội dung

Trường tiêu đề thực thể Mã hóa Nội dung được sử dụng làm công cụ sửa đổi cho loại phương tiện. Sau đây là cú pháp chung:

Content-Encoding : content-coding

Mã hóa nội dung là một đặc điểm của thực thể được xác định bởi URI yêu cầu. Sau đây là một ví dụ đơn giản:

Content-Encoding: gzip

Nếu mã hóa nội dung của một thực thể trong thông báo yêu cầu không được máy chủ gốc chấp nhận, máy chủ sẽ phản hồi với mã trạng thái là 415 (Loại phương tiện không được hỗ trợ).

Nội dung-Ngôn ngữ

Trường tiêu đề thực thể Nội dung-Ngôn ngữ mô tả (các) ngôn ngữ tự nhiên của đối tượng dự kiến cho thực thể kèm theo. Sau đây là cú pháp chung:

Content-Language : language-tag

Nhiều ngôn ngữ có thể được liệt kê cho nội dung dành cho nhiều đối tượng. Sau đây là một ví dụ đơn giản:

Content-Language: mi, en

Mục đích chính của Ngôn ngữ-Nội dung là cho phép người dùng xác định và phân biệt các thực thể theo ngôn ngữ ưa thích của riêng người dùng.

Thời lượng nội dung

Trường tiêu đề thực thể Độ dài Nội dung cho biết kích thước của phần thân thực thể, theo số thập phân của OCTET, được gửi đến người nhận hoặc, trong trường hợp của phương thức HEAD, kích thước của phần thân thực thể đã được gửi có yêu cầu là một GET. Sau đây là cú pháp chung:

Content-Length : DIGITS

Sau đây là một ví dụ đơn giản:

Content-Length: 3495

Bất kỳ Nội dung-Độ dài nào lớn hơn hoặc bằng 0 đều là giá trị hợp lệ.

Nội dung-Vị trí

Trường tiêu đề thực thể Nội dung-Vị trí có thể được sử dụng để cung cấp vị trí tài nguyên cho thực thể được đính kèm trong thông báo khi thực thể đó có thể truy cập được từ một vị trí tách biệt với URI của tài nguyên được yêu cầu. Sau đây là cú pháp chung:

Content-Location:  absoluteURI | relativeURI

Sau đây là một ví dụ đơn giản:

Content-Location: http://www.tutorialspoint.org/http/index.htm

Giá trị của Nội dung-Vị trí cũng xác định URI cơ sở cho thực thể.

Nội dung-MD5

Trường tiêu đề thực thể Content-MD5 có thể được sử dụng để cung cấp thông báo MD5 về thực thể, để kiểm tra tính toàn vẹn của thông báo khi nhận được. Sau đây là cú pháp chung:

Content-MD5  : md5-digest using base64 of 128 bit MD5 digest as per RFC 1864

Sau đây là một ví dụ đơn giản:

Content-MD5  : 8c2d46911f3f5a326455f0ed7a8ed3b3

Thông báo MD5 được tính dựa trên nội dung của phần thân thực thể, bao gồm bất kỳ mã hóa nội dung nào đã được áp dụng, nhưng không bao gồm bất kỳ mã hóa truyền nào được áp dụng cho phần thân thư.

Phạm vi nội dung

Trường tiêu đề thực thể Phạm vi nội dung được gửi cùng với một phần thân thực thể để chỉ định vị trí trong phần thân thực thể đầy đủ, phần thân một phần sẽ được áp dụng. Sau đây là cú pháp chung:

Content-Range : bytes-unit SP first-byte-pos "-" last-byte-pos

Ví dụ về giá trị byte-content-range-spec, giả sử rằng thực thể chứa tổng cộng 1234 byte:

- The first 500 bytes:
Content-Range : bytes 0-499/1234

- The second 500 bytes:
Content-Range : bytes 500-999/1234

- All except for the first 500 bytes:
Content-Range : bytes 500-1233/1234

- The last 500 bytes:
Content-Range : bytes 734-1233/1234

Khi một thông báo HTTP bao gồm nội dung của một phạm vi, nội dung này được truyền với tiêu đề Phạm vi nội dung và tiêu đề Độ dài nội dung hiển thị số byte thực sự được truyền. Ví dụ,

HTTP/1.1 206 Partial content
Date: Wed, 15 Nov 1995 06:25:24 GMT
Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
Content-Range: bytes 21010-47021/47022
Content-Length: 26012
Content-Type: image/gif

Loại nội dung

Trường tiêu đề thực thể Loại-Nội dung cho biết loại phương tiện của phần thân thực thể được gửi đến người nhận hoặc trong trường hợp của phương thức HEAD, loại phương tiện sẽ được gửi đi có yêu cầu là GET. Sau đây là cú pháp chung:

Content-Type : media-type

Sau đây là một ví dụ:

Content-Type: text/html; charset=ISO-8859-4

Hết hạn

Trường tiêu đề thực thể Expires cung cấp ngày / giờ mà sau đó phản hồi được coi là cũ. Sau đây là cú pháp chung:

Expires : HTTP-date

Sau đây là một ví dụ:

Expires: Thu, 01 Dec 1994 16:00:00 GMT

Sửa đổi lần cuối

Trường tiêu đề thực thể được sửa đổi lần cuối cho biết ngày và giờ tại đó máy chủ gốc tin rằng biến thể được sửa đổi lần cuối. Sau đây là cú pháp chung:

Last-Modified: HTTP-date

Sau đây là một ví dụ:

Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT

HTTP thường được sử dụng cho các hệ thống thông tin phân tán, nơi có thể cải thiện hiệu suất bằng cách sử dụng bộ đệm phản hồi. Giao thức HTTP / 1.1 bao gồm một số phần tử nhằm mục đích làm cho bộ nhớ đệm hoạt động.

Mục tiêu của bộ nhớ đệm trong HTTP / 1.1 là loại bỏ nhu cầu gửi yêu cầu trong nhiều trường hợp và loại bỏ nhu cầu gửi phản hồi đầy đủ trong nhiều trường hợp khác.

Các cơ chế bộ nhớ cache cơ bản trong HTTP / 1.1 là các chỉ thị ngầm đối với bộ nhớ cache nơi máy chủ chỉ định thời gian hết hạn và trình xác thực. Chúng tôi sử dụngCache-Control tiêu đề cho mục đích này.

Các Cache-Controlheader cho phép máy khách hoặc máy chủ truyền nhiều lệnh khác nhau trong các yêu cầu hoặc phản hồi. Các chỉ thị này thường ghi đè các thuật toán bộ nhớ đệm mặc định. Các chỉ thị bộ nhớ đệm được chỉ định trong danh sách được phân tách bằng dấu phẩy. Ví dụ:

Cache-control: no-cache

Có các chỉ thị yêu cầu bộ nhớ cache quan trọng sau đây có thể được khách hàng sử dụng trong yêu cầu HTTP của nó:

SN	Chỉ thị và mô tả yêu cầu bộ nhớ cache
1	no-cache Bộ đệm ẩn không được sử dụng phản hồi để đáp ứng yêu cầu tiếp theo mà không được xác thực lại thành công với máy chủ gốc.
2	no-store Bộ nhớ đệm không nên lưu trữ bất kỳ thứ gì về yêu cầu máy khách hoặc phản hồi của máy chủ.
3	max-age = seconds Cho biết rằng khách hàng sẵn sàng chấp nhận phản hồi có tuổi không lớn hơn thời gian được chỉ định tính bằng giây.
4	max-stale [ = seconds ] Cho biết rằng khách hàng sẵn sàng chấp nhận phản hồi đã vượt quá thời gian hết hạn. Nếu giây được đưa ra, nó không được hết hạn quá thời gian đó.
5	min-fresh = seconds Cho biết rằng khách hàng sẵn sàng chấp nhận phản hồi có thời gian làm mới không nhỏ hơn tuổi hiện tại cộng với thời gian được chỉ định tính bằng giây.
6	no-transform Không chuyển đổi phần thân thực thể.
7	only-if-cached Không lấy dữ liệu mới. Bộ đệm ẩn chỉ có thể gửi một tài liệu nếu nó nằm trong bộ đệm và không nên liên hệ với máy chủ gốc để xem có bản sao mới hơn hay không.

Có các chỉ thị phản hồi bộ nhớ cache quan trọng sau đây có thể được máy chủ sử dụng trong phản hồi HTTP của nó:

SN	Chỉ thị và mô tả phản hồi bộ nhớ cache
1	public Cho biết rằng phản hồi có thể được lưu vào bộ nhớ đệm bất kỳ.
2	private Cho biết rằng tất cả hoặc một phần của thông báo phản hồi được dành cho một người dùng duy nhất và không được lưu vào bộ nhớ đệm bằng bộ nhớ đệm dùng chung.
3	no-cache Bộ đệm ẩn không được sử dụng phản hồi để đáp ứng yêu cầu tiếp theo mà không được xác thực lại thành công với máy chủ gốc.
4	no-store Bộ nhớ đệm không nên lưu trữ bất kỳ thứ gì về yêu cầu máy khách hoặc phản hồi của máy chủ.
5	no-transform Không chuyển đổi phần thân thực thể.
6	must-revalidate Bộ nhớ đệm phải xác minh tình trạng của tài liệu cũ trước khi sử dụng và không nên sử dụng tài liệu hết hạn.
7	proxy-revalidate Chỉ thị ủy quyền xác thực lại có cùng ý nghĩa với chỉ thị phải xác thực lại, ngoại trừ nó không áp dụng cho bộ nhớ đệm tác nhân người dùng không được chia sẻ.
số 8	max-age = seconds Cho biết rằng khách hàng sẵn sàng chấp nhận phản hồi có tuổi không lớn hơn thời gian được chỉ định tính bằng giây.
9	s-maxage = seconds Độ tuổi tối đa được chỉ định bởi chỉ thị này sẽ ghi đè tuổi tối đa được chỉ định bởi chỉ thị tuổi tối đa hoặc tiêu đề Expires. Chỉ thị s-maxage luôn bị bộ đệm riêng bỏ qua.

HTTP URL chỉ có thể được gửi qua Internet bằng cách sử dụng ASCII ký tự thiết lập , thường chứa các ký tự bên ngoài các thiết lập ASCII. Vì vậy, các ký tự không an toàn này phải được thay thế bằng% theo sau là hai chữ số thập lục phân.

Bảng sau hiển thị biểu tượng ASCII của ký tự và Biểu tượng bằng của nó và cuối cùng là ký hiệu thay thế nó có thể được sử dụng trong URL trước khi chuyển nó đến máy chủ:

ASCII	Biểu tượng	Sự thay thế
<32		Mã hóa với% xx trong đó xx là đại diện thập lục phân của ký tự.
32	không gian	+ hoặc% 20
33	!	% 21
34	"	% 22
35	#	% 23
36	$	% 24
37	%	% 25
38	&	% 26
39	'	% 27
40	(	% 28
41	)	% 29
42	*	*
43	+	% 2B
44	,	% 2C
45	-	-
46	.	.
47	/	% 2F
48	0	0
49	1	1
50	2	2
51	3	3
52	4	4
53	5	5
54	6	6
55	7	7
56	số 8	số 8
57	9	9
58	:	% 3A
59	;	% 3B
60	<	% 3C
61	=	% 3D
62	>	% 3E
63	?	% 3F
64	@	% 40
65	A	A
66	B	B
67	C	C
68	D	D
69	E	E
70	F	F
71	G	G
72	H	H
73	Tôi	Tôi
74	J	J
75	K	K
76	L	L
77	M	M
78	N	N
79	O	O
80	P	P
81	Q	Q
82	R	R
83	S	S
84	T	T
85	U	U
86	V	V
87	W	W
88	X	X
89	Y	Y
90	Z	Z
91	[	% 5B
92	\	% 5C
93	]	% 5D
94	^	% 5E
95	_	_
96	`	% 60
97	a	a
98	b	b
99	c	c
100	d	d
101	e	e
102	f	f
103	g	g
104	h	h
105	Tôi	Tôi
106	j	j
107	k	k
108	l	l
109	m	m
110	n	n
111	o	o
112	p	p
113	q	q
114	r	r
115	S	S
116	t	t
117	u	u
118	v	v
119	w	w
120	x	x
121	y	y
122	z	z
123	{	% 7B
124	\|	% 7C
125	}	% 7D
126	~	% 7E
127		% 7F
> 127		Mã hóa với% xx trong đó xx là đại diện thập lục phân của ký tự

HTTP được sử dụng cho giao tiếp qua internet, vì vậy các nhà phát triển ứng dụng, nhà cung cấp thông tin và người dùng nên biết các giới hạn bảo mật trong HTTP / 1.1. Cuộc thảo luận này không bao gồm các giải pháp dứt điểm cho các vấn đề được đề cập ở đây nhưng nó đưa ra một số đề xuất để giảm rủi ro bảo mật.

Rò rỉ thông tin cá nhân

Các ứng dụng khách HTTP thường giữ bí mật đối với một lượng lớn thông tin cá nhân như tên, vị trí, địa chỉ thư, mật khẩu, khóa mã hóa của người dùng, v.v. Vì vậy, bạn nên hết sức cẩn thận để ngăn chặn việc vô tình rò rỉ thông tin này qua giao thức HTTP sang các nguồn khác.

Tất cả các thông tin bí mật phải được lưu trữ ở phía máy chủ dưới dạng mã hóa.
Tiết lộ phiên bản phần mềm cụ thể của máy chủ có thể cho phép máy chủ trở nên dễ bị tấn công hơn trước các cuộc tấn công chống lại phần mềm được biết là có chứa lỗ hổng bảo mật.
Các proxy hoạt động như một cổng thông qua tường lửa mạng nên có các biện pháp phòng ngừa đặc biệt liên quan đến việc chuyển thông tin tiêu đề xác định các máy chủ phía sau tường lửa.
Thông tin được gửi trong trường Từ có thể xung đột với lợi ích riêng tư của người dùng hoặc chính sách bảo mật của trang web của họ và do đó, thông tin đó không được truyền đi nếu người dùng không thể tắt, bật và sửa đổi nội dung của trường.
Khách hàng không nên đưa trường tiêu đề Người giới thiệu vào một yêu cầu HTTP (không an toàn) nếu trang giới thiệu được chuyển bằng một giao thức bảo mật.
Tác giả của dịch vụ sử dụng giao thức HTTP không nên sử dụng các biểu mẫu dựa trên GET để gửi dữ liệu nhạy cảm, vì điều này sẽ khiến dữ liệu này được mã hóa trong URI yêu cầu

Tấn công dựa trên tên tệp và đường dẫn

Tài liệu nên được hạn chế đối với các tài liệu được trả về bởi các yêu cầu HTTP, chỉ là những tài liệu được dành cho quản trị viên máy chủ.

Ví dụ: UNIX, Microsoft Windows và các hệ điều hành khác sử dụng ..như một thành phần đường dẫn để chỉ ra một mức thư mục trên mức hiện tại. Trên một hệ thống như vậy, máy chủ HTTP PHẢI không cho phép bất kỳ cấu trúc nào như vậy trong URI yêu cầu nếu nó cho phép truy cập vào một tài nguyên bên ngoài những tài nguyên dự định có thể truy cập được thông qua máy chủ HTTP.

Giả mạo DNS

Khách hàng sử dụng HTTP phụ thuộc rất nhiều vào Dịch vụ tên miền và do đó thường dễ bị tấn công bảo mật dựa trên việc cố ý kết hợp sai địa chỉ IP và tên DNS. Vì vậy, khách hàng cần thận trọng trong việc giả định giá trị liên tục của liên kết số IP / tên DNS.

Nếu máy khách HTTP lưu vào bộ nhớ cache kết quả của việc tra cứu tên máy chủ để đạt được sự cải thiện về hiệu suất, họ phải quan sát thông tin TTL do DNS báo cáo. Nếu máy khách HTTP không tuân theo quy tắc này, chúng có thể bị giả mạo khi địa chỉ IP của máy chủ đã truy cập trước đó thay đổi.

Tiêu đề vị trí và giả mạo

Nếu một máy chủ duy nhất hỗ trợ nhiều tổ chức không tin tưởng nhau, thì nó PHẢI kiểm tra các giá trị của tiêu đề Vị trí và Nội dung- Vị trí trong phản hồi được tạo dưới sự kiểm soát của các tổ chức nói trên để đảm bảo rằng họ không cố gắng làm mất hiệu lực của các tài nguyên mà họ không có thẩm quyền.

Thông tin xác thực

Các ứng dụng khách HTTP và tác nhân người dùng hiện tại thường lưu giữ thông tin xác thực vô thời hạn. HTTP / 1.1. không cung cấp phương pháp để máy chủ hướng khách hàng loại bỏ các thông tin xác thực được lưu trong bộ nhớ cache, đây là một rủi ro bảo mật lớn.

Có một số cách giải quyết cho các phần của vấn đề này, và vì vậy bạn nên sử dụng bảo vệ bằng mật khẩu trong trình bảo vệ màn hình, thời gian chờ không hoạt động và các phương pháp khác để giảm thiểu các vấn đề bảo mật vốn có trong vấn đề này.

Proxy và bộ nhớ đệm

Các proxy HTTP là trung gian và đại diện cho cơ hội cho các cuộc tấn công trung gian. Proxy có quyền truy cập vào thông tin liên quan đến bảo mật, thông tin cá nhân về người dùng và tổ chức cá nhân cũng như thông tin độc quyền của người dùng và nhà cung cấp nội dung.

Người vận hành proxy nên bảo vệ hệ thống mà proxy chạy trên đó vì chúng sẽ bảo vệ bất kỳ hệ thống nào có chứa hoặc vận chuyển thông tin nhạy cảm.

Các proxy lưu vào bộ nhớ cache cung cấp thêm các lỗ hổng tiềm ẩn, vì nội dung của bộ nhớ cache là một mục tiêu hấp dẫn để khai thác độc hại. Do đó, nội dung bộ nhớ cache nên được bảo vệ dưới dạng thông tin nhạy cảm.

ví dụ 1

Yêu cầu HTTP để tìm nạp hello.htmtrang từ máy chủ web đang chạy trên tutorialspoint.com

Yêu cầu khách hàng

GET /hello.htm HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.tutorialspoint.com
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Connection: Keep-Alive

Phản hồi của máy chủ

HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache/2.2.14 (Win32)
Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT
Content-Length: 88
Content-Type: text/html
Connection: Closed

<html>
<body>
<h1>Hello, World!</h1>
</body>
</html>

Ví dụ 2

Yêu cầu HTTP để tìm nạp t.htmltrang không tồn tại trên máy chủ web đang chạy trên tutorialspoint.com

Yêu cầu khách hàng

GET /t.html HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.tutorialspoint.com
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Connection: Keep-Alive

Phản hồi của máy chủ

HTTP/1.1 404 Not Found
Date: Sun, 18 Oct 2012 10:36:20 GMT
Server: Apache/2.2.14 (Win32)
Content-Length: 230
Content-Type: text/html; charset=iso-8859-1
Connection: close
   
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html>
<head>
   <title>404 Not Found</title>
</head>
<body>
   <h1>Not Found</h1>
   <p>The requested URL /t.html was not found on this server.</p>
</body>
</html>

Ví dụ 3

Yêu cầu HTTP để tìm nạp hello.htmtừ máy chủ web đang chạy trên tutorialspoint.com , nhưng yêu cầu đến với phiên bản HTTP sai:

Yêu cầu khách hàng

GET /hello.htm HTTP1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.tutorialspoint.com
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Connection: Keep-Alive

Phản hồi của máy chủ

HTTP/1.1 400 Bad Request
Date: Sun, 18 Oct 2012 10:36:20 GMT
Server: Apache/2.2.14 (Win32)
Content-Length: 230
Content-Type: text/html; charset=iso-8859-1
Connection: close
   
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html>
<head>
   <title>400 Bad Request</title>
</head>
<body>
   <h1>Bad Request</h1>
   <p>Your browser sent a request that this server could not understand.<p>
   <p>The request line contained invalid characters following the protocol string.<p>
</body>
</html>

Ví dụ 4

Yêu cầu HTTP để đăng dữ liệu biểu mẫu lên process.cgiTrang CGI trên máy chủ web chạy trên tutorialspoint.com . Máy chủ trả về tên đã chuyển sau khi đặt chúng làm cookie:

Yêu cầu khách hàng

POST /cgi-bin/process.cgi HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.tutorialspoint.com
Content-Type: text/xml; charset=utf-8
Content-Length: 60
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Connection: Keep-Alive

first=Zara&last=Ali

Phản hồi của máy chủ

HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache/2.2.14 (Win32)
Content-Length: 88
Set-Cookie: first=Zara,last=Ali;domain=tutorialspoint.com;Expires=Mon, 19-
Nov-2010 04:38:14 GMT;Path=/
Content-Type: text/html
Connection: Closed

<html>
<body>
<h1>Hello Zara Ali</h1>
</body>
</html>