Làm cách nào để phản hồi yêu cầu HTTP OPTIONS?

83

OPTIONSPhương thức HTTP được cho là được sử dụng để xác định các phương pháp khác mà máy chủ hỗ trợ trên một tài nguyên nhất định. Do đó, tôi có hai câu hỏi:

  • Câu trả lời này trông như thế nào? Tôi đã thấy những ví dụ với danh sách CSV trong Public, Allowvà thậm chí là Access-Control-Allow-Methodstiêu đề. Tất cả chúng có cần thiết không? Có gì khác biệt? RFC 2616 có vẻ không hữu ích lắm ở đây.

  • Có thích hợp sử dụng điều này để liệt kê các hành động mà tài nguyên hỗ trợ trong môi trường không phải REST-API không? Ví dụ: nếu tôi ConversionControllerủng hộ hành động convert, thì một phản hồi như thế này có hợp lý không:

Yêu cầu:

OPTIONS /conversion HTTP/1.1

Phản ứng:

HTTP/1.1 200 OK
...
Allow: CONVERT
...
http 
— FtDRbwLXw6
nguồn
2
Allow: CONVERT??
— Pacerier

Câu trả lời:

20

RFC 2616 định nghĩa "Cho phép" ( http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.14.7 ). "Công khai" không được sử dụng nữa. "Access-Control-Allow-Method" được định nghĩa trong thông số kỹ thuật CORS (xem http://www.w3.org/TR/cors/ ).

— Julian Reschke
nguồn
Cảm ơn bạn đã làm rõ. Trong trường hợp CORS, nên gửi cả cái Allowvà Access-Control-Allow-Methodsđược gửi hay chỉ cái sau?
— FtDRbwLXw6
Tôi sẽ luôn trả về "Cho phép", do đó không phải là CORS trong trường hợp đặc biệt.
— Julian Reschke
6
Nội dung thì sao? Nội dung cơ thể có được không?
— CMCDragonkai,
2
@CMCDragonkai Có, OPTIONScó thể có nội dung. Từ RFC 2616: "Nếu yêu cầu TÙY CHỌN bao gồm phần thân thực thể (như được chỉ ra bởi sự hiện diện của Độ dài Nội dung hoặc Mã hóa Truyền tải), thì loại phương tiện PHẢI được chỉ ra bởi trường Loại-Nội dung. Mặc dù thông số kỹ thuật này không xác định bất kỳ việc sử dụng nào cho phần nội dung như vậy, các phần mở rộng trong tương lai cho HTTP có thể sử dụng phần nội dung OPTIONS để thực hiện các truy vấn chi tiết hơn trên máy chủ. Máy chủ không hỗ trợ phần mở rộng như vậy CÓ THỂ loại bỏ phần thân yêu cầu. "
— giám mục
Tôi tin rằng cả hai Allowvà Access-Control-Allow-Methodslà bắt buộc nếu bạn muốn sử dụng CORS. Cái trước chỉ định phương thức nào được hỗ trợ nói chung và cái sau chỉ định phương thức nào được phép cho các yêu cầu gốc chéo. Ví dụ, bạn có thể cho phép GET, POST, PUTvà DELETEcho nguồn gốc của riêng bạn nhưng chỉ cho phép GETvà POSTcho cross-xứ.
— Mikko Rantalainen
8

Đáp lại tiêu đề: "Làm cách nào để phản hồi yêu cầu HTTP OPTIONS?" Để trả lời điều đó, tôi muốn biết tại sao bạn muốn phản hồi yêu cầu TÙY CHỌN? Ai / cái gì đang gửi cho bạn một yêu cầu TÙY CHỌN, và tại sao? Nhiều máy chủ công cộng phản hồi với một số dạng "lỗi" hoặc "không được phép" (500, 501, 405). Vì vậy, trừ khi bạn đang ở trong một tình huống cụ thể mà khách hàng của bạn sẽ gửi một cách hợp lý các yêu cầu TÙY CHỌN và mong đợi thông tin hữu ích / có ý nghĩa trở lại (ví dụ: WebDAV, CORS), bạn có thể muốn trả lời bằng: "đừng làm vậy."

Về câu hỏi của bạn về yêu cầu "OPTIONS / chuyển đổi HTTP / 1.1": trừ khi bạn biết rằng có một số ứng dụng khách của máy chủ của mình, một ứng dụng khách sẽ gửi yêu cầu TÙY CHỌN tới "/ chuyển đổi" và mong đợi phản hồi bằng "Cho phép: CHUYỂN ĐỔI" , "câu trả lời là không: sẽ không hợp lý nếu trả lời như vậy. Tôi nghĩ rằng hầu hết các trường mà làm OPTIONS hỗ trợ và đáp ứng với "Allow", phản ứng với các phương pháp HTTP chuẩn.

Đây là một bài viết tuyệt vời về chủ đề này .

Tóm tắt: OPTIONS ngay lập tức có vấn đề vì nó không hỗ trợ bộ nhớ đệm. Lựa chọn thay thế: siêu dữ liệu trên toàn máy chủ: hãy thử các URI nổi tiếng . Tài nguyên cụ thể: hãy thử sử dụng tiêu đề Liên kết trên các phản hồi của nó hoặc liên kết ở định dạng đại diện cho tài nguyên đó.

Cuối cùng, nếu những gì bạn đang theo đuổi là một mô tả dịch vụ, hãy xem WADL hoặc RSDL .

BIÊN TẬP:

dotnetguy đưa ra một điểm tốt trong nhận xét dưới đây: OPTIONS có giá trị không thể phủ nhận trong một số bối cảnh nhất định (ví dụ: CORS); Tôi chắc chắn không có ý định đề nghị khác.

— Hawkeye Parker
nguồn
4
Bài viết rất hay và đúng thẩm quyền, nhưng hãy xem phần "Tại sao HTTPbis lại để OPTIONS vào", và nhận xét. Với CORS, hệ thống REST phải có thể đáp ứng các TÙY CHỌN, đặc biệt nếu các API sẽ được sử dụng từ một ứng dụng web dựa trên JavaScript. Các khuôn khổ JS thường kích hoạt một yêu cầu tùy chọn "preflight" trước cuộc gọi HTTP thực.
— Sudhanshu Mishra
Tôi thấy các yêu cầu TÙY CHỌN khi tôi kết nối máy chủ http (tự viết) của mình từ Trình tìm kiếm macOS ( sử dụng Webdav ).
— Joe
7

Yêu cầu HTTP OPTIONS là gì?

Đó là một yêu cầu từ khách hàng để biết những gì HTTP phương pháp máy chủ sẽ cho phép, như GET, POSTvv

Yêu cầu

Yêu cầu có thể trông như thế này khi hỏi về các tùy chọn cho một tài nguyên cụ thể:

OPTIONS /index.html HTTP/1.1

hoặc như thế này khi hỏi về máy chủ nói chung:

OPTIONS * HTTP/1.1

Phản ứng

Phản hồi sẽ chứa một Allowtiêu đề với các phương thức được phép:

Allow: OPTIONS, GET, HEAD, POST

Tại sao máy chủ nhận được yêu cầu HTTP OPTIONS?

  • Một số API REST cần nó (nhưng nếu bạn đang xác định API, bạn sẽ biết điều đó)
  • Trình duyệt gửi nó đến máy chủ dưới dạng yêu cầu "được đánh dấu trước" để xem máy chủ có hiểu CORS không
  • Những kẻ tấn công gửi nó để lấy thêm thông tin về API

Làm cách nào để phản hồi yêu cầu HTTP OPTIONS?

  • Bạn có thể trả lời bằng Allowedtiêu đề và thậm chí ghi lại API của mình trong phần nội dung.
  • Bạn có thể trả lời với các Access-Control-Request-*tiêu đề bổ sung do CORS xác định .
  • Bạn có thể trả lời bằng 405 Method Not Allowedhoặc 501 Not Implemented.

Làm cách nào để ngừng nhận các yêu cầu HTTP OPTIONS?

  • Nếu nó đến từ một trình duyệt, hãy cập nhật API của bạn để nó không làm bất cứ điều gì "nguy hiểm" (như PUThoặc DELETE, hoặc POSTvới application/json). Chỉ thực hiện các yêu cầu đơn giản .

Xem thêm

— Suragch
nguồn
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookie và Chính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.