Tất cả về HTTP message (Tài liệu được dịch từ cuốn sách: http_the_definitive_guide)

Người dịch: Nguyễn Trường Hận

HTTP message
Tài liệu được dịch từ cuốn sách: http_the_definitive_guide

Chương 3:

HTTP MESSAGE

Nếu HTTP là người đưa tin internet, HTTP message là gói tin mà nó sử dụng để
chuyển thông tin xung quanh. Ở chapter 1, chúng ta đã tìm hiểu về chương trình HTTP
gửi mỗi message như thế nào. Chapter này nói cho bạn biết tất cả về HTTP message,
cách tạo ra chúng và hiểu chúng như thế nào. Sau khi đọc chapter này, bạn sẽ biết hầu
hết những gì cần để biết viết một ứng dụng HTTP của bạn. Cụ thể, bạn sẽ hiểu:
Message flow
-

3 phần của HTTP message (start line, header, entity body)
1


Người dịch: Nguyễn Trường Hận

-

Sự khác nhau giữa request message và response message.

-

Các funtion khác nhau hỗ trợ request message

-

Các codes status khác nhau được trả về trong respone message.

-

Ý nghĩa các HTTP header khác nhau

3.1. The flow of message.
HTTP message là một khối data được gửi bởi ứng dụng HTTP. Những khối data
này bắt đầu với một chuỗi text gọi là meta-information, chuỗi này mô tả nội dung của
message và ý nghĩa, kèm với data (không bắt buộc). Những message lưu thông giữa
clients, server, và proxies. Những điều kiện như “inbound” , “outbound” “upstream” và
“downstream” mô tả hướng đi của message .
Con đường của message trong mạng nội bộ tới server.
HTTP sử dụng điều kiện inbound và outbound để mô tả hướng đi của giao dịch
(transactional). Message di chuyển trong mạng nội bộ tới server và khi chúng làm việc
xong, chúng di chuyển ra bên ngoài trở lại user agent.

Messages flow downstream
HTTP message chảy như dòng sông. Tất cả các message chạy xuống hạ lưu, bất
kể chúng là request message hay response message. Nơi gửi bất kỳ của message là
thượng nguồn của nơi nhận. Như trong hình 3-2, proxy 1 là thượng nguồn của proxy 3
với request message nhưng là hạ lưu của proxy 3 với response message.

2


Người dịch: Nguyễn Trường Hận

3.2. Thành phần của message
HTTP message có cấu trúc đơn giản, được định dạng của khối data. Xem hình 33 để hình dung. Mỗi message bao gồm một request từ client hoặc 1 response từ server.
Chúng gồm 3 phần là 1 startline mô tả message, một khối của headers bao gồm thuộc
tính và phần body không bắt buộc chứa data.
Starline và header là văn bản ASCII trình bày ở dạng dòng. Mỗi dòng kết thúc với
1 cụm 2 ký tự, bao gồm một carriage return (ASCII 13) và một kí tự line-feed (ASCII
10). Kí tự kết thúc dòng này được viết tắt là “CRLF”. Nó là giá trị được chỉ ra trong đặc
tả HTTP cho kí tự kết thúc dòng là CRLF, ứng dụng mạnh mẽ còn nên chấp nhận chỉ
một kí tự line-feed. Một vài ứng dụng HTTP cũ hoặc bị hỏng không luôn luôn gửi cả
carriage return và line feed.
Phần body (message body) này có thể có dữ liệu hoặc không. Không giống như
startline và header, body có thể chứa dữ liệu dạng text hoặc binary hoặc để trống.
Ở ví dụ trong hình 3-3, header đưa cho bạn một vài thông tin về body. Dòng
content-type chỉ ra rằng dạng dữ liệu chứa trong body là text, nó là một plain-text
document. Dòng Content-Length chỉ ra cho bạn biết rằng kích thước của body, trong ví
dụ là 19byte.

3


Người dịch: Nguyễn Trường Hận

Message Syntax (Cú pháp message)
Tất cả HTTP message rơi vào 2 loại: request message và response message.
Request message là massage yêu cầu một hành động từ server. Response message mang
kết quả của request quay trở về client. Cả request và response message đều có một cấu
trúc đơn giản giống nhau. Trong hình 3-4 chỉ ra rằng request và response message lấy
một gif.
Dưới đây là định dạng cho một request message:

Dưới đây là định dạng của response messsage (chú ý rằng cú pháp chỉ khác nhau
ở dòng bắt đầu):

4


Người dịch: Nguyễn Trường Hận

Dưới đây là mô tả nhanh về các giá trị:
-

Method: Hành động mà client muốn server thực hiện trên tài nguyên của server.
Nó là một từ đơn như “GET”, “HEAD” hoặc “POST”.

-

Request-URL: Một URL hoàn chỉnh đặt tên cho tài nguyên được request hoặc
thành phần đường dẫn của URL. Nếu bạn đang giao tiếp với server, thành phần
đường dẫn của URL thường xuyên được chấp nhận miễn nó là đường dẫn tuyệt
đối tới tài nguyên, server có thể giả định mình như host/port của URL.

-

Version: Mô tả phiên bản của HTTP mà message sử dụng, nó có định dạng như:
Major và minor là số nguyên.

-

Status-code: Một cụm 3 số mô tả những gì xảy ra suốt quá trình request. Số đầu
tiên của mỗi code mô tả chung lớp của status (“success”, “error”, …). Một danh

sách đầy đủ của status code được xác định trong đặc tả HTTP.

-

Reason-phrase: Một bản cho phép đọc của status code, bao gồm tất cả text cho đến
khi gặp kí tự kết thúc dòng. Danh sách reason-phrase cho tất cả status code xác
định trong đặc tả của HTTP. Reason phrase có nghĩa là chỉ dành cho con người, vì
vậy, ví dụ 2 response line “HTTP/1.0 200 NOT OK” và “HTTP/1.0 200 OK”
nên được coi như tương đương chỉ dẫn thành công, mặc dù reason phrase mang ý
nghĩa khác nhau.

-

Header: 0 hoặc nhiều header, mỗi trong số chúng là một tên theo sau bởi dấu 2
chấm cùng với khoảng trắng: theo sau là giá trị. Header kết thúc bằng 1 CRLF
đánh dấu sự kết thúc của header và sự bắt đầu của trường body. Một vài phiên bản
của HTTP như HTTP/1.1 yêu cầu một số header nhất định được trình bày cho
request hoặc response message hợp lệ.

-

Entity-body: Entity body bao gồm một khối dữ liệu tùy ý, không phải tất cả các
message đều chứa entity body, vì vậy thỉnh thoảng một message kết thúc với một
1 CRLF.

5


Người dịch: Nguyễn Trường Hận

Chú ý rằng một tập hợp các tiêu đề HTTP nên luôn luôn được kết thúc bằng 1
CRLF, dù cho không có header hay không có body. Tuy nhiên nhiều client và server bỏ
qua CRLF cuối cùng nếu không có entity boby. Để tương thích với điều này, client và
server nên chấp nhận message kết thúc mà không có CRLF.
Start lines
Tất cả HTTP message đều bắt đầu với một start line. Start line của request message
cho biết “làm gì” và start line của response message cho biết “diễn ra gì?”
3.2.2.1 Request line
Request message yêu cầu server làm điều gì đó với một tài nguyên. Start line của
một request message gọi là request line bao gồm một phương thức mô tả những hoạt
động server nên thực hiện và một request URL mô tả tài nguyên mà trên đó thực hiện
một phương thức. Request line còn bao gồm một HTTP version nói cho server biết phiên
bản của HTTP mà client sử dụng.
Tất cả các trường được phân chia bởi khoảng trắng. Trong hình 3-5a, phương thức
request là GET, request URL là /test/hi-there.txt và version là HTTP/1.1.
3.2.2.2 Response line
Response message mang thông tin status và bất kì dữ liệu kết quả từ server trả cho
client. Start line trong response message gọi là response line bao gồm HTTP version mà
response message đang sử dụng, một status code và một reason phrase mô tả trạng thái
của hoạt động.
Tất cả các trường được phân tách bằng khoảng trắng, ở hình 3-5b, HTTP version
là HTTP/1.0, status code là 200, và reason phrase là OK, có nghĩa là document được trả
về thành công. Các phiên bản trước phiên bản HTTP/1.0, response không cần phải bao
gồm response line.
3.2.2.3 Method
Dòng method bắt đầu tại startline của request message, nói cho server biết nó cần
làm gì, ví dụ tại dòng “GET/ /specials/saw-blade.gif HTTP/1.0,” thì method là GET.
Đặc tả của HTTP có định nghĩa một tập các method. Ví dụ method GET dùng để
lấy về một document từ server, method POST dùng để gửi data từ một server tới tiến
trình và method OPTIONS xác định khả năng chung của web server hoặc khả năng của

web server cho một tài nguyên cụ thể.
6


Người dịch: Nguyễn Trường Hận

Bảng 3-1 mô tả method. Chú ý rằng một vài method có một body trong request
message và những method còn lại thì không có.

Không phải tất cả các server đều thực hiện tất cả bảy method trong bảng 3-1. Hơn
nữa, vì HTTP được thiết kế để dễ dàng mở rộng, các server khác có thể thực hiện các
method yêu cầu riêng của nó ngoài các method này. Các method bổ sung này được gọi
là các method mở rộng, vì chúng nằm ngoài đặc tả HTTP.
3.2.2.4 Status code
Status code nói cho client biết điều gì đã xảy ra. Status code nằm tại start line của
response message. Ví dụ, tại dòng “HTTP/1.0 200 OK”, status code là 200
Khi client gửi request message tới HTTP server, nhiều điều có thể xảy ra. Nếu bạn
may mắn, request sẽ thành công. Nhưng không phải lúc nào bạn cũng may mắn như vậy.
Server có thể nói cho bạn biết rằng tài nguyên mà bạn request không thể tìm thấy, hoặc
bạn không có quyền truy cập tới tài nguyên đó, hoặc có thể một phần của tài nguyên đã
bị di chuyển tới nơi khác.
Status code được trả về trong start line của mỗi response message. Cả một số và
một status con người có thể đọc được được trả về cho client. Số code làm cho việc xử lí
lỗi dễ dàng đối với chương trình máy tính. Trong khi reason phrase hiển thị rất dễ hiểu
đối với con người.
Những status code khác nhau được gom thành các lớp khác nhau dựa theo mã số
gồm 3 chữ số của chúng. Status nằm trong khoảng 200 đến 299 đại diện cho giao dịch
thành công. Status code nằm trong khoảng 300 đến 399 biểu thị rằng tài nguyên đã bị di
chuyển. status code nằm trong khoảng 400 đến 499 có nghĩa là client đã làm gì đó sai
trong request. Status code nằm trong khoảng 500 đến 599 có nghĩa là có điều gì đó

không đúng ở server.

7


Người dịch: Nguyễn Trường Hận

Phiên bản hiện tại của HTTP định nghĩa không chỉ một vài code cho mỗi loại
status. Như những protocol phát triển sau này, nhiều status code hơn sẽ được định
nghĩa chính thức trong đặc tả HTTP. Nếu bạn nhận một status code mà bạn không
nhận ra nó, có thể rằng một ai đó đã định nghĩa nó như một giá trị mở rộng cho
protocol hiện tại. Bạn nên coi nó như là một thành viên chung của class mà nó rơi vào.
Ví dụ, Nếu bạn nhận được status code 515 (Giá trị này nằm ngoài những giá trị
status code đã được định nghĩa trong class 5XX được liệt kê trong bảng 3-2.), bạn nên
coi thông tin response này chỉ ra 1 lỗi ở server, status code này chung class với 5XX.
Bảng 3-3 liệt kê một vài giá trị status code thông dụng nhất mà bạn có thể gặp.
Chúng ta sẽ giải thích tất cả status code hiện tại của HTTP trong đoạn sau của chapter
này.

3.2.2.5 Reason phrase
Reason phrase là thành phần cuối cùng của start line trong response message. Nó
cung cấp một diễn giải bằng text của status code. Ví dụ, trong dòng “HTTP/1.0 200
OK: reason phrase là OK.
Reason phrase được ghép nối một một với status code. Reason phrase cung cấp
một dạng đọc được của status code mà nhà phát triển ứng dụng có thể chuyển đến
client cho biết điều gì đã xảy ra trong quá trình request.
Đặc tả của HTTP không cung cấp bất kì luật cứng và nhanh nào cho reson phrase
nên trông như thế nào. Đoạn sau của chapter này , chúng ta sẽ liệt kê status code và
một vài gợi ý cho reason phrases.
8

Người dịch: Nguyễn Trường Hận

3.2.2.6 Version numbers
Version number xuất hiện trong cả request và response message start line có
dạng là HTTP/x.y. Nó cung cấp một phương tiện cho các ứng dụng HTTP nói cho
nhau biết về version của protocol mà chúng sử dụng.
Version number được dự định cung cấp cho các ứng dụng nói HTTP với một đầu
mối về khả năng của nhau và định dạng của thông điệp. Một ứng dụng HTTP version
1.2 giao tiếp với một ứng dụng HTTP version 1.1 nên biết rắng nó không nên sử dụng
bất kì đặc điểm mới của version 1.2, vì chúng có khả năng không được chấp nhận bởi
những ứng dụng version cũ hơn.
Version number cho biết phiên bản cao nhất của HTTP mà ứng dụng hỗ trợ.
Trong một vài trường hợp điều này dẫn đến sự nhầm lẫn giữa các ứng dụng, bởi vì ứng
dụng HTTP/1.0 diễn dịch một response với HTTP/1.1 trong ứng dụng để chỉ ra rằng
response là một response 1.1, khi trong sự thật nó chỉ là level của protocol được sử
dụng bởi ứng dụng response.
Chú ý rằng version number không được hiểu như một số thập phân. Mỗi số trong
version number được hiểu là một số riêng lẻ. Vì vậy, khi so sánh HTTP version, mỗi
số phải được so sánh riêng để xác định cái nào là version cao hơn. Ví dụ, HTTP 2.22
thì cao hơn HTTP/2.3 bởi vì 22 > 3.
Headers
Phần trước tập trung tìm hiểu về dòng đầu tiên của request và response message.
Sau dòng đầu tiên đó là là các header được đánh số, 0,1,2,…
HTTP header bổ sung thêm thông tin cho request và response message. Chúng
đơn giản là danh sách những giá trị/tên. Ví dụ, theo sau header line chỉ định giá trị 19
cho trường header Content-Length:

3.2.3.1 Header classifications (Phân loại header)

Đặc tả HTTP định nghĩa một vài trường header. Các ứng dụng còn tự do việc tạo
ra thêm các header riêng của họ. HTTP header được phân thành các loại:
-

General headers: Có thể xuất hiện trong cả request và response message.
9


Người dịch: Nguyễn Trường Hận

-

Request headers: Cung cấp nhiều thông tin hơn về request

-

Response headers: Cung cấp nhiều thông tin hơn về response

-

Entity headers: Mô tả kích thước và độ dài của nội dung, hoặc tài nguyên của
chính nó.

-

Extension headers: Header mới được định nghĩa trong đặc tả.
Mỗi HTTP header có một cú pháp đơn giản: một tên theo sau bởi dấu 2 chấm,

theo sau là dấu khoảng trắng (có thể có hoặc không), theo sau nữa là trường giá trị,
theo sau nữa là CRLF (1 dấu xuống dòng). Bảng 3-4 liệt kê một vài header phổ biến.

3.2.3.2 Header continuation lines
Dòng header dài có thể được chia nhỏ ra thành nhiều dòng để dễ đọc hơn, mỗi
dòng cách nhau ít nhất 1 khoảng trắng hoặc một dấu tab.
Ví dụ:

Trong ví dụ này, response message gồm một server header mang giá trị được
chia thành nhiều dòng liên tục. Giá trị cuối cùng của header là “Test Server Version
1.0”
Chúng ta sẽ mô tả ngắn gọn tất cả các HTTP header sau chapter này. Chúng ta
còn cung cấp một tài liệu tham khảo chi tiết của tất cả các header trong Appendix C.
Entity Bodies
Phần thứ 3 của một HTTP message đó là phần entity body (không bắt buộc phải
có). Entity bodies là payload của HTTP message. Chúng là những thứ mà HTTP được
thiết kế để vận chuyển.
10


Người dịch: Nguyễn Trường Hận

HTTP message có thể mang theo nhiều loại dữ liệu số như hình ảnh, video,
HTML document, ứng dụng phần mềm, thông tin giao dịch thẻ tín dụng, mail điện tử,
…
3.3. Method
Hãy nói nhiều hơn, chi tiết hơn về các HTTP method cơ bản, đã liệt kê ở bảng 31. Chú ý rằng không phải tất cả method đều được thực hiện bởi mỗi server. Để tuân
thủ phiên bản HTTP 1.1, một server cần thực hiện không chỉ method GET mà còn
method HEAD cho tài nguyên của nó.
Ngay cả khi server thực hiện tất cả các method, method có nhiều khả năng nhất
nên sử dụng hạn chế. Ví dụ, server hỗ trợ method DELETE hoặc PUT sẽ không muốn
bất kì ai có thể xóa hoặc lưu tài nguyên. Những hạn chế này nói chung được cài đặt

trong cấu hình server, vì vậy chúng thay đổi từ site to site và từ server tới server.
Safe Methods
HTTP định nghĩa một tập những method được gọi là safe method. Method GET
và HEAD được gọi là safe method, có nghĩa là không hành động nào nên xảy ra trên
server , giống như kết quả của một HTTP request sử dụng method GET hoặc HEAD.
Bởi không có hành động, chúng có nghĩa rằng không có gì xảy ra trên server như
kết quả của HTTP request. Ví dụ, xem xét khi bạn đi shopping online tại Joe’s
Hardware và bạn click chuột vào button “submit purchase”, click vào button “submit”
với request POST cùng với thông tin credit card của bạn, và một hành động được diễn
ra trên server. Trong trường hợp này, hành động là credit card của bạn bị tính phí cho
giao dịch của bạn.
Không có gì đảm bảo rằng những method an toàn sẽ không gây ra một hành động
(trong thực tế, điều đó tùy thuộc vào nhà phát triển web). Safe method có nghĩa là cho
phép ứng dụng phát triển HTTP cho phép người dùng biết khi nào một method unsafe
có thể gây ra một vài hành động. ở trong ví dụ trên, trình duyệt web của bạn có thể
hiện lên một wanning message để cho bạn biết rằng bạn đã gửi 1 request với một
method unsafe và do đó, một vài điều có thể xảy ra trên server.
GET

11


Người dịch: Nguyễn Trường Hận

GET là method phổ biến nhất, nó thường xuyên được sử dụng để yêu cầu server
gửi một tài nguyên. HTTP/1.1 đòi hỏi server thực hiện method này. Trong hình 3-7 chỉ
ra một ví dụ của một client thực hiện một HTTp request với method GET.

HEAD
Method HEAD hoạt động giống với method GET, nhưng server chỉ trả về header

của response. Không có entity body nào được trả về. Điều này cho phép một client
kiểm tra header cho tài nguyên mà không cần thực sự phải có được tài nguyên đó. Sử
dụng HEAD, bạn có thể:
-

Tìm kiếm tài nguyên mà không cần phải lấy nó về

-

Biết đối tượng có tồn tại hay không dựa vào status code trong response
message.

-

Kiểm tra nếu tài nguyên đã được sửa đổi khi nhìn vào header.

Nhà phát triển server phải đảm bảo rằng header trả về là chính xác là nội dung
mà request GET trả về. Method HEAD cũng được đòi hỏi tuân thủ HTTP/1.1. Hình 38 cho thấy hoạt động của method HEAD.

PUT
12


Người dịch: Nguyễn Trường Hận

Method PUT ghi document vào server, ngược lại với method GET là đọc
document từ một server. Một vài hệ thống còn cho phép bạn tạo trang web và cài đặt
chúng trực tiếp trên một web server sử dụng method PUT.

Ý nghĩa của method PUT là cho server muốn lấy body của request và sử dụng nó

để tạo một document mới được gọi là request URL hoặc, nếu URL đó đã tồn tại rồi, sử
dụng body để thay thế vào nó.
Bởi vì PUT cho phép bạn thay đổi nội dung tài nguyên trên server nên nhiều web
server đòi hỏi bạn phải log in với password trước khi bạn có thể thực hiện một method
PUT. Bạn có thể đọc nhiều hơn về xác thực password ở chapter12.
POST
Method POST được thiết kế nhằm gửi data đầu vào tới server. Trong thực tế, nó
thường xuyên được sử dụng để hỗ trợ form HTML. Data lấy được từ việc điền vào
form thường được gửi tới server, sau đó so sánh dữ liệu này với nơi nó cần đến (tới
chương trình gateway của server, sau đó xử lí nó). Hình 3-10 chỉ ra một client thực
hiện một request HTTP gửi dữ liệu lấy được từ form tới server với method POST.

13


Người dịch: Nguyễn Trường Hận

TRACE
Khi một client gửi một request, request đó có thể đi thông qua tường lửa,
gateway hay một ứng dụng khác. Mỗi trong số chúng đều có cơ hội để chỉnh sửa
HTTP request ban đầu. Method trace cho phép client nhìn thấy những request như thế
nào khi nó được đưa đến server.
Trace request bắt đầu chẩn đoán một “loopback” tại server đích. Server tại nút
mạng cuối cùng của của đường đi trả về một trace response, với request massage chưa
dùng tới nó nhận được ở body của response của nó. Sau đó một client có thể xem như
thế nào hoặc nếu message ban đầu bị nén hoặc bị sửa đổi cùng với chuỗi
request/response của bất kỳ ứng dụng HTTP can thiệp nào.
Method TRACE được dùng chủ yếu cho việc chẩn đoán, … xác mình rằng
request đó đang đi thông qua chuỗi request/response như dự định. Nó còn là một công
cụ tốt để nhìn thấy những tác động của proxy và các ứng dụng khác trên request của

bạn.

14


Người dịch: Nguyễn Trường Hận

Tốt như TRACE dùng cho chẩn đoán, nó có nhược điểm của giả định là ứng
dụng can thiệp sẽ xử lý các loại request khác nhau (các method GET, HEAD, POST
…) là một. Nhiều ứng dụng HTTP thực hiện những điều khác nhau dựa trên method.
Ví dụ, một proxy có thể chuyển trực tiếp request POST tới server nhưng cố gắng để
gửi một request GET tới một ứng dụng HTPP khác (như một web cache). TRACE
không cung cấp một cơ chế để phân biệt các method. Nhìn chung, ứng dụng can thiệp
thực hiện được coi như là một tiến trình xử lí TRACE request.

Một message không có entity body có thể được gửi với TRACE request. Entity
body của TRACE response bao gồm nguyên văn request mà máy chủ phản hồi đã
nhận được.
OPTIONS
Method OPTIONS yêu cầu server nói với chúng ta về những khả năng khác nhau
được hỗ trợ bởi web server. Bạn có thể yêu cầu một server về những method gì nó hỗ
trợ chung hoặc cho một tài nguyên nào cụ thể (một vài server có thể hỗ trợ nhiều hoạt
động cụ thể chỉ trên các loại đối tượng cụ thể).
Điều này cung cấp một ý nghĩa cho ứng dụng client nhằm mục đích làm thế nào
tốt nhất để truy cập tới những tài nguyên khác nhau mà không cần thực sự phải truy
cập vào chúng. Hình 3-12 chỉ ra rằng một request sử dụng OPTIONS method.

15

Người dịch: Nguyễn Trường Hận

DELETE
Method DELETE yêu cầu server xóa một tài nguyên xác định nào đó bởi
request URL. Tuy nhiên, ứng dụng client không đảm bảo rằng lệnh xóa được thực
hiện. Điều này bởi vì đặc tả HTTP cho phép server ghi đè request mà không nói cho
client biết. Hình 3-13 chỉ ra một ví dụ của method DELETE.

Những method mở rộng
HTTP được thiết kế để có thể mở rộng các trường, vì vậy một tính năng mới sẽ không
gây ra ảnh hưởng xấu tới phần mềm cũ hơn. Những method mở rộng là method không
được định nghĩa trong đặc tả HTTP/1.1. Chúng cung cấp cho nhà phát triển một
phương tiện mở rộng khả năng của dịch vụ HTTP mà server của họ thực hiện trên các
tài nguyên mà server đó quản lí.
Một vài ví dụ phổ biến của method mở rộng được liệt kê trong bảng 3-5. Những
method này là một phần của mở rộng WEBDAV HTTP (sẽ được đề cập ở chapter 19)
hỗ trợ đẩy nội dung của web lên web server thông qua HTTP.

16


Người dịch: Nguyễn Trường Hận

Điều quan trọng là không phải tất cả các method mở rộng đươc định nghĩa trong một
đặc tả. Nếu bạn định nghĩa một method mở rộng, nó giống như không được hiểu bởi
hầu hết các ứng dụng HTTP. Tương tự như vậy, nó có thể rằng ứng dụng HTTP của
bạn có thể chạy các method mở rộng đang được sử dụng một ứng dụng khác mà nó
không hiểu được method đó.
Trong những trường hợp này, cách tốt nhất là những method mở rộng này nên được
cho phép. Proxies nên cố gắng chuyển tiếp những message với các method không biết

thông qua máy chủ nhận nếu chúng có khả năng thực hiện điều đó mà không vi phạm
quyền hạn từ đầu đến cuối. Nếu không thì chúng nên phản hồi với mã lỗi 501 Not
Implemented. Xử lí các method mở rộng được thực hiện tốt nhất bởi các luật cũ, “cần
phải thận trọng với những gì bạn gửi, tự do trong những gì bạn được cho phép”.
3.4. Status code
HTTP status code được phân thành 5 loại, như đã nhìn thấy trong bảng 3-2. Nội dung
này sẽ tóm tắt các HTTP status code cho mỗi loại.
Status code cung cấp một cách dễ dàng để client có thể hiểu được kết quả của quá
trình giao dịch giữa chúng với server. Trong nội dung này chúng ta còn liệt kê một vài
ví dụ của reason phrase.
100-199: Status code thông tin
HTTP/1.1 đã giới thiệu status code thông tin cho giao thức. Chúng tương đối mới và là
chủ đề chịu tranh cãi về sự phức tạp và giá trị mà nó mang lại. Bảng 3-6 liệt kê những
status code thông tin cụ thể.

17


Người dịch: Nguyễn Trường Hận

Mã code 100 gọi là Continue status code, đặc biệt gây nhầm lẫn. Nó nhằm tối ưu hóa
trong trường hợp một ứng dụng HTTP client có một entity body để gửi tới một server
nhưng muốn kiểm tra xem server sẽ có chấp nhận entity đó trước khi nó gửi không?.
Chúng ta thảo luận nó ở đây 1 cách chi tiết hơn ( Nó tương tác như thế nào với client,
server và proxies) bởi vì nó thường gây nhầm lẫn cho người viết chương trình HTTP.
3.4.1.1 Client and 1000 Continue
Nếu một client đang gửi một entity tới một server và đang sẵn sàng để đợi một
response với status code là 100 trước khi nó gửi entity. Client cần gửi một Expect
request header với giá trị 100-continue. Nếu client không đang gửi một entity, nó
không nên gửi một 100-continue Expect header, bởi vì điều này sẽ chỉ gây nhầm lẫn

cho server khi nghĩ rằng client có thể đang gửi một entity.
100-continue, trong nhiều cách hiểu, nó là một sự tối ưu hóa. Một ứng dụng client nên
thực sự dùng 100-continue chỉ để tránh đang gửi tới một server một entity lớn mà
server đó sẽ không thể xử lý và sử dụng.
Bởi vì ban đầu của sự nhầm lẫn xung quang status code 100-continue, client mà gửi
một Expect header không nên đợi mãi việc server gửi về một response với code 100continue. Sau một vài lần timeout, client chỉ nên gửi entity.
Trong thực tế, client còn nên được chuẩn bị đối phó với response 100 continue không
được mong đợi. Bởi vì một vài ứng dụng HTTP không đúng tiêu chuẩn gửi code này
một cách không thích đáng.
3.4.1.2 Server and 100 continue
Nếu một server nhận một request với Expect header và giá trị 100-continue, nó nên
phản hồi với response 100-continue hoặc một error code (trong bảng 3-9). Server
không bao giờ nên gửi một status code 100 continue tới client nếu client không gửi
100-continue tiếp theo, tuy nhiên có một số server sẽ không thực hiện như vậy.

18


Người dịch: Nguyễn Trường Hận

Nếu vì lý do nào đó mà server nhận được một vài (hoặc tất cả) của entity trước khi nó
đã có cơ hội gửi một phản hồi với status code 100-continue, nó không cần gửi status
code này, bởi vì client đã quyết định tiếp tục rồi. Khi server đã đọc xong request, tuy
nhiên nó vẫn cần gửi một status code cuối cùng cho request (nó có thể chỉ là status
100-continue).
Cuối cùng, nếu một server nhận được một request với status code là 100-continue và
nó quyết định kết thúc request trước khi nó đọc xong entity body, nó không nên chỉ
gửi một response và đóng kết nối, điều này có thể ngăn cản client nhận được response
(lỗi “TCP close and reset errors” sẽ được nói rõ hơn ở chapter 4).
3.4.1.3 Proxies and 100 Continue

Một proxy nhận được từ một client một request kèm với status code là 100-continue
cần làm một vài điều. Nếu proxy biết rằng server ở hop mạng tiếp theo sử dụng
HTTP/1.1 hoặc không biết server đó sử dụng HTTP version nào thì nó nên chuyển tiếp
request với Expect header trong request đó. Nếu nó biết server ở hop mạng tiếp theo
sử dụng HTTP version nhỏ hơn 1.1, nó nên response với status code là 417
Expectation Failed error.
Nếu một proxy quyết định gửi kèm với request một Expect header và status code 100continue thay cho client sử dụng HTTP version thấp hơn 1.1, nó không nên chuyển
tiếp response 100 continue (Nếu nó nhận được một response 100 continue từ server)
tới client, bởi vì client sẽ không biết phải làm gì với response đó).
200-299: Success Status Codes
Nếu client tạo một request, request đa phần đều thành công. Server có một dãy các
status code để biểu thị cho sự thành công của giao dịch, kết hợp chúng với những loại
request khác nhau. Bảng 3-7 liệt kê những dạng success status code.

19


Người dịch: Nguyễn Trường Hận

300-399: Redirection status codes
Redirection status codes nói cho client biết cách sử dụng một vị trí thay thế cho tài
nguyên mà nó quan tâm hoặc cung cấp một response thay thế cho nội dung. Nếu một
tài nguyên đã bị di chuyển, một redirection status code và một Location header không
bắt buộc có thể được gửi tới client và nói cho client biết rằng tài nguyên đó đã bị di
chuyển và vị trí mà tài nguyên đó có thể được tìm thấy. Điều này cho phép trình duyệt
đi tới vị trí mới của tài nguyên đó một cách rõ ràng mà không làm phiền tới người
dùng chúng.

20

Người dịch: Nguyễn Trường Hận

Một vài redirection status code có thể được sử dụng để xác minh bản sao một tài
nguyên cục bộ của một ứng dụng với server gốc. Ví dụ, một ứng dụng HTTP có thể
kiểm tra nếu bản sao tài nguyên cục bộ của nó vẫn cập nhật hoặc nếu tài nguyên đã
sửa đổi trên server gốc. Trong hình 3-15 chỉ ra một ví dụ của vấn đề này. Client gửi
một header đặc biệt If-Modified-Since, header này nói rằng lấy một document nào đó
chỉ nếu nó đã được chỉnh sửa từ năm 1997. Document không được thay đổi từ ngày
này, server replies với một status code 304 thay vì nội dung document được request.

21


Người dịch: Nguyễn Trường Hận

Nhìn chung, trong thực tế một response tốt cho các request no HEAD bao gômg một
redirection status code để chứa một entity với một mô tả và liên kết tới URL được
chuyển hướng. Bảng 3-8 liệt kê những redirection status code.

22


Người dịch: Nguyễn Trường Hận

Từ bảng 3-8, bạn có thể chú ý có một vài sự trùng lặp giữa các staus code 302, 303 và
307. Có một vài dòng nói về cách sử dụng những status code này, hầu hết chúng xuất
phát từ sự khác biệt trong cách mà các ứng dụng HTTP/1.0 và HTTP 1/1 xử lý các
status code này.
Khi một client sử dụng HTTP/1.0 gửi một request và nhận về một 302 redirect status

code trong response message, nó sẽ theo dõi URL redirect trong Location header với
message GET URL đó. (thay vì tạo một POST request như nó đã làm với request ban
đầu.
Server HTTP/1.0 chờ đợi client HTTP/1.1 thực hiện điều này khi một server HTTP/1.0
gửi một status code 302 sau khi nhận được một POST request từ một client HTTP 1.0,
server chờ đợi client này theo chuyển hướng của GET request để lấy được redirect
URL.
400-499: Client error Status codes
Thỉnh thoảng một client gửi một vài thứ cho một server nhưng server không thể xử lí,
ví dụ như một request message được tạo ta một cách rất tệ hoặc thường xuyên nhất là
một request một URL không tồn tài.
Chúng ta thấy rằng sẽ gặp lỗi 404 Not found thường xuyên xuất hiện trên trình duyệt,
điều này chỉ khi server nói với chúng ta rằng chúng ta đã request tới một tài nguyên
mà server không biết.
23


Người dịch: Nguyễn Trường Hận

Nhiều clỗi về client được xử lý với trình duyệt của bạn, mà không bao giờ làm phiền
bạn. Một vài status code giống như 404 có thể vẫn đi qua.

24


Người dịch: Nguyễn Trường Hận

500-599: Server error Status code
Thỉnh thoảng một client giử một request hợp lệ nhưng server chính nó gặp một lỗi.
Điều này có thể là do một client request tới một giới hạn của server hoặc một lỗi của

một trong các thành phần phụ của server.
Proxies thường xuyên gặp sự cố khi cố gắng nói cho server thay cho client. Vấn đề về
Proxy server status code 5XX sẽ mô tả các vấn đề.

25