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

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

Message flow

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

2

- 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

3

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

3-3 để 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

4

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

5

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

6

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

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ể

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

8

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

9

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

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

10

- 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

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

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

- 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

3-8 cho thấy hoạt động của method HEAD

PUT

13

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

14

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

15

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

16

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