Các sự ủy quyền và việc ghi vào bộ nhớ ẩn
Các sự ủy quyền HTTP là một Server trung gian, và tương ứng là các cơ hội về các nguy cơ tấn
công ở trung gian. Các ủy nhiệm có truy cập tới thông tin bảo mật liên quan, thông tin cá nhân về
từng người sử dụng và các tổ chức, và thông tin sở hữu riêng của người sử dụng và người cung
cấp nội dung đó.
Các nhà điều hành ủy nhiệm nên bảo về các hệ thống mà các ủy nhiệm chạy trên đó, vì họ sẽ bảo
vệ bất kỳ hệ thống nào mà chứa hoặc truyền tải thông tin nhạy cảm.
Việc ghi vào bộ nhớ ẩn các ủy nhiệm tạo ra thêm các lỗ hổng tiềm tàng, từ khi các nội dung của bộ
nhớ ẩn biểu diễn một mực tiêu hấp dẫn cho sự khái thác ác ý. Vì thế, các nội dung bộ nhớ ẩn phải
được bảo vệ như là thông tin nhạy cảm.
Bạn đang xem trước 20 trang tài liệu Tài liệu HTTP, để xem tài liệu hoàn chỉnh bạn click vào nút DOWNLOAD ở trên
g để á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.tutorialspoint.com
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)
Connection: close
Content-Type: message/http
Content-Length: 39
TRACE / HTTP/1.1
Host: www.tutorialspoint.com
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Copyright © vietjack.com
Trang chia sẻ các bài học online miễn phí Page 31
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:
STT Mã và miêu tả
1 1xx: Thông tin
Nó nghĩa là yêu cầu đã được nhận và tiến trình đang tiếp tục.
2 2xx: Thành công
Nó nghĩa là hoạt động đã được nhận, được hiểu, và được chấp nhận một
cách thành công.
3 3xx: Sự điều hướng lại
Nó nghĩa là hoạt động phải được thực hiện để hoàn thành yêu cầu.
4 4xx: Lỗi Client
Nó nghĩa là yêu cầu chứa cú pháp không chính xác hoặc không được thực
hiện.
5 5xx: Lỗi Server
Nó nghĩa là Server thất bại với việc thực hiện một yêu cầu nhìn như có vẻ
khả thi.
Các mã trạng thái là có tính co dãn và các ứng dụng HTTP không được yêu cầu để hiểu ý nghĩa
của tất cả các mã trạng thái đã được đăng ký. Dưới đây là một danh sách liệt kê tất cả các mã
trạng thái:
Copyright © vietjack.com
Trang chia sẻ các bài học online miễn phí Page 32
1xx: Thông tin
Thông báo Miêu tả
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
Thông báo Miêu tả
200 OK Yêu cầu là OK.
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 thành.
203 Non-
authoritative
Information
Thông tin trong đối tượng Header là từ một bản sao nội
bộ hoặc bên thứ 3, không từ Server ban đầu.
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.
205 Reset Trình duyệt nên dọn sạch mẫu được sử dụng cho việc
Copyright © vietjack.com
Trang chia sẻ các bài học online miễn phí Page 33
Content truyền tải này bởi một dữ liệu đầu vào tăng thêm.
206 Partial
Content
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ộtRange 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
Thông báo Miêu tả
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.
Copyright © vietjack.com
Trang chia sẻ các bài học online miễn phí Page 34
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
Thông báo Miêu tả
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.
405 Method Not
Allowed
Phương thức được xác định trong yêu cầu là không
được cho phép.
406 Not Acceptable Server chỉ có thể tạo một phản hồi mà không được
chấp nhận bởi Client.
407 Proxy
Authentication
Bạn phải xác nhận với một Server ủy quền trước khi
Copyright © vietjack.com
Trang chia sẻ các bài học online miễn phí Page 35
Required yêu cầu này được phục vụ.
408 Request
Timeout
Yêu cầu tốn thời gian dài hơn thời gian Server được
chuẩn bị để đợi.
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ó.
412 Precondition
Failed
Điều kiện trước được cung cấp trong yêu cầu được
tính toán là sai bởi Server.
413 Request Entity
Too Large
Server sẽ không chấp nhận yêu cầu, bởi vì đối
tượng yêu cầu là quá rộng.
414 Request-url Too
Long
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.
415 Unsupported
Media Type
Server sẽ không chấp nhận yêu cầu, bởi vì kiểu
phương tiện không được hỗ trợ.
416 Requested
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.
Copyright © vietjack.com
Trang chia sẻ các bài học online miễn phí Page 36
417 Expectation
Failed
Khả năng được cung cấp trong một trường Expect
không thể được kết nối bởi Server.
5xx: Lỗi Server
Thông báo Miêu tả
500 Internal Server
Error
Yêu cầu không được hoàn thành. Server bắt gặp
một điều kiện không được mong đợi.
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.
503 Service
Unavailable
Yêu cầu không được hoàn thành. Server tạm thời
đang quá tải hoặc down.
504 Gateway Timeout Gateway bị trễ.
505 HTTP Version
Not Supported
S
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.
Copyright © vietjack.com
Trang chia sẻ các bài học online miễn phí Page 37
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ởiClient trong yêu cầu HTTP của nó:
STT Chỉ dẫn yêu cầu bộ nhớ ẩn và miêu tả
1 no-cache
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 đầu.
2 no-store
Bộ nhớ ẩn không nên lưu giữ bất cứ thứ gì về yêu cầu Client hoặc phản
hồ Server.
Copyright © vietjack.com
Trang chia sẻ các bài học online miễn phí Page 38
3 max-age = giây (s)
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).
4 max-stale [ tính bằng giây ]
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 đó.
5 min-fresh = giây
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.
6 no-transform
Không chuyển đổi phần thân đối tượng.
7 only-if-cached
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 Server trong phản
hồi của nó:
STT Chỉ dẫn phản hồi bộ nhớ ẩn và Miêu tả
1 public
Chỉ ra rằng phản hồi có thể được giữ trong bộ nhớ ẩn bởi bất cứ bộ nhớ
Copyright © vietjack.com
Trang chia sẻ các bài học online miễn phí Page 39
ẩn nào.
2 private
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ẻ.
3 no-cache
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.
4 no-store
Bộ nhớ ẩn không nên lưu bất cứ gì về yêu cầu Client hoặc phản hồi
Server.
5 no-transform
Không chuyển đổi phần thân đối tượng.
6 must-revalidate
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.
7 proxy-revalidate
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ẻ.
8 max-age = giây
Chỉ ra rằng Client đang muốn chấp nhận một yêu cầu mà tuổi của nó
Copyright © vietjack.com
Trang chia sẻ các bài học online miễn phí Page 40
không lớn hơn thời gian đã xác định bằng giây.
9 s-maxage = 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.
Copyright © vietjack.com
Trang chia sẻ các bài học online miễn phí Page 41
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ụ:
Copyright © vietjack.com
Trang chia sẻ các bài học online miễn phí Page 42
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
Các trường Header yêu cầu trên Client
Trường Accept (Chấp nhận)
Trường Accept này có thể được sử dụng đễ xác định các kiểu phương tiện cụ thể mà là có thể
chấp nhận cho sự phản hồi. Cú pháp chung là như sau:
Accept: type/subtype [q=qvalue]
Các kiểu phương tiện có thể được liệt kê phân biệt nhau bởi các dấu phảy và giá trị q tùy ý biểu
diễn một mức độ chất lượng có thể chấp nhận để chấp nhận các kiểu trên một phạm vi từ 0 tới 1.
Dưới đây là ví dụ:
Accept: text/plain; q=0.5, text/html, text/x-dvi; q=0.8, text/x-c
Đoạn này có thể được biên dịch như text/html và text/x-c và là các kiểu phương tiện được ưa
thích hơn nhưng nếu chúng không tồn tại, thì sau đó gửi đối tượng text/x-dvi , và nếu nó không
tồn tại, gửi đối tượng text/plain.
Copyright © vietjack.com
Trang chia sẻ các bài học online miễn phí Page 43
Trường Accept-Charset
Trường này có thể được sử dụng để chỉ các bộ thiết lập ký tự nào được chấp nhận cho sự phản
hồi. Dưới đây là cú pháp chung:
Accept-Charset: character_set [q=qvalue]
Nhiều bộ ký tự có thể được liệt kê riêng rẽ nhau bởi các dấu phảy và giá trị q tùy ý biểu diễn một
mức độ chất lượng có thể chấp nhận cho các bộ ký tự không được ưa thích hơn trên một miền từ
0 đến 1. Dưới đây là ví dụ:
Accept-Charset: iso-8859-5, unicode-1-1; q=0.8
Giá trị đặc biệt “*”, nếu có trong trường Accept-Charset, kết nối mọi bộ ký tự và nếu không có giá
trị trường Accept-Charset nào, thì mặc định là bất kỳ bộ ký tự nào cũng có thể được chấp nhận.
Trường Accept-Encoding
Trường này tương tự như Accept, nhưng hạn chế mã hóa nội dung là có thể chấp nhận trong phản
hồi. Cú pháp chung là:
Accept-Encoding: encoding types
Các ví dụ là như sau:
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
Trường Accept-Language
Trường này tương tự như Accept, nhưng hạn chế bộ thiết lập của các ngôn ngữ tự nhiên là được
ưa thích hơn khi một phản hồi tới một yêu cầu. Cú pháp chung là:
Accept-Language: language [q=qvalue]
Nhiều ngôn ngữ có thể được liệt kê phân biệt nhau bởi dấu phảy và giá trị q tùy ý biểu diễn một
mức độ chất lượng có thể chấp nhận cho các ngôn ngữ không được ưa thích hơn trên miền từ 0
tới 1. Dưới đây là một ví dụ:
Accept-Language: da, en-gb;q=0.8, en;q=0.7
Copyright © vietjack.com
Trang chia sẻ các bài học online miễn phí Page 44
Trường Authorization (Sự ủy quyền)
Giá trị trường Authorization bao gồm các sự ủy nhiệm mà chứa thông tin ủy quyền của một user
agent cho phạm vi nguồn đang được yêu cầu. Cú pháp chung là:
Authorization : credentials
Định cấu hình HTTP/1.0 định nghĩa giản đồ ủy quyền CƠ BẢN, nơi mà tham số ủy quyền là một
chuỗi của tên sử dụng:mật khẩu được mã hóa trong cơ sở 64 bit. Dưới đây là ví dụ:
Authorization: BASIC Z3Vlc3Q6Z3Vlc3QxMjM=
Giá trị đã giải mã là guest:guest123, trong đó guest là tài khoản người dùng và guest123 là mật
khẩu.
Trường Cookie
Giá trị trường Cookie chứa một cặp tên/giá trị của thông tin được lưu giữ cho URL đó. Dưới đây là
cú pháp chung:
Cookie: name=value
Nhiều cookie có thể được xác định phân biệt nhau bởi các dấu chấm phảy “;” như sau:
Cookie: name1=value1;name2=value2;name3=value3
Trường Expect
Trường Expect được sử dụng để chỉ ra rằng một bộ thiết lập cụ thể của các hành vi Server được
yêu cầu bởi Client. Cú pháp chung là:
Expect : 100-continue | expectation-extension
Nếu một Server nhận một yêu cầu chứa một trường Expect mà bao gồm một độ dãn mong đợi mà
nó không hỗ trợ, nó phải phản hồi với trạng thái 417 (sự mong đợi thất bại).
Trường From
Trường From chứa một địa chỉ thư điện tử cho người sử dụng mà kiểm soát user agent. Dưới đây
là một cú pháp đơn giản:
From: webmaster@w3.org
Trường này có thể được sử dụng cho nhập các mục đích và như là một phương tiện cho việc xác
nhận nguồn của các yêu cầu không khả thi hoặc không muốn.
Copyright © vietjack.com
Trang chia sẻ các bài học online miễn phí Page 45
Trường Host
Trường Host được sử dụng để xác định Internet host và số hiệu cổng của nguồn được yêu cầu.
Cú pháp chung là:
Host : "Host" ":" host [ ":" port ] ;
Một Host mà không có bất kỳ thông tin port nào ngụy ý là port mặc định, mà là 80. Ví dụ, một yêu
cầu trên Server ban đầu cho sẽ là:
GET /pub/WWW/ HTTP/1.1
Host: www.w3.org
Trường If-Match
Trường If-Match được sử dụng trong một method để làm cho nó có điều kiện. Header này yêu cầu
Server để biểu diễn method được yêu cầu chỉ khi giá trị được cung cấp trong thẻ này kết nối với
các thẻ đối tượng được cung cấp được biểu diễn bởi Etag. Cú pháp chung là:
If-Match : entity-tag
Một dấu (*) kết nối với bất cứ đối tượng nào, và sự truyền tải tiếp tục chỉ khi đối tượng tồn tại. Dưới
đây là các ví dụ có thể:
If-Match: "xyzzy"
If-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
If-Match: *
Nếu không có thể đối tượng nào kết nối, hoặc nếu (*) được cung cấp và không đối tượng hiện tại
nào tồn tại, Server không được trình bày method được yêu cầu, và phải trả lại một phản hồi là 412
(điều kiện trước thất bại).
Trường If-Modified-Since
Trường này được sử dụng với một method để làm cho nó có điều kiện. Nếu URL được yêu cầu
không được chỉnh sửa từ thời gian đã được xác định trong trường này, một đối tượng sẽ không
được trả lại từ Server; thay vào đó, một phản hồi 304 (không được chỉnh sửa) sẽ được trả lại mà
không có bất cứ phần thân thông báo nào. Cú pháp chung của If-Modified-Since là:
If-Modified-Since : HTTP-date
Một ví dụ của trường là:
Copyright © vietjack.com
Trang chia sẻ các bài học online miễn phí Page 46
If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT
Nếu không có thẻ đối tượng nào kết nối với, hoặc nếu “*” được cung cấp và không đối tượng hiện
tại nào tồn tại,, Server không được trình bày method được yêu cầu, và phải trả lại phản hồi 412
(điều kiện trước thất bại).
Trường If-None-Match
Trường này được sử dụng với một method để làm cho nó có điều kiện. Trường này yêu cầu Server
trình bày method được yêu cầu chỉ khi một trong số giá trị đã cho của thẻ này kết nối với các thẻ
đối tượng đã được cung cấp biểu diễn bởi Etag. Cú pháp chung là:
If-None-Match : entity-tag
Một dấu * kết nối với bất kỳ đối tượng nào, và sự truyền tải tiếp tục chỉ khi đối tượng không tồn tại.
Dưới đây là các ví dụ có thể có:
If-None-Match: "xyzzy"
If-None-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
If-None-Match: *
Trường If-Range
Trường If-Range có thể được sử dụng với một GET có điều kiện để yêu cầu chỉ một phần của đối
tượng mà đang bị thất lạc, nếu nó không được thay đổi, và toàn bộ đối tượng nếu nó được thay
đổi. Cú pháp chung như sau:
If-Range : entity-tag | HTTP-date
Hoặc một thẻ đối tượng hoặc một dữ liệu có thể được sử dụng để xác minh đối tượng nội bộ đã
nhận. Ví dụ:
If-Range: Sat, 29 Oct 1994 19:43:31 GMT
Tại đây, nếu tài liệu không được chỉnh sửa từ ngày đã cho, Server trả lại dãy byte được cung cấp
bởi trường Range, nếu không thì nó trả lại tất cả các tài liệu mới.
Trường If-Unmodified-Since
Trường này được sử dụng với một method để làm cho nó có điều kiện. Cú pháp chung là:
If-Unmodified-Since : HTTP-date
Copyright © vietjack.com
Trang chia sẻ các bài học online miễn phí Page 47
Nếu nguồn được yêu cầu không được chỉnh sửa từ khi thời gian đã được xác định trong trường
này, Server sẻ thực hiện hoạt động được yêu cầu nếu như If-Unmodified-Since không biểu diễn. Ví
dụ:
If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT
Nếu yêu cầu có kết quả là bất cứ gì khác ngoài một trạng thái là 2xx hoặc 4xx, thì trường If-
Unmodified-Since nên được bỏ qua.
Trường Max-Forwards
Trường này cung cấp một kỹ thuật với các phương thức TRACE và OPTIONS để giới hạn số các
trạm ủy quyền hoặc gateway mà có thể chuyển tiếp yêu cầu tới Server kế tiếp. Đây là cú pháp
chung:
Max-Forwards : n
Giá trị Max-Forward là một số nguyên hệ thập phân chỉ rằng số lần còn lại của thông báo yêu cầu
này có thể được chuyển tiếp. Điều này là hữu ích cho debug với phương thức TRACE, tránh được
các vòng lặp vô hạn. Ví dụ:
Max-Forwards : 5
Trường này có thể bị bỏ qua với tất cả các phương thức được định nghĩa trong định cấu hình
HTTP.
Trường Proxy-Authorization
Trường này cho phép Client xác nhận chính nó (hoặc người sử dụng của nó) tới một trạm ủy
quyền mà yêu cầu sự ủy nhiệm. Đây là cú pháp chung:
Proxy-Authorization : credentials
Giá trị trường Proxy-Authorization bao gồm các sự ủy nhiệm chứa thông tin ủy nhiệm của user
agent cho trạm ủy nhiệm và/hoặc phạm vi của nguồn được yêu cầu.
Trường Range
Trường Range xác định dãy nội bộ của nội dung được yêu cầu từ tài liệu. Cú pháp chung là:
Range: bytes-unit=first-byte-pos "-" [last-byte-pos]
Giá trị First-byte-pos trong một byte-range-spec chung cấp byte-offset của byte đầu tiên trong một
dãy. Giá trị last-byte-pos cung cấp byte-offset của byte cuối cùng trong dãy; đó là, các vị trí byte
Copyright © vietjack.com
Trang chia sẻ các bài học online miễn phí Page 48
được xác định. Bạn có thể xác định một đơn vị byte như các byte. Byte offset bắt đầu tại 0. Một số
ví dụ đơn giản như sau:
- 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 dãy có thể được liệt kê, phân biệt nhau bởi dấu phảy. Nếu ký số đầu tiên trong dãy byte
phân biệt nhau bởi dấu phảy bị bỏ quên, dãy được giả sử là tính toán từ phần cuối của tài liệu. Nếu
ký số thứ hai bị bỏ quên, dãy là byte thứ n tới phần cuối tài liệu.
Trường Referer
Trường này cho phép Client xác định địa chỉ URI của nguồn mà từ đó URL đã được yêu cầu. Cú
pháp chung là như sau:
Referer : absoluteURI | relativeURI
Dưới đây là ví dụ:
Referer:
Nếu giá trị trường là một URI quan hệ, nó nên được phiên dịch liên quan tới Request-URI.
Trường TE
Trường này chỉ sự mở rộng nào mà transfer-coding đang muốn chấp nhận trong phản hồi và có
hoặc không nó đang muốn chấp nhận các trường trailer trong một transfer-codingđược đóng khối.
Sau đây là cú pháp chung:
TE : t-codings
Sự hiện diện của từ khóa “trailers” chỉ rằng Client đang muốn chấp nhận các trường trailer trong
một transfer-coding được đóng khối và nó được xác định theo một trong 2 cách:
Copyright © vietjack.com
Trang chia sẻ các bài học online miễn phí Page 49
TE: deflate
TE:
TE: trailers, deflate;q=0.5
Nếu giá trị trường TE là trống hoặc không trường TE nào hiện diện, thì khi đó chỉ có transfer-
coding được đóng khối (chunked). Một thông báo với không transfer-coding là luôn luôn có thể
chấp nhận.
Trường User-Agent
Trường User-Agent chứa thông tin về tác nhân người sử dụng tạo yêu cầu. Sau đây là cú pháp
chung:
User-Agent : product | comment
Ví dụ:
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Các trường Phản hồi từ Server
Trường Accept-Ranges
Trường này cho phép Server chỉ sự chấp nhận của nó về các dãy yêu cầu cho một nguồn. Cú
pháp chung là:
Accept-Ranges : range-unit | none
Ví dụ, một Server mà chấp nhận các yêu cầu về dãy byte có thể gửi:
Accept-Ranges: bytes
Server mà không chấp nhận bất kỳ loại dãy yêu cầu cho một nguồn có thể gửi:
Accept-Ranges: none
Điều này sẽ khuyên Client không cố gắng để chiếm được một dãy yêu cầu.
Trường Age
Trường Age chuyển tính toán về số lượng thời gian từ khi phản hồi được tạo ra tại Server ban đầu
của người gửi. Cú pháp chung là:
Age : delta-seconds
Copyright © vietjack.com
Trang chia sẻ các bài học online miễn phí Page 50
Giá trị Age là các số nguyên thập phân không phủ định, biểu diễn thời gian bằng giây. Sau đây là
một ví dụ đơn giản:
Age: 1030
Một HTTP/1.1 Server mà bao gồm một bộ nhớ ẩn phải bao gồm một trường Age trong mỗi phản
hồi được tạo từ bộ nhớ ẩn riêng của nó.
Trường ETag
Trường Etag cung cấp giá trị hiện tại của thẻ đối tượng cho biến thể được yêu cầu. Cú pháp chung
là:
ETag : entity-tag
Dưới đây là một số ví dụ đơn giản:
ETag: "xyzzy"
ETag: W/"xyzzy"
ETag: ""
Trường Location
Trường Location được sử dụng để điều hướng lại người nhận tới một vị trí khác ngoài Reqest-
URI. Cú pháp chung là:
Location : absoluteURI
Dưới đây là một ví dụ đơn giản:
Location:
Trường Content-Location khác Location ở trong đó mà Content-Location xác nhận vị trí ban đầu
của đối tượng được bao gồm trong yêu cầu.
Trường Proxy-Authenticate
Trường này phải được bao gồm như là một phần của phản hồi 407. Cú pháp chung là:
Proxy-Authenticate : challenge
Copyright © vietjack.com
Trang chia sẻ các bài học online miễn phí Page 51
Trường Retry-After
Trường này có thể được sử dụng với một phản hồi 503 (Service Unavailable - dịch vụ không có
sẵn) để chỉ rằng dịch vụ được mong đợi để là không có sẵn trong vòng bao lâu tới Client đang yêu
cầu. Cú pháp chung là:
Retry-After : HTTP-date | delta-seconds
Các ví dụ:
Retry-After: Fri, 31 Dec 1999 23:59:59 GMT
Retry-After: 120
Trong ví dụ sau, sự trì hoãn là 2 phút.
Trường Server
Trường này chứa thông tin về phần mềm được sử dụng bởi Server ban đầu để kiểm soát yêu cầu.
Cú pháp chung là:
Server : product | comment
Sau đây là ví dụ:
Server: Apache/2.2.14 (Win32)
Nếu phản hồi đang được chuyển tiếp qua một trạm ủy quyền, ứng dụng ủy quyền không được
chỉnh sửa trường Server.
Trường Set-Cookie
Trường này chứa một cặp tên/giá trị của thông tin để giữ lại cho URL. Cú pháp chung là:
Set-Cookie: NAME=VALUE; OPTIONS
Trường phản hồi Set-Cookie bao gồm Set-Cookie dấu hiệu, được theo sau bởi một danh sách
được phân biệt bằng dấu phảy của một hoặc nhiều cookie. Ở đây là các giá trị có thể mà bạn có
thể xác định như là các tính năng:
STT Các tính năng và Miêu tả
1 Comment=comment
Copyright © vietjack.com
Trang chia sẻ các bài học online miễn phí Page 52
Tính năng này có thể được sử dụng để xác định bất cứ lời bình nào liên
kết với cookie.
2 Domain=domain
Thuộc tính Domain xác định miền mà với nó cookie là có hiệu lực.
3 Expires=Date-time
Ngày mà cookie sẽ hết hạn. Nếu nó là trống, cookie sẽ hết hạn khi khách
sử dụng rời khỏi trình duyệt.
4 Path=path
Thuộc tính path xác định bộ thiết lập phụ của các URL mà cookie này áp
dụng.
5 Secure
Nó chỉ dẫn user agent để trả lại cookie chỉ ở dưới dạng một kết nối an
toàn.
Sau đây là một ví dụ của một cookie đơn giản được tạo bởi Server:
Set-Cookie: name1=value1,name2=value2; Expires=Wed, 09 Jun 2021 10:18:14 GMT
Trường Vary
Trường Vary xác định rằng đối tượng có nhiều nguồn và vì thế có thể theo nhiều cách để tới một
danh sách yêu cầu đã được xác định. Sau đây là cú pháp chung:
Vary : field-name
Bạn có thể xác định nhiều Header phân biệt nhau bởi dấu phảy và một giá trị là dấu * mà không
xác định các tham số (không giới hạn tới các Header yêu cầu). Sau đây là ví dụ đơn giản:
Vary: Accept-Language, Accept-Encoding
Ở đây, các tên trường là không nhạy cảm.
Copyright © vietjack.com
Trang chia sẻ các bài học online miễn phí Page 53
Trường WWW-Authenticate
Trường này phải được bao gồm trong các thông báo phản hồi 401 (không được ủy quyền). Giá trị
trường bao gồm ít nhất một challenge (hiệu lệnh) mà chỉ dẫn giản đồ ủy quyền và các tham số có
thể áp dụng tới URI yêu cầu. Cú pháp chung là:
WWW-Authenticate : challenge
Giá trị tường có thể chứa nhiều hơn một challenge, hoặc nếu nhiều hơn một trường WWW-
Authenticate được cung cấp, các nội dung của chính challenge đó có thể chứa một danh sách
được phân biệt bởi dấu phảy của các tham số ủy quyền. Sau đây là một ví dụ đơn giản:
WWW-Authenticate: BASIC realm="Admin"
Entity Headers
Trường Allow
Trường này liệt kê bộ thiết lập của các method được hỗ trợ bởi nguồn được xác nhận bởi Request-
URI. Cú pháp chung là:
Allow : Method
Bạn có thể xác định nhiều phương thức được phân biệt bởi dấu phảy. Sau đây là một ví dụ đơn
giản:
Allow: GET, HEAD, PUT
Trường này không ngăn cản một Client từ việc cố gắng thử các method khác.
Trường Content-Encoding
Trường này được sử dụng như một bộ chỉnh sửa tới kiểu phương tiện. Cú pháp chung là:
Content-Encoding : content-coding
Mã hóa nội dung là một thuộc tính của một đối tượng được xác định bởi Request-URI. 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 đối tượng là một thông báo yêu cầu là không được chấp nhận bởi
Server nguồn, Server sẽ phản hồi với một mã trạng thái 415 (kiểu phương tiện không được hỗ trợ).
Copyright © vietjack.com
Trang chia sẻ các bài học online miễn phí Page 54
Trường Content-Language
Trường này miêu tả các ngôn ngữ tự nhiên của người đọc đã dự định cho đối tượng đã bao gồm.
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 mà được dự định cho nhiều người đọc. Sau đây
là một ví dụ đơn giản:
Content-Language: mi, en
Mục đích đầu tiên của Content-Language là để cho phép một người sử dụng để xác nhận và tạo
sự khác biệt các đối tượng theo ngôn ngữ được ưa thích hơn của riêng người dùng.
Trường Content-Length
Trường này chỉ dẫn kích cỡ của phần thân đối tượng, trong số thập phân của hệ 8, được gửi tới
người nhận hoặc, trong trường hợp của phương thức HEAD, kích cỡ của phần thân đối tượng mà
sẽ được gửi, có yêu cầu là một GET. Cú pháp chung là:
Content-Length : DIGITS
Sau đây là một ví dụ đơn giản:
Content-Length: 3495
Bất kỳ Conten-Length nào lớn hơn hoặc bằng là một giá trị có hiệu lực.
Trường Content-Location
Trường này có thể được sử dụng để cung cấp vị trí nguồn cho đối tượng được bao gồm trong
thông báo khi đối tượng đó là có thể truy cập từ một vị trí riêng biệt từ một URI của nguồn được
yêu cầu. Cú pháp chung là:
Content-Location: absoluteURI | relativeURI
Sau đây là một ví dụ đơn giản:
Content-Location:
Giá trị của Content-Location cũng định nghĩa URI cơ sở cho đối tượng.
Copyright © vietjack.com
Trang chia sẻ các bài học online miễn phí Page 55
Trường Content-MD5
Trường này có thể được sử dụng để cung cấp một hệ thống phân loại MD5 của đối tượng cho việc
kiểm tra tính nguyên vẹn của thông tin tới người nhận. Cú pháp chung là:
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
Hệ thống phân loại MD5 được tính toán hóa dựa trên cơ sở nội dung của phần thân thực thể, bao
gồm bất cứ mã hóa nội dung nào mà đã được áp dụng, nhưng không bao gồm bất cứ mã hóa
truyền tải được áp dụng tới phần thân thông báo.
Trường Content-Range
Trường này được gửi với một phần thân thực thể nội bộ để xác định nơi trong toàn bộ phần thân
đối tượng mà phần thân nội bộ nên được áp dụng. Cú pháp chung là:
Content-Range : bytes-unit SP first-byte-pos "-" last-byte-pos
Các ví dụ của các giá trị byte-content-range-spec, giả sử rằng đối tượng chứa một tổng của 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 dãy đơn, nội dung này được truyền tải với một
Content-Range, và một Content-Length chỉ số byte được truyền tải thực sự. Ví dụ:
HTTP/1.1 206 Partial content
Date: Wed, 15 Nov 1995 06:25:24 GMT
Copyright © vietjack.com
Trang chia sẻ các bài học online miễn phí Page 56
Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
Content-Range: bytes 21010-47021/47022
Content-Length: 26012
Content-Type: image/gif
Trường Content-Type
Trường này chỉ dẫn kiểu phương tiện của phần thân đối tượng được gửi tới người nhận hoặc,
trong trường hợp phương thức HEAD, kiểu phương tiện mà sẽ được gửi, có yêu cầu là GET. Cú
pháp chung là:
Content-Type : media-type
Sau đây là một ví dụ:
Content-Type: text/html; charset=ISO-8859-4
Trường Expires
Trường này cung cấp Ngày/Thời gian sau đó phản hồi được cho là hết hạn. Cú pháp chung:
Expires : HTTP-date
Sau đây là một ví dụ:
Expires: Thu, 01 Dec 1994 16:00:00 GMT
Trường Last-Modified
Trường này chỉ ngày và thời gian tại đó Server ban đầu tin rằng sự biến đổi được chỉnh sửa lần
cuối. Cú pháp chung là:
Last-Modified: HTTP-date
Sau đây là một ví dụ:
Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT
Caching trong HTTP
HTTP được sử dụng một cách đặc trưng cho các hệ thống thông tin được phân phối, nơi mà hiệu
suất có thể được nâng cao bởi sử dụng các bộ nhớ ẩn phản hồi. Giao thức HTTP/1.1 bao gồm một
số các yếu tố được dự định để thực hiện các công việc lưu vào bộ nhớ ẩn.
Copyright © vietjack.com
Trang chia sẻ các bài học online miễn phí Page 57
Mục tiêu của lưu vào bộ nhớ ẩn trong HTTP/1.1 là để tính toán sự cần thiết để gửi các yêu cầu
trong nhiều trường hợp, và để tính toán sự cần thiết để gửi các sự phản hồi đầy đủ trong nhiều
trường hợp khác.
Kỹ thuật bộ nhớ ẩn cơ sở trong HTTP/1.1 là gồm các chỉ thị tới các bộ nhớ ẩn nơi mà Server xác
định thời gian và ngày mãn hạn. Chúng ta sử dụng trường Cache-Control cho mục đích này.
Trường Cache-Control cho phép một Client hoặc Server để truyền các chỉ thị đa dạng trong hoặc
các yêu cầu hoặc các sự phản hồi. Những chỉ thị này có đặc trưng là có quyền ưu tiên cao hơn các
thuật toán lưu vào bộ nhớ ẩn theo mặc định. Các chỉ thị lưu vào bộ nhớ ẩn được xác định trong
một danh sách phân biệt nhau bởi dấu phảy. Ví dụ:
Cache-control: no-cache
Sau đây là các chỉ thị yêu cầu bộ nhớ ẩn có thể được sử dụng bởi Client trong yêu cầu HTTP của
nó:
STT Chỉ dẫn yêu cầu bộ nhớ ẩn và miêu tả
1 no-cache
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 đầu.
2 no-store
Bộ nhớ ẩn không nên lưu giữ bất cứ thứ gì về yêu cầu Client hoặc phản hồ
Server.
3 max-age = (tính bằng giây)
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).
4 max-stale [= giây]
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 đó.
Copyright © vietjack.com
Trang chia sẻ các bài học online miễn phí Page 58
5 min-fresh = giây
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.
6 no-transform
Không chuyển đổi phần thân đối tượng.
7 only-if-cached
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ỉ thị phản hồi bộ nhớ ẩn sau đây có thể được sử dụng bởi Server trong phản hồi HTTP của
nó:
STT Chỉ dẫn phản hồi bộ nhớ ẩn và Miêu tả
1 public
Chỉ ra rằng phản hồi có thể được giữ trong bộ nhớ ẩn bởi bất cứ bộ nhớ
ẩn nào.
2 private
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ẻ.
3 no-cache
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.
4 no-store
Bộ nhớ ẩn không nên lưu bất cứ gì về yêu cầu Client hoặc phản hồi
Copyright © vietjack.com
Trang chia sẻ các bài học online miễn phí Page 59
Server.
5 no-transform
Không chuyển đổi phần thân đối tượng.
6 must-revalidate
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.
7 proxy-revalidate
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ẻ..
8 max-age = giây
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.
9 s-maxage = 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.
Mã hóa URL trong HTTP
Các HTTP URL có thể chỉ được gửi thông qua Internet bởi sử dụng bộ ký tự ASCII, mà thường
chứa các ký tự bên ngoài bộ ký tự ASCII. Vì thế các ký tự không an toàn phải được đổi chỗ với
a % được theo sau bởi hai ký số hệ thập lục phân.
Bảng dưới đây chỉ các ký hiệu ASCII của các ký tự và sự thay thế của chúng mà có thể được sử
dụng trong URL trước khi truyền nó tới Server.
ASCII Biểu
tượng
Sự thay thế
Copyright © vietjack.com
Trang chia sẻ các bài học online miễn phí Page 60
< 32 Mã hóa với %xx, với xx là sự đại diện trong hệ thập lục phân
của ký tự.
32 space + or %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 - -
Copyright © vietjack.com
Trang chia sẻ các bài học online miễn phí Page 61
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 8 8
57 9 9
58 : %3A
59 ; %3B
60 < %3C
Copyright © vietjack.com
Trang chia sẻ các bài học online miễn phí Page 62
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 I I
74 J J
75 K K
Copyright © vietjack.com
Trang chia sẻ các bài học online miễn phí Page 63
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
Copyright © vietjack.com
Trang chia sẻ các bài học online miễn phí Page 64
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 i i
Copyright © vietjack.com
Trang chia sẻ các bài học online miễn phí Page 65
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
Copyright © vietjack.com
Trang chia sẻ các bài học online miễn phí Page 66
121 y y
122 z z
123 { %7B
124 | %7C
125 } %7D
126 ~ %7E
127 %7F
> 127 Mã hóa với %xx, với xx là sự đại diện trong hệ thập lục phân
của ký tự.
Bảo mật trong HTTP
HTTP được sử dụng cho giao tiếp thông tin qua Internet, vì thế các nhà lập trình ứng dụng, các
nhà cung cấp thông tin, và những người sử dụng nên nhận biết các giới hạn bảo vệ trong
HTTP/1.1. Chương thảo luận này sẽ không bao gồm các giải pháp rõ ràng tới những vấn đề được
đề cập tại đây, nhưng nó đưa ra một số gợi ý để giảm các rủi ro.
Sự rò rỉ thông tin cá nhân
Các Client thường giữ bí mật một số lượng lớn thông tin cá nhân như tên người sử dụng, vị trí, địa
chỉ mail, các khóa mật mã hóa, . Vì thế bạn nên rất cẩn thận để ngăn cản sự rò rỉ thông tin này
qua các giao thức HTTP tới các nguồn khác.
Tất cả thông tin bí mật nên được lưu tại Server trong mẫu mật mã hóa.
Khám phá phiên bản phần mềm riêng của Server có thể cho phép thiết bị Server để trở lên
dễ tổn thương hơn khi bị tấn công phần mềm mà được biết tới là các lỗ hổng bảo mật.
Copyright © vietjack.com
Trang chia sẻ các bài học online miễn phí Page 67
Các trạm ủy quyền mà phục vụ như là một cửa thông qua một bức tường lửa mạng nên
thực hiện các biện pháp phòng ngừa đặc biệt tới việc truyền tải của thông tin Header mà
nhận diện các host đằng sau tường lửa.
Thông tin được gửi trong trường “From” có thể xung đột với các quyền lợi cá nhân của
người sử dụng hoặc chính sách bảo mật của site, và vì thế, nó không nên được truyền tải
mà không có sự giám sát của người sử dụng để không cho phép, cho phép hoặc chỉnh sửa
các nội dung của trường.
Các Client không nên bao gồm một trường Referer trong một yêu cầu HTTP (không an
toàn), nếu trang đang hướng tới được truyền trải với một giao thức bảo mật.
Các tác giả của dịch vụ mà sử dụng giao thức HTTP không nên sử dụng các mẫu dựa trên
GET để chấp nhận dữ liệu nhạy cảm, bởi vì nó sẽ làm cho dữ liệu được mã hóa trong
Request-URI.
Sự tấn công dựa trên các tên Path và File
Tài liệu nên được giới hạn tới các tài liệu mà được trả về bởi các yêu cầu HTTP tới chỉ những tài
liệu mà đã được có dự định bởi người quản lý Server.
Ví dụ, UNIX, Microsoft và các hệ điều hành khác sử dụng `..` như là một thành phần đường truyền
để chỉ một mức độ thư mục ở trên thư mục hiện tại. Trên một hệ thống như vậy, một Server PHẢI
không cho phép bất cứ sự xây dựng nào trong Request-URI, nếu không thì nó cho phép truy cập
tới một nguồn bên ngoài những thư mục này để được có thể truy cập thông qua Server.
Việc đánh lừa DNS (DNS Spoofing)
Các Client đang sử dụng HTTP chủ yếu dựa trên Dịch vụ tên miền (DNS), và là vì vậy thường dễ
bị tấn công bảo mật dựa trên sự quên liên kết có chủ tâm của các địa chỉ IP và các tên DNS. Vì thế
các Client cần chú ý trong khi đang giả sử rằng tính hiệu lực đang tiếp tục của một sự liên kết giữa
IP/tên miền DNS.
Nếu các Client ghi vào bộ nhớ ẩn các kết quả của các sự tra cứu tên host để đạt được sự cải thiện
hiệu suất, chúng phải theo dõi thông tin TTl được báo cáo bởi DNS. Nếu các Client không theo dõi
quy luật này, chúng có thể bị đánh lừa khi một địa chỉ IP của Server đã truy cập trước đó thay đổi.
Copyright © vietjack.com
Trang chia sẻ các bài học online miễn phí Page 68
Vị trí các Header và việc đánh lừa
Nếu một Server đơn hỗ trợ nhiều tổ chức mà không tin tưởng lẫn nhau, thì khi đó nó PHẢI kiểm tra
các giá trị của các trường Location và Content Location trong các phản hồi mà được tạo dưới sự
điều khiển của các tổ chức được nhắc đến để đảm bảo rằng chúng không cố gắng chiếm lấy các
nguồn tài nguyên không có hiệu lực mà qua đó chúng không có ủy quyền.
Ủy nhiệm xác minh
Các Client đang tồn tại và user agent có đặc trưng là ghi lại thông tin xác minh một cách mập mờ.
HTTP/1.1 không cung cấp một phương thức cho Server để chỉ dẫn trực tiếp các Client loại bỏ
những ủy nhiệm ghi vào bộ nhớ ẩn mà là một nguy cơ rủi ro bảo mật lớn.
Có một số công việc xung quanh tới các phần của vấn đề này, và vì thế nó được khuyến khích là
sử dụng các mật khẩu bảo vệ trong việc bảo vệ màn hình, các thời gian rỗi, và một số phương
thức khác mà làm giảm đi các vấn đề an toàn cố hữu trong vấn đề này.
Các sự ủy quyền và việc ghi vào bộ nhớ ẩn
Các sự ủy quyền HTTP là một Server trung gian, và tương ứng là các cơ hội về các nguy cơ tấn
công ở trung gian. Các ủy nhiệm có truy cập tới thông tin bảo mật liên quan, thông tin cá nhân về
từng người sử dụng và các tổ chức, và thông tin sở hữu riêng của người sử dụng và người cung
cấp nội dung đó.
Các nhà điều hành ủy nhiệm nên bảo về các hệ thống mà các ủy nhiệm chạy trên đó, vì họ sẽ bảo
vệ bất kỳ hệ thống nào mà chứa hoặc truyền tải thông tin nhạy cảm.
Việc ghi vào bộ nhớ ẩn các ủy nhiệm tạo ra thêm các lỗ hổng tiềm tàng, từ khi các nội dung của bộ
nhớ ẩn biểu diễn một mực tiêu hấp dẫn cho sự khái thác ác ý. Vì thế, các nội dung bộ nhớ ẩn phải
được bảo vệ như là thông tin nhạy cảm.
Ví dụ về Message trong HTTP
Ví dụ 1
HTTP yêu cầu rút trang hello.htm từ Server đang chạy trên tutorialspoint.com.
Client yêu cầu:
GET /hello.htm HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Copyright © vietjack.com
Trang chia sẻ các bài học online miễn phí Page 69
Host: www.tutorialspoint.com
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Connection: Keep-Alive
Server phản hồi:
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
Hello, World!
Ví dụ 2
HTTP yêu cầu rút trang t.html mà không tồn tại trên Server đang chạy trêntutorialspoint.com.
Client yêu cầu
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
Server phản hồi
HTTP/1.1 404 Not Found
Date: Sun, 18 Oct 2012 10:36:20 GMT
Server: Apache/2.2.14 (Win32)
Content-Length: 230
Copyright © vietjack.com
Trang chia sẻ các bài học online miễn phí Page 70
Content-Type: text/html; charset=iso-8859-1
Connection: Closed
404 Not Found
Not Found
The requested URL /t.jspl was not found on this server.
Ví dụ 3
HTTP yêu cầu rút trang hello.htm từ Server đang chạy trên tutorialspoint.com nhưng yêu cầu đi
kèm với một phiên bản HTTP không chính xác:
Client yêu cầu
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
Server phản hồi
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
Copyright © vietjack.com
Trang chia sẻ các bài học online miễn phí Page 71
400 Bad Request
Bad Request
Your browser sent a request that this server could not understand.
The request line contained invalid characters following the protocol string.
Ví dụ 4
HTTP yêu cầu để gửi dữ liệu mẫu tới trang process.cgi trên một Server đang chạy
trêntutorialspoint.com. Server trả lại tên đã truyền sau khi thiết lập chúng như là các cookie:
Client 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: text/xml; charset=utf-8
Content-Length: 60
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Connection: Keep-Alive
first=Zara&last=Ali
Server phản hồi
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-
Copyright © vietjack.com
Trang chia sẻ các bài học online miễn phí Page 72
Nov-2010 04:38:14 GMT;Path=/
Content-Type: text/html
Connection: Closed
Hello Zara Ali
Tài liệu tham khảo về HTTP
Các nguồn sau chứa các thông tin hữu ích về HTTP. Mong bạn sử dụng chúng để hiểu sâu hơn
những gì chúng tôi đã trình bày trong loạt bài này.
Các đường link hữu ích về HTTP
Tutorialspoint − Loạt bài hướng dẫn của chúng tôi xây dựng dựa trên nguồn này.
Hypertext Transfer Protocol - HTTP/1.1 - Trình bày chi tiết kỹ thuật về "HTTP/1.1", và sự
cập nhật với RFC 2068
HTTP State Management Mechanism - Định nghĩa Giao thức cho HTTP State Management
Mechanism.
Transmission Control Protocol - Một tài liệu đầy đủ về TCP protocol. (RFC 793)
IP/IPv4 Protocol - Một tài liệu đầy đủ về Internet Protocol Version 4 (RFC 791)
IP/IPv6 Protocol - Một tài liệu đầy đủ về Internet Protocol Version 6 (RFC 791)
IANA IPv4 Address Space Registry - Sự cấp phát không gian địa chỉ của Internet Protocol
version 4 (IPv4).
IP-Lookup - Giúp bạn tìm kiếm thông tin về địa chỉ IP của bạn hoặc bất kỳ địa chỉ IP nào
khác. Nó hỗ trợ cả địa chỉ của IPv4 và IPv6.
Các file đính kèm theo tài liệu này:
- tai_lieu_http_tieng_viet_191.pdf