Tài Liệu Học Lập Trình HTTP ( Hacker Anonymous Việt Nam )

Đây là tài liệu do Hacker Anonymous Việt Nam biên soạn rất kĩ lưỡng và chi tiết cho những bạn học lập trình web.

HTTP là gì

[HTTP là gì]HTTP là một giao thức cấp độ ứng dụng cho các hệ thống thông tin phân phối,

cộng tác, đa phương tiện Đây là nền tảng cho giao tiếp dữ liệu cho WWW (ví dụ: Internet) từ

1990 HTTP là một giao thức chung và stateless mà có thể được sử dụng cho các mục đích khác cũng như các sự co giãn của các phương thức yêu cầu, các code lỗi và Header của nó Theo cơ bản, HTTP là một giao thức giao tiếp trên cơ sở TCP/IP, mà được sử dụng để phân phối dữ liệu (các tệp HTML, các file ảnh, …) trên WWW Cổng mặc định là TCP 80, những các cổng khác cũng có thể được sử dụng Nó cung cấp một cách được tiêu chuẩn hóa cho các máy tính để giao tiếp với nhau Chi tiết kỹ thuật HTTP xác định cách mà dữ liệu yêu cầu của Client

sẽ được xây dựng và được gửi tới Server, và cách để Server phản hồi các yêu cầu này

Các đặc trưng cơ bản

Có 3 đặc trưng cơ bản mà làm HTTP trở thành một giao thức đơn giản nhưng đầy sức mạnh:

 HTTP là giao thức connectionless (kết nối không liên tục): Client của HTTP, ví dụ:

một trình duyệt khởi tạo một yêu cầu HTTP và sau đó một yêu cầu được tạo ra, Client ngắt kết nối từ Server và đợi cho một phản hồi Server xử lý yêu cầu và thiết lập lại sự kết nối với Client để gửi phản hồi trở lại

 HTTP là một phương tiện độc lập: Nó nghĩa là, bất kỳ loại dữ liệu nào cũng có thể

được gửi bởi HTTP miễn là Server và Client biết cách để kiểm soát nội dung dữ liệu

Nó được yêu cầu cho Client cũng như Server để xác định kiểu nội dung bởi sử dụng kiểu MIME thích hợp

 HTTP là stateless: Như đã được đề cập ở trên, HTTP là connectionless và nó một kết

quả trực tiếp là HTTP trở thành một giao thức Stateless Server và Client biết về nhau chi trong một yêu cầu hiện tại Sau đó, cả hai chúng nó quên tất cả về nhau Do bản chất của giao thức, cả Client và các trình duyệt có thể giữ lại thông tin giữa các yêu cầu khác nhau giữa 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 (Request/Reponse), trong khi mà kết nối của 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

Cấu trúc cơ bản

Sơ đồ dưới đây chỉ cấu trúc rất đơn giản của một ứng dụng web và miêu 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 cấu trúc Client/Server, nơi mà các trình duyệt web, các thiết bị tìm kiếm,… hoạt động như các Client, và các Server web hoạt động như một Server

chương trình Client hoặc Server Bạn sẽ thấy sự hữu ích hoàn toàn của những tham số này trong các chương kế tiếp trong khi học tập về cấu trúc thông báo cho các yêu cầu và các phản hồi HTTP

Phiên bản HTTP

HTTP sử dụng một sơ đồ đánh số <major>.<minor> để chỉ phiên bản của giao thức Phiên

bản của một thông báo HTTP được chỉ bởi một trường HTTP-Version trong dòng đầu tiên Tại đây là cú pháp chung của việc xác định số phiên bản HTTP:

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

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

Ở đây, nếu port là trống hoặc không được cung cấp, thì port 80 được cho là cho HTTP và một abs_path trống là tương đương với một abs_path là “/” Các ký tự khác trong các bộ thiết lập reserved và unsafe là tương đương với mã hóa “%” HEX HEX” của chúng

Các định dạng Ngày/Thời gian

Tất cả các nhãn Ngày/Thời gian HTTP Phải được biểu diễn trong Greenwich Mean Time

(GMT), không có sự ngoại trừ Các ứng dụng HTTP được cho phép để sử dụng 3 nhãn đại diện Ngày/Thời gian sau:

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

Các bộ ký tự

Chúng ta sử dụng các bộ ký tự để xác định các thiết lập ký tự mà Client ưa thích Nhiều bộ thiết lập ký tự có thể được liệt kê riêng biệt bởi các dấu phảy Nếu một giá trị là không được xác định, mặc định là US-ASII

Mã hóa nội dung

Một giá trị mã hóa nội dung chỉ rằng một thuật toán mã hóa đã được sử dụng để mã hóa nội dung trước khi truyền nó tới mạng Mã hóa nội dung được sử dụng lần đầu để cho phép một tài liệu để được nén hoặc ngoài ra được truyền tải mà không thất lạc sự nhận diện

Tất cả các giá trị mã hóa nội dung là không phân biệt kiểu chữ (case-insensitive) HTTP/1.1 sử

dụng các giá trị mã hóa nội dung trong các trường Accept-Encoding

Ví dụ

Dưới đây là các sơ đồ mã hóa hợp lệ:

Accept-encoding: gzip

or

Accept-encoding: compress

or

Accept-encoding: deflate

Các kiểu đa phương tiện (media types)

HTTP sử dụng các Kiểu phương tiện Internet trong các trường Content-Type vàAccept để

cung cấp dữ liệu mở và có thể mở rộng Tất cả các giá trị kiểu phương tiện được đăng ký với IANA (Internet Assigned Number Authority) Cú pháp chung để xác định kiểu phương tiện như sau:

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

Các thuộc tính type, subtype, và parameter là case-insensitive

Ví dụ

Accept: image/gif

Các thẻ ngôn ngữ

HTTP sử dụng các thẻ ngôn ngữ trong các trường Accept-Language và Content-Language

Một thẻ ngôn ngữ bao gồm một hoặc nhiều phần: Một thẻ ngôn ngữ sơ cấp và một dãy các thẻ phụ:

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

Các khoảng trắng không được cho phép trong thẻ và tất cả các thẻ là case-insentive

Ví dụ

Các thẻ ví dụ bao gồm:

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

Hai chữ primary-tag là một chữ viết tắt cho ngôn ngữ trong ISO-639 và hai ký tự đầu tiên trong thẻ phụ subtag là mã quốc gia

Message trong HTTP

HTTP được xây dựng trên cơ sở mô hình cấu trúc Client-Server và giao thức Stateless các Yêu cầu/Phản hồi mà điều hành bởi việc trao đổi các thông báo (Message) dọc theo một kết nối TCP/IP

Một Client là một chương trình (một trình duyệt hoặc bất kỳ Client) mà thiết lập một kết nối tới một Server cho mục đích gửi một hoặc nhiều thông báo yêu cầu HTTP Một HTTP “Server” là một chương trình (hiểu theo cách chung là một Server web như Apache Server web hoặc Internet Information Services – IIS …) mà chấp nhận các kết nối để phục vụ các yêu cầu HTTP bởi việc gửi các thông báo phản hồi HTTP

HTTP sử dụng URI để nhận diện một nguồn đã cho và để thiết lập một kết nối Một khi một kết

nối được thiết lập, Các Thông báo HTTP được truyền trong một định dạng tương tự như được

sử dụng trong thư điện tử Internet Mail [RFC5322] và MIME (Multipurpose Internet Mail

Extensions) [RFC2045] Các thông báo này bao gồm cácYêu cầu từ Client tới Server và các Phản hồi từ Server tới Client mà sẽ theo định dạng sau:

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

Các yêu cầu HTTP và các phản hồi HTTP sử dụng một định dạng thông báo chung của RFC

822 cho truyền trải dữ liệu được yêu cầu Định dạng thông báo chung này bao gồm 4 mục:

 Một dòng đầu tiên

 Không hoặc nhiều trường Header theo sau bởi CRLF

 Một dòng trống (ví dụ: một dòng mà không có gì trước CRLF), chỉ phần cuối của trường Header



 Một thân thông báo tùy ý

Trong các mục tiếp theo, chúng ta sẽ giải thích từng mục được sử dụng trong thông báo HTTP

Dòng đầu thông báo (start-line)

Một dòng đầu sẽ có cú pháp chung như sau:

start-line = Request-Line | Status-Line

Chúng ta sẽ bàn luận Request-Line và Status-Line trong khi thảo luận về các thông báo Yêu

cầu HTTP và Phản hồi HTTP tương ứng Bây giờ, chúng ta xem xét một số ví dụ về dòng bắt đầu trong trường hợp yêu cầu và phản hồi

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

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

Các trường Header

Các trường Header cung cấp thông tin được yêu cầu về yêu cầu hoặc phản hồi, hoặc về đối tượng được gửi trong thân thông báo Có 4 kiểu của Header trong các thông báo HTTP:

 Kiểu chung (General-Header): Các trường Header này có khả năng ứng dụng chung

cho cả các thông báo yêu cầu và phản hồi

 Kiểu yêu cầu (Request-Header): Các trường Header này chỉ có khả năng áp dụng cho

các thông báo yêu cầu

 Kiểu phản hồi (Response-Header): Các trường Header này chỉ có khả năng áp dụng

cho các thông báo phản hồi

 Kiểu thực thể (Entity-Header): Các trường này xác định thông tin về thân-thực thể

hoặc, nếu không có phần thân nào hiển thị, về nguồn được nhận diện bởi yêu cầu Tất cả các Header được đề cập ở trên theo một định dạng chung và mỗi một trường Header bao gồm một tên được theo sau bởi một dấu hai chấm (:) và giá trị trường như sau:

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

Dưới đây là ví dụ về các trường Header đa dạng:

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

Phần thân thông báo là tùy ý cho một thông báo HTTP nhưng nếu nó là có sẵn, thì khi đó nó được sử dụng để mang phần thân được liên kết với yêu cầu hoặc phản hồi Nếu phần thân thực thể được liên kết, thì sau đó thường các dòng Content-Type và Content-Length xác định bản chất của phần thân được liên kết

Một phần thân thông báo là phần mà mang dữ liệu yêu cầu HTTP thực sự (bao gồm dữ liệu mẫu và được tải lên,…) và dữ liệu phản hồi HTTP từ Server (bao gồm các file, ảnh, …) Dưới đây là nội dung đơn giản của một phần thân thông báo:

Yêu cầu (Request) trong HTTP

Một Client gửi một yêu cầu HTTP tới một Server trong mẫu một thông báo yêu cầu mà bao gồm định dạng sau:

 Một dòng yêu cầu

 Không hoặc nhiều hơn trường Header (General|Request|Entity) được theo sau bởi CRLF

 Một dòng trống (ví dụ: một dòng không có gì đằng trước CRLF) chỉ phần kết thúc của trường Header



 Một phần thân thông báo tùy ý

Các phần dưới giải thích cách sử dụng của mỗi đối tượng trong thông báo yêu cầu HTTP

Dòng Yêu cầu

Dòng Yêu cầu bắt đầu với một thủ tục method, được theo sau bởi một Request-URI và phiên bản giao thức, và kết thúc với CRLF Các yếu tố được phân biệt riêng rẽ bởi các ký tự khoảng trống SP

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

Dưới đây thảo luận về mỗi phần được đề cập trong Dòng Yêu cầu

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

Phương thức yêu cầu chỉ phương thức để được thực hiện trên nguồn được nhận diện bởi Request-URI đã cung cấp Method là case-intensive và nên luôn luôn được đề cập trong

chữ hoa Bảng dưới đây liệt kê tất cả các method được hỗ trợ trong HTTP/1.1

GET được sử dụng để lấy lại thông tin từ Server đã cung cấp bởi sử

dụng một URI đã cung cấp Các yêu cầu sử dụng GET nên chỉ nhận

dữ liệu và nên không có ảnh hưởng gì tới dữ liệu

2 HEAD

Tương tự như GET, nhưng nó truyền tải dòng trạng thái và khu vực

Header

Một yêu cầu POST được sử dụng để gửi dữ liệu tới Server, ví dụ,

thông tin khách hàng, file tải lên, …, bởi sử dụng các mẫu HTML

Thay đổi tất cả các đại diện hiện tại của nguồn mục tiêu với nội dung

được tải lên

STT Phương thức và Miêu tả

1 Một dấu * được sử dụng khi một yêu cầu HTTP không áp dụng tới một nguồn

cụ thể, nhưng tới chính Server đó, và chỉ được cho phép khi phương thức

được sử dụng không cần thiết áp dụng tới một nguồn Ví dụ:

OPTIONS * HTTP/1.1

sự ủy nhiệm Sự ủy nhiệm được yêu cầu chuyển tới yêu cầu hoạc dịch vụ từ

một cache hiệu lực, và trả lại phản hồi Ví dụ:

GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.1

3 Mẫu phổ biến nhất của Request-URI được sử dụng để xác định một nguồn

trên một Server hoặc gateway ban đầu Ví dụ, một Client mong muốn lấy

được một nguồn một cách trực tiếp từ Server ban đầu sẽ tạo một kết nối

TCP tới port 80 của host www.w3.org và gửi các dòng sau:

GET /pub/WWW/TheProject.html HTTP/1.1

Host: www.w3.org

Ghi chú rằng, đường truyền tuyệt đối không thể là trống rỗng; nếu

không gì được trình bày trong URI ban đầu, nó Phải được cung cấp

như là “/” (Server root)

Các trường Header Yêu cầu

Chúng ta sẽ học General-Header và Entity-Header trong một chương riêng khi chúng ta sẽ học

về các trường Header Bây giờ, chúng ta xem các trường Header yêu cầu là gì:

Các trường Request-Header cho phép Client truyền thông tin thêm về yêu cầu, và về chính Client đó, tới Server Những trường này hoạt động như các bộ chỉnh sửa yêu cầu Dưới đây là một danh sách các trường Request-Header quan trọng mà có thể được sử dụng dựa trên sự yêu cầu:

 Accept-Charset

 Accept-Encoding

 Accept-Language

Các ví dụ của Thông báo Yêu cầu

Bây giờ chúng ta đặt tất cả những thứ đã học ở trên cùng với nhau để tạo một yêu cầu HTTP

để chỉ thị trang hello.htm từ Server chạy trên anonymousvn.org

Tại đây chúng ta không gửi bất cứ yêu cầu dữ liệu tới Server bởi vì chúng ta đang chỉ thị một trang thuần HTML từ Server Kết nối là General-Header, và phần còn lại của Header là các Header yêu cầu Ví dụ sau đây chỉ cách để gửi dữ liệu mẫu tới Server bởi sử dụng phần thân thông báo yêu cầu:

Ở đây, URl được cung cấp /cgi-bin/process.cgi sẽ được sử dụng để xử lý dữ liệu được truyền

và theo đó, một phản hồi sẽ được trả lại Ở đây content-type nói cho Server rằng dữ liệu được truyền là một dữ liệu mẫu web đơn giản và length sẽ là độ dài thực của dự liệu đặt trong phần

thân thông báo Ví dụ sau chỉ cách bạn có thể truyền XML thuần tới Server của bạn

Phản hồi (Response) trong HTTP

Sau khi nhận và phiên dịch một thông báo yêu cầu, một Server gửi tín hiệu phản hồi với một thông báo phản hồi HTTP

 Một dòng trạng thái (Status-Line)

 Không hoặc nhiều hơn các trường Header (General|Response|Entity) được theo sau bởi CRLF

 Một dòng trống (ví dụ: một dòng mà không có gì đằng trước CRLF) chỉ phần kết thúc của các trường Header



 Một phần thân thông báo tùy ý

Các khu vực dưới đây giải thích cách sử dụng của mỗi đối tượng trong một thông báo phản hồi HTTP

Dòng trạng thái

Một dòng trạng thái bao gồm phiên bản giao thức được theo sau bởi một mã hóa trạng thái số

và cụm từ thuần văn bản được liên kết của nó

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

Nó nghĩa là hoạt động phải được thực hiện để hoàn thành yêu cầu

đã được cung cấp trong một chương riêng biệt cho bạn tham khảo

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

Chúng ta sẽ học General-Header và Entity-Header trong một chương riêng biệt khi chúng ta sẽ học về các trường Header Bây giờ, chúng ta tìm hiểu xem các trường Header phản hồi là gì: Các trường Header phản hồi cho phép Server truyền thông tin thêm về phản hồi mà không thể được đặt trong dòng Status-Line Những trường Header này cung cấp thông tin về Server và về truy cập từ xa tới nguồn được xác định bởi Request-URI

 Accept-Ranges

 ETag

Các ví dụ về Thông báo Phản hồi

Bây giờ chúng ta đặt tất cả các thứ trên cùng với nhau để tạo một phản hồi HTTP cho một yêu cầu để chỉ thị trang hello.jsp từ Server đang chạy trên anonymousvn.org

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

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">

Date: Sun, 18 Oct 2012 10:36:20 GMT

Server: Apache/2.2.14 (Win32)

<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>

Phương thức trong HTTP

Tập hợp các phương thức phổ biến cho HTTP/1.1 được xác định bên dưới và bộ thiết lập này

có thể được mở rộng dựa trên các sự yêu cầu Những tên method này là case-sensitive và chúng phải được sử dụng trong dạng chữ hoa

STT Phương thức và miêu tả

GET được sử dụng để lấy lại thông tin từ Server đã cung cấp bởi sử

dụng một URI đã cung cấp Các yêu cầu sử dụng GET nên chỉ nhận

dữ liệu và nên không có ảnh hưởng gì tới dữ liệu

Tương tự như GET, nhưng nó truyền tải dòng trạng thái và khu vực

Header

Một yêu cầu POST được sử dụng để gửi dữ liệu tới Server, ví dụ,

thông tin khách hàng, file tải lên, …, bởi sử dụng các mẫu HTML

Thay đổi tất cả các đại diện hiện tại của nguồn mục tiêu với nội dung

được tải lên

Phương thức GET

Một yêu cầu GET lấy dữ liệu từ một Server bởi việc xác định các tham số trong đoạn URL của

yêu cầu Đây là phương thức chính được sử dụng để thu hồi tài liệu Ví dụ sau chỉ cách sử

dụng của phương thức GET để chỉ thị hello.htm:

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

Phương thức HEAD là có chức năng tương tự như GET, ngoại trừ là Server phản hồi với một

dòng và các Header phản hồi, nhưng không có phần thân đối tượng Ví dụ sau chỉ cách sử

dụng của phương thức HEAD để chỉ thị thông tin Header vềhello.htm:

Connection: Keep-Alive

Server phản hồi lại yêu cầu HEAD trên như 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

Phương thức POST được sử dụng khi bạn muốn gửi một vài dữ liệu tới Server, ví dụ, cập

nhật file, dữ liệu mẫu, … Ví dụ sau đây chỉ cách sử dụng của phương thức POST để gửi một

dữ liệu mẫu tới Server, mà sẽ được xử lý bởi một process.cgi và cuối cùng một phản hồi sẽ

<? xml version = "1.0" encoding = "utf-8" ?>

<string xmlns = "http://clearforest.com/" > string </string>

Bên Server, scipt process.cgi xử lý dữ liệu đã truyền và gửi phản hồi như 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

Phương thức PUT được sử dụng để yêu cầu Server để lưu giữ phần thân đối tượng được bao

gồm tại một vị trí được xác định bởi URL đã cung cấp Ví dụ sau yêu cầu Server lưu phần thân

đối tượng đã cung cấp trong hello.htm tại root của Server:

Date: Mon, 27 Jul 2009 12:28:53 GMT

Server: Apache/2.2.14 (Win32)

Phương thức DELETE

Phương thức DELETE được sử dụng để yêu cầu Server để xóa một file tại vị trí được xác

định bởi URL đã cung cấp Ví dụ sau yêu cầu Server xóa tệp đã cho hello.htm tại root của Server:

Date: Mon, 27 Jul 2009 12:28:53 GMT

Server: Apache/2.2.14 (Win32)

Phương thức CONNECT được sử dụng bởi Client để thành lập một kết nối mạng tới Server

qua HTTP Ví dụ sau yêu cầu một kết nối với một Server đang chạy trên host

anonymousvn.org:

CONNECT www.anonymousvn.org HTTP/1.1

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

Kết nối được thành lập với Server và phản hồi sau được gửi trả lại tới Client:

HTTP/1.1 200 Connection established

Date: Mon, 27 Jul 2009 12:28:53 GMT

Server: Apache/2.2.14 (Win32)

Phương thức OPTIONS

Phương thức OPTIONS được sử dụng bởi Client để tìm ra các phương thức HTTP và các

chức năng được hỗ trợ bởi một Server Client có thể xác định một URL với phương thức OPTIONS hoặc một dấu * để hướng tới toàn bộ Server Ví dụ sau yêu cầu một danh sách các phương thức được hỗ trợ bởi một Server đang chạy trên anonymousvn.org:

OPTIONS * HTTP/1.1

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

Server sẽ gửi một thông tin dựa trên định cấu hình hiện tại của Server, 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 thức TRACE

Phương thức TRACE được sử dụng để ánh xạ các nội dung của một yêu cầu HTTP tới người

yêu cầu mà có thể được sử dụng cho mục đích debug tại thời điểm của sự phát triển Ví dụ sau chỉ cách sử dụng của phương thức TRACE:

TRACE / HTTP/1.1

Host: www.anonymousvn.org

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

Server sẽ gửi thông báo sau trong phản hồi tới 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)

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

Mã hóa trạng thái trong HTTP

Yếu tố Status-Code là một số nguyên 3 ký tự, trong đó ký tự đầu tiên của mã hóa trạng thái định nghĩa hạng (loại) phản hồi và hai ký tự cuối không có bất cứ vai trò phân loại nào Có 5 giá trị của ký tự đầu tiên:

Nó nghĩa là hoạt động phải được thực hiện để hoàn thành yêu cầu

1xx: Thông tin

100 Continue Chỉ một phần của yêu cầu được nhận bởi Server, nhưng miễn là

nó không bị loại bỏ, Client nên tiếp tục với yêu cầu

101 Switching

Protocols

Server chuyển đổi giao thức

2xx: Thành công

201 Created Yêu cầu là hoàn thành, và một nguồn mới được tạo

202 Accepted Yêu cầu được chấp nhận cho xử lý, nhưng việc xử lý chưa hoàn

204 No Content Một mã trạng thái và một Header được cung cấp trong phản hồi,

nhưng không có phần thân đối tượng trong sự phản hồi

Server đang trả lại dữ liệu cục bộ của kích cỡ được yêu cầu

Được sử dụng trong phản hồi tới một yêu cầu xác định một Range Header Server phải xác định dãy được bao gồm trong phản hồi với Content-Range header

3xx: Sự điều hướng lại

300 Multiple

Choices

Một danh sách các link Người sử dụng có thể chọn một link và tới vị trí đó Tối đa 5 địa chỉ

301 Moved

Permanently

Trang được yêu cầu đã di chuyển tới một URL mới

302 Found Trang được yêu cầu đã di chuyển tạm thời tới một URL mới

303 See Other Trang được yêu cầu có thể được tìm ở dưới một URL khác

304 Not Modified Đây là mã phản hồi tới một If-Modified-Since hoặc

If-None-Match header, nơi mà URL không được chỉnh sửa từ ngày cụ thể

305 Use Proxy URL được yêu cầu phải được truy cập thông qua một sự ủy

quyền được đề cập trong Location Header

306 Unused Mã này được sử dụng trong một phiên bản trước Nó không còn

được sử dụng nữa, nhưng mã này được lưu giữ

307 Temporary

Redirect

Trang được yêu cầu đã di chuyển tạm thời tới một URL mới

4xx: L ỗi Client

400 Bad Request Server không hiểu yêu cầu

401 Unauthorized Trang được yêu cầu cần một tên sử dụng và một mật

khẩu

402 Payment

Required

Bạn không thể sử dụng mã này nữa

403 Forbidden Sự truy cập tới trang được yêu cầu bị cấm

404 Not Found Server không thể tìm thấy trang được yêu cầu

409 Conflict Yêu cầu không thể được hoàn thành bởi vì sự xung đột.

410 Gone Trang được yêu cầu không có sẵn nữa

411 Length Required Content-Length không được xác định rõ Server sẽ không

chấp nhận yêu cầu mà không có nó

Server sẽ không chấp nhận yêu cầu, bởi vì URL là quá dài

Xảy ra khi bạn chuyển một yêu cầu “port” tới một yêu cầu

“get” với thông tin quá dài

Range Not Satisfiable

Dãy byte được yêu cầu là không có sẵn và bên ngoài giới hạn

501 Not Implemented Yêu cầu không được hoàn thành Server không hỗ trợ

tính năng được yêu cầu

502 Bad Gateway Yêu cầu không được hoàn thành Server nhận một phản

hồi không có hiệu lực từ Server ở thượng nguồn

Server không hỗ trợ phiên bản “giao thức HTTP”

Các trường Header trong HTTP

Các trường Header cung cấp thông tin được yêu cầu về yêu cầu hoặc phản hồi, hoặc về đối tượng được gửi trong phần thân thông báo Có 4 kiểu của Header thông báo HTTP:

 Kiểu chung (General-Header): Các trường Header này có khả năng ứng dụng chung

cho cả các thông báo yêu cầu và phản hồi

 Kiểu yêu cầu (Request-Header): Các trường Header này có khả năng ứng dụng chỉ

cho các thông báo yêu cầu

 Kiểu phản hồi (Response-Header): Các trường Header này chỉ có khả năng áp dụng

cho các thông báo phản hồi

 Kiểu thực thể (Entity-Header): Các trường này xác định thông tin về thân-thực thể

hoặc, nếu không có phần thân nào hiển thị, về nguồn được nhận diện bởi yêu cầu

General Header

Trường Cache-Control

Trường Header chung Cache-Control được sử dụng để xác định các chỉ dẫn mà PHẢIđược

tuân theo bởi tất cả các hệ thống bộ nhớ ẩn Cú pháp như sau:

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

Một Client hoặc Server có thể sử dụng Header chung Cache-Control để xác định các tham số

cho bộ nhớ ẩn hoặc yêu cầu các loại cụ thể của tài liệu từ bộ nhớ ẩn Các chỉ dẫn bộ nhớ ẩn được xác định trong một danh sách được phân biệt bởi dấu phảy Ví dụ:

Cache-control: no-cache

Bảng dưới liệt kê các chỉ dẫn yêu cầu bộ nhớ ẩn quan trọng mà có thể được sử dụng

bởi Client trong yêu cầu HTTP của nó:

Một bộ nhớ ẩn phải không sử dụng phản hồi để làm thỏa mãn một

yêu cầu theo sau mà không tái xác nhận thành công với Server ban

Chỉ ra rằng Client đang muốn chấp nhận một phản hồi mà thời gian

của nó không lớn hơn thời gian đã xác định bằng giây (s)

Chỉ ra rằng Client đang muốn chấp nhận một phản hồi mà đã vượt

thời gian mãn hạn Nếu số giây được cung cấp, nó phải không là hết

hạn bởi nhiều hơn thời gian đó

Chỉ ra rằng Client đang muốn chấp nhận một phản hồi mà thời gian

sống khỏe của nó là không ít hơn tuổi hiện tại của nó cộng với thời

gian đã xác định bằng giây

Không chuyển đổi phần thân đối tượng

Không lấy dữ liệu mới Bộ nhớ ẩn có thể gửi một tài liệu chỉ khi nó ở

trong bộ nhớ ẩn, và không nên liên hệ với Server ban đầu để xem xét

nếu một bản sao mới hơn tồn tại

Các chỉ dẫn phản hồi bộ nhớ ẩn quan trọng sau đây có thể được sử dụng bởi Servertrong

Chỉ ra rằng tất cả hoặc một phần của thông báo phản hồi được xem

như là cho một người sử dụng đơn và phải không được giữ trong bộ

nhớ ẩn bởi một bộ nhớ ẩn được chia sẻ

Một bộ nhớ ẩn phải không sử dụng phản hồi để thỏa mãn một yêu

cầu theo sau mà không tái xác nhận thành công với Server ban đầu

Bộ nhớ ẩn phải xác minh trạng thái của các tài liệu đã cũ trước khi sử

dụng nó và các tài liệu đã mãn hạn không nên được sử dụng

Chỉ dẫn tái xác nhận ủy quyền có cùng ý nghĩa với chỉ dẫn

must-revalidate, ngoại trừ nó không áp dụng tới các bộ nhớ ẩn user agent

không được chia sẻ

Chỉ ra rằng Client đang muốn chấp nhận một yêu cầu mà tuổi của nó

không lớn hơn thời gian đã xác định bằng giây

Tuổi tối đa được xác định bởi chỉ dẫn này vượt quá tuổi tối đa đã xác

định bởi hoặc chỉ dẫn max-age hoặc Expires Header Chỉ dẫn

s-maxage luôn luôn được bỏ qua bởi một bộ nhớ cá nhân

Trường Connection

Trường Header chung Connection cho phép người gửi xác định các chức năng mà được

mong ước cho kết nối cụ thể đó và phải không được giao tiếp bởi các trạm ủy nhiệm qua các kết nối xa hơn Dưới đây là cú pháp đơn giản cho sử dụng Connection Header:

Connection : "Connection"

HTTP/1.1 xác định rõ chức năng kết nối “close” cho người gửi tới tín hiệu mà kết nối sẽ được

đóng sau khi hoàn thành phản hồi Ví dụ:

Connection: close

Theo mặc định, HTTP 1.1 sử dụng các kết nối liên tục, nơi mà kết nối không tự động đóng sau khi hoàn thành một giao dịch Trong khi đó, HTTP 1.0 không có các kết nối liên tục theo mặc định Nếu một Client 1.0 mong muốn sử dụng các kết nối liên tục, nó sử dụng các tham

số keep-alvie như sau:

Connection: keep-alive

Trường Date

Tất cả các nhãn Ngày/Thời gian PHẢI được biểu diễn trong GMT, không có trường hợp ngoại

trừ Các ứng dụng HTTP được cho phép được sử dụng bất kỳ 3 sự biểu diễn nhãn Ngày/Thời gian nào sau đâ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, định dạng đầu tiên là được sử dụng nhiều nhất

Trường Pragma

Trường Pragma được sử dụng để bao gồm các chỉ dẫn cụ thể để thực hiện mà có thể áp dụng

tới 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ỉ dẫn chỉ xác định rõ trong HTTP/1.0 là chỉ dẫn không bộ nhớ ẩn và được duy trì trong HTTP/1.1 cho tính tương thích ngược về sau Không có các chỉ dẫn Pragma mới sẽ được định nghĩa trong tương lai

Trường Trailer

Giá trị trường Trailer chỉ ra rằng thiết lập đã cho của các trường Header biểu diễn trong trailer

của một thông báo được mã hóa với mã hóa truyển tải được đóng khối Dưới đây là cú pháp của trường Trailer:

Trailer : field-name

Các trường Header thông báo được liệt kê trong trường Trailer phải không bao gồm các trường Header sau:

 Transfer-Encoding

 Content-Length

 Trailer

Trường Transfer-Encoding (Mã hóa truyền tải)

Trường Transfer-Encoding này chỉ ra kiểu truyền tải nào được áp dụng tới phần thân thông báo

để cho việc truyền tải 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

như Content-encoding bởi vì các mã hóa truyền tải là một thuộc tính của thông báo, không

phải là của phần thân thông báo Cú pháp của trường Transfer-Encoding là như sau:

Transfer-Encoding: chunked

Tất cả các giá trị Transfer-Encoding là không nhạy cảm (không phân biệt hoa-thường)

Trường Upgrade

Trường Upgrade này cho phép Client xác định những giao thức giao tiếp thêm vào mà nó hỗ

trợ và sẽ được sử dụng nếu Server tìm thấy rằng nó thích hợp để chuyển đổi giao thức Ví dụ:

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

Trường Upgrade được chờ đợi để cung cấp một kỹ thuật đơn giản cho truyền tải từ HTTP/1.1 tới một số giao thức không tương hợp

Trường Via

Trường Via phải được sử dụng bởi các gateway và các trạm ủy nhiệm để chỉ ra 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 HTTP/1.0 User agent tới một trạm ủy nhiệm nội bộ được đặt tên mã “fred”, mà sử dụng HTTP/1.1 để chuyển tiếp yêu cầu tới một trạm ủy nhiệm công cộng tại nowhere.com, mà hoàn thành yêu cầu bởi việc chuyển tiếp nó tới Server ban đầu tại www.ics.uci.edu Yêu cầu được nhận bởi www.ics.uci.edu sẽ có trường Via như sau:

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

Trường Warning (Cảnh báo)

Trường Warning được sử dụng để mang thông tin thêm về trạng thái hoặc sự truyền tải của

một thông báo mà có thể không được phản ánh trong thông báo đó Một sự phản hồi có thể mang nhiều hơn một trường Warning

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