Tại sao Drupal sử dụng 403 Cấm?

RFC 2616 , tài liệu xác định HTTP / 1.1, đưa ra các định nghĩa của tất cả các mã trạng thái HTTP. Đối với 403 Forbidden, nó nói :

Máy chủ hiểu yêu cầu, nhưng từ chối thực hiện nó. Ủy quyền sẽ không giúp đỡ và yêu cầu KHÔNG NÊN lặp lại. Nếu phương thức yêu cầu không phải là CHÍNH và máy chủ muốn công khai lý do tại sao yêu cầu chưa được thực hiện, thì NÊN mô tả lý do từ chối trong thực thể. Nếu máy chủ không muốn cung cấp thông tin này cho khách hàng, mã trạng thái 404 (Không tìm thấy) có thể được sử dụng thay thế.

Nhưng đó không phải là cách Drupal sử dụng nó: tùy vào từng trường hợp, nó sử dụng nó cho điều kiện mặc định trong các cuộc gọi lại (ví dụ shortcut_link_add_inline()) Cách thực hiện 403 Forbiddentương đương với "Drupal không hiểu yêu cầu". không có quyền truy cập vào trang (tức là do các quyền như là người dùng ẩn danh).

Trong trường hợp trước đây ("yêu cầu không được hiểu"), mã trạng thái phù hợp hơn là 400 Bad Request:

Máy chủ không thể hiểu được yêu cầu do cú pháp không đúng. Khách hàng KHÔNG NÊN lặp lại yêu cầu mà không sửa đổi.

Và trong trường hợp sau này ("khách hàng không có quyền truy cập vào trang do quyền"), thì nó phải là 401 Unauthorized(nếu Drupal muốn cho rằng đó chỉ là vấn đề về quyền):

Yêu cầu yêu cầu xác thực người dùng. Phản hồi PHẢI bao gồm trường tiêu đề WWW-xác thực (phần 14.47) có chứa một thách thức áp dụng cho tài nguyên được yêu cầu. Máy khách CÓ THỂ lặp lại yêu cầu với trường tiêu đề Ủy quyền phù hợp (phần 14.8). Nếu yêu cầu đã bao gồm thông tin xác thực ủy quyền, thì phản hồi 401 cho biết rằng ủy quyền đã bị từ chối cho các thông tin đăng nhập đó.

hoặc 404 File Not Found(nếu không):

Máy chủ không tìm thấy bất cứ thứ gì khớp với URI yêu cầu. Không có dấu hiệu nào được đưa ra cho dù điều kiện là tạm thời hay vĩnh viễn. Mã trạng thái 410 (Đã qua) NÊN sử dụng nếu máy chủ biết, thông qua một số cơ chế có thể định cấu hình bên trong, rằng tài nguyên cũ không có sẵn vĩnh viễn và không có địa chỉ chuyển tiếp. Mã trạng thái này thường được sử dụng khi máy chủ không muốn tiết lộ chính xác lý do tại sao yêu cầu bị từ chối hoặc khi không có phản hồi nào khác được áp dụng.

Nhấn mạnh của tôi (xem thêm câu cuối cùng trong định nghĩa cho 403 Forbidden).

Tôi nhận ra rằng nó đã như thế này trong nhiều năm, nhưng lý do ban đầu để tạo ra drupal_access_denied()bá và bằng cách mở rộng 403 Forbiddenchỉ là phản hồi mà Drupal gửi khi nhận được yêu cầu không như thế nào?

Như đã nêu trong trích dẫn của bạn, 401 Unauthorizedphải được kết hợp với xác thực HTTP, đây không phải là những gì Drupal đang sử dụng, vì vậy đây không phải là một tùy chọn.

Vì vậy, 403 là IMHO một phản hồi hoàn toàn hợp lệ vì khách hàng không được lặp lại yêu cầu của họ nhưng cuối cùng có thể điền vào một mẫu đăng nhập mà sẽ dẫn đến một yêu cầu khác.

Các trường hợp đặc biệt như chức năng liên kết ngắn mà bạn đã đăng không quá rõ ràng. Tôi đoán lý do cho việc sử dụng quyền truy cập bị từ chối là vì nó đang kiểm tra mã thông báo đó là một xác thực. Nhưng nó cũng có thể sử dụng 400 hoặc 404. Tôi đoán lý do sử dụng 403 thay vì 400 chỉ đơn giản là vì không có chức năng trợ giúp để trả về 400.

Cũng đã có một cuộc thảo luận liên quan đến mô-đun Privatemsg (mà tôi đang duy trì) cho dù việc thử một tin nhắn riêng tư với tư cách là người dùng ẩn danh sẽ dẫn đến 403 hoặc 404 (vì lý do riêng tư). Nó từng là 404 nhưng đã được thay đổi thành 403 vì người dùng thường nhấp vào liên kết trực tiếp trong thông báo thư và trang 403 có thể dễ dàng được chuyển thành biểu mẫu đăng nhập (vì có một mô-đun thực hiện việc này ngoài hộp). Vì vậy, điều này có liên quan đến hai câu cuối của mô tả 403.