Bạn nghĩ những tính năng ẩn nào của HTTP đáng được nhắc đến?
Bởi các tính năng ẩn, tôi muốn nói đến các tính năng đã là một phần của tiêu chuẩn nhưng khá ít được biết đến hoặc không được sử dụng.
Vui lòng chỉ một tính năng cho mỗi câu trả lời.
Câu trả lời:
Nó phải là 418 Tôi là mã trạng thái ấm trà , một phần của Giao thức điều khiển bình cà phê siêu văn bản (một phần mở rộng cho HTTP). Làm cho tôi cười mỗi lần.
2.3.2 418 Tôi là một ấm trà
Bất kỳ nỗ lực nào để pha cà phê bằng ấm trà sẽ dẫn đến mã lỗi "418 Tôi là một ấm trà". Cơ thể thực thể kết quả CÓ THỂ ngắn và mập mạp.
Thực tế là người giới thiệu đã sai chính tả và người ta quyết định rằng lỗi chính tả đó nên được giữ lại.
Câu trả lời rõ ràng: Phương pháp PUT, DELETE, TRACE, OPTIONS, CONNECT
Hầu hết mọi người đều biết về phương thức GET và POST vì đó là những gì họ sử dụng khi xây dựng biểu mẫu. Các trình duyệt cũng sử dụng HEAD rất nhiều. Các phương pháp khác ít được biết đến nhiều hơn; chúng hầu hết được sử dụng bởi các ứng dụng cụ thể hơn.
Có ai đã từng thấy 402 Yêu cầu thanh toán chưa?
Tôi nghĩ 204 chỉ là nếu bạn không có nội dung để hiển thị, nhưng thông số kỹ thuật vẻ như có hành vi bổ sung mà tác nhân người dùng "không thay đổi chế độ xem tài liệu của nó."
Theo HOWTO: Định cấu hình Apache để trả lại HTTP 204 (Không có nội dung) cho AJAX
FWIW, Google thực sự làm điều gì đó tương tự. Mỗi khi người dùng nhấp vào một liên kết trong kết quả tìm kiếm của họ, Google sẽ tự ping để ghi lại lần nhấp đó; mã phản hồi từ ping là HTTP 204.
Ngoài ra, 204 No Content đề xuất đây là một kỹ thuật tốt cho "lỗi web" hoặc "báo hiệu" nếu bạn muốn tiết kiệm trên mỗi byte lưu lượng mạng cuối cùng mà bạn có thể.
(...) chủ sở hữu máy chủ mong muốn rằng các liên kết từ xa đến tài nguyên đó bị xóa. (...)
Trình thu thập dữ liệu web (đáng chú ý nhất là Google) sẽ hủy lập chỉ mục (thường là trong lần thu thập thông tin tiếp theo) một trang bắt đầu trả về 410.
Trong Nội dung động, sử dụng tiêu đề Last_Modified hoặc ETag
Đôi khi bạn có nội dung động có thể lớn và / hoặc tốn kém để tạo và nội dung đó có thể không thay đổi theo yêu cầu. Bạn có thể thêm tiêu đề Last_Modified hoặc ETag vào phản hồi đã tạo của mình.
Ở đầu mã động đắt tiền của bạn, bạn có thể sử dụng If_Modified_Since hoặc If_None_Match để xác định xem người yêu cầu nội dung đã có còn hiện tại hay không. Nếu đó là thay đổi trạng thái phản hồi thành "304 Chưa sửa đổi" và kết thúc yêu cầu.
Một số công nghệ phía máy chủ cung cấp các tính năng như vậy một cách chính thức nhưng bạn có thể thực hiện những điều trên ngay cả trong ASP-Classic thấp.
Lưu ý điều này khác với việc đặt tiêu đề Cache-Control, Expires ở chỗ nó đảm bảo khách hàng luôn có thông tin mới nhất theo yêu cầu.
Bạn có thể yêu cầu tiếp tục phản hồi HTTP (lớn) (ví dụ: tải xuống tệp) bằng cách sử dụng Range
và If-Range
yêu cầu các tiêu đề tương ứng với phạm vi byte được chỉ định và mã định danh tệp duy nhất hoặc dấu thời gian sửa đổi tệp. Điều này có thể xảy ra nếu máy chủ đã gửi Accept-Ranges: bytes
và ETag
hoặcLast-Modified
tiêu đề tiêu đề phản hồi trên phản hồi ban đầu tương ứng với thông báo rằng máy chủ hỗ trợ các yêu cầu phạm vi byte, mã định danh tệp duy nhất và dấu thời gian sửa đổi tệp.
Phản hồi ban đầu có thể trông giống như ( ETag
thường bao gồm tên tệp, kích thước và dấu thời gian sửa đổi cuối cùng):
Accept-Ranges: bytes
ETag: file.ext_1234_1234567890
Content-Range: bytes 0-1233/1234
Khi quá trình tải xuống bị hủy bỏ, ví dụ 1KB (1024 byte), khách hàng có thể tiếp tục lại như sau:
If-Range: file.ext_1234_1234567890
Range: bytes=1024-
Cái nào sẽ trả về phản hồi này với các byte thích hợp trong phần thân:
Accept-Ranges: bytes
ETag: file.ext_1234_1234567890
Content-Range: bytes 1024-1233/1234
ReST cố gắng đẩy HTTP đến giới hạn của nó như một giao thức giao diện.
Nó không phải là một tính năng ẩn , nhưng từ việc xem xét các API ReST được xác định rõ ràng, người ta có thể nắm bắt khá tốt về cách thức hoạt động của HTTP và tìm thấy các ví dụ tuyệt vời về những gì có thể đạt được với sự kết hợp đơn giản của các phương thức HTTP, mã trạng thái và tiêu đề để và băng giá.
Đoạn giới thiệu (ngược lại với Header)
Trạng thái HTTP 100 (Tiếp tục)
Khách hàng có thể gửi thông báo yêu cầu với nội dung yêu cầu để xác định xem máy chủ gốc có sẵn sàng chấp nhận yêu cầu hay không ..
Trong một số trường hợp, việc khách hàng gửi nội dung có thể không phù hợp hoặc không hiệu quả cao nếu máy chủ từ chối thông báo mà không nhìn vào nội dung.
Có thể được sử dụng để tránh lưu lượng truy cập từ các máy khách giả mạo .. và / hoặc nơi băng thông là một thứ quý giá.
Tuy nhiên, để sử dụng đầy đủ tính năng này, cần có một số tiêu chí đối với Máy khách, Máy chủ và proxy HTTP1.1. Xem HTTP / 1.1 RFC 2616 để đọc thêm về Kết nối HTTP.
http://www.domain.invalid/index.php?id=44
được gọi, nếu truy vấn ( id=44
) không thể trả về nguồn ressource, tại sao không trả về mã trạng thái 404
?http://www.domain.invalid/index.php?id=foo
được gọi trong khi id
chỉ chấp nhận số nguyên, tại sao không trả về mã trạng thái 400
?200
(ok, không vấn đề gì, bạn làm tốt) 401
.Vâng, mã trạng thái dường như là một loại chức năng bí mật của HTTP đối với một số nhà phát triển web ... Nhưng tôi tự hỏi liệu điều huyền bí nhất trong số tất cả các "tính năng" của giao thức này không phải là RFC của nó !
401
chỉ dành cho Xác thực HTTP chứ không phải các loại khác. Afaik khiến hầu hết các trình duyệt yêu cầu người dùng nhập mật khẩu http.
HTTP-Authentication
... ^^ Có quá khó để sử dụng nó thay vì phát minh lại bánh xe?
.htaccess
tệp của Apache - mà có lẽ chỉ quản trị viên web có thể cập nhật. Do đó, xác thực HTTP thực sự không phù hợp lắm để quản lý quyền người dùng và đăng nhập / đăng xuất của ứng dụng.
HTTP-Authentication
và thậm chí PHP cũng có thể xử lý HTTP-Authentication
( php.net/manual/en/features.http-auth.php ). Nếu bạn là nhà phát triển web, bạn phải có những kiến thức cơ bản về quản trị máy chủ, chỉ vì lý do an toàn! Là nhà phát triển web phải có kỹ năng quản trị trang web / sysadmin, anh ta có thể dễ dàng thực hiện các tác vụ này.