Với ngữ nghĩa bộ nhớ đệm rất đơn giản: nếu các tham số giống nhau (và URL giống nhau, tất nhiên), thì đó là lần truy cập. Điều đó có thể không? Được khuyến nghị?Có thể cache các phương thức POST trong HTTP không?
Tương ứng RFC 2616 trong phần 9.5 (POST) cho phép lưu bộ nhớ cache của phản hồi vào thư POST nếu bạn sử dụng tiêu đề thích hợp.
Câu trả lời cho phương pháp này không thể lưu vào bộ nhớ cache, trừ khi phản hồi bao gồm các trường tiêu đề Kiểm soát bộ nhớ cache hoặc Hết hạn thích hợp. Tuy nhiên, phản hồi 303 (Xem Khác) có thể được sử dụng để chỉ đạo tác nhân người dùng đến truy xuất tài nguyên có thể lưu vào bộ nhớ cache.
Lưu ý rằng RFC cùng khẳng định một cách rõ ràng trong phần 13 (Caching trong HTTP) mà một bộ nhớ cache phải vô hiệu hóa các thực thể tương ứng sau một yêu cầu POST .
Một số phương pháp HTTP PHẢI gây ra bộ nhớ cache để vô hiệu hóa thực thể. Đây là một trong hai thực thể được tham chiếu bởi Yêu cầu-URI hoặc theo Vị trí hoặc tiêu đề Nội dung-Vị trí (nếu có). Những phương pháp này bao gồm:
- PUT - DELETE - POST
Nó không rõ ràng với tôi như thế nào những thông số kỹ thuật có thể cho phép bộ nhớ đệm có ý nghĩa.
Tất nhiên điều đó là có thể. Nếu bạn muốn nhận các yêu cầu POST được gửi tới máy chủ của bạn và lưu trữ dữ liệu được gửi lại để được gửi lại sau - không có mồ hôi.
Phần phức tạp có liên quan đến "trạng thái". Làm cách nào để bạn quyết định dữ liệu bạn muốn gửi lại cho người dùng thực sự phải giống nhau? Điều gì xảy ra nếu cookie của anh ấy đã thay đổi - điều đó có thay đổi dữ liệu bạn muốn gửi lại không?
Nếu người dùng đã gửi yêu cầu POST đến trang chủ của bạn và kể từ lần cuối cùng anh ấy làm điều đó, một người dùng khác gửi cho anh ấy một tin nhắn (sử dụng một số hệ thống bên trong trang web của bạn.) Bạn phải xác định đó là một thay đổi -trạng thái và gửi phiên bản mới của trang chủ của bạn, với thông báo về tin nhắn cho người dùng vào lần tiếp theo anh tải trang chủ. Ngay cả khi các tham số POST giống nhau.
+1 cũng được lý luận ;-) –
Có thể, có. Vi phạm RFC 2616 (HTTP/1.1), cũng rất có thể. Phá vỡ/không hoạt động trong các trình duyệt mong đợi HTTP/1.1, có thể. Bạn chọn đi. – Piskvor
Nếu đó là thứ không thực sự thay đổi dữ liệu trên trang web của bạn, nó phải là yêu cầu GET. Ngay cả khi đó là một biểu mẫu, bạn vẫn có thể đặt nó làm yêu cầu nhận. Trong khi, như những người khác chỉ ra, bạn có thể lưu lại kết quả của một POST, nó sẽ không có ý nghĩa ngữ nghĩa bởi vì một POST theo định nghĩa đang thay đổi dữ liệu.
Yêu cầu POST có thể không thay đổi bất kỳ dữ liệu nào được sử dụng để tạo trang phản hồi, trong trường hợp đó, có thể có ý nghĩa để cache phản hồi. –
David Z: Chắc chắn nếu POST đang thay đổi dữ liệu thì phản hồi sẽ đưa ra một số dấu hiệu thành công/thất bại. Không yêu cầu chính xác, nhưng tôi không thể nghĩ ra một tình huống mà POST sẽ thay đổi dữ liệu và phản hồi là tĩnh. – Morvael
Nếu dữ liệu tham số quá dài, yêu cầu GET sẽ không hoạt động với tất cả các máy chủ, do đó POST là cần thiết, đặc biệt nếu nguồn sẽ chạy trên các máy chủ mà tác giả mã không định cấu hình. – gogowitsch
toàn thể:
Về cơ bản POST is not an idempotent operation. Vì vậy, bạn không thể sử dụng nó cho bộ nhớ đệm. GET nên là một hoạt động idempotent, vì vậy nó thường được sử dụng cho bộ nhớ đệm.
Vui lòng xem phần 9.1 của HTTP 1.1 RFC 2616 S. 9.1.
Khác với ngữ nghĩa GET phương pháp của:
Các phương thức POST chính nó là ngữ nghĩa có nghĩa là để gửi một cái gì đó tới một tài nguyên.POST không thể được lưu trữ bởi vì nếu bạn làm điều gì đó một lần so với hai lần so với ba lần, thì bạn đang thay đổi tài nguyên của máy chủ mỗi lần. Mỗi yêu cầu quan trọng và sẽ được gửi đến máy chủ.
Bản thân phương pháp PUT là ngữ nghĩa nhằm đặt hoặc tạo tài nguyên. Nó là một hoạt động idempotent, nhưng nó sẽ không được sử dụng cho bộ nhớ đệm vì DELETE có thể đã xảy ra trong thời gian chờ đợi.
Phương thức DELETE chính nó là ngữ nghĩa nhằm xóa tài nguyên. Nó là một hoạt động idempotent, nhưng nó sẽ không được sử dụng cho bộ nhớ đệm vì một PUT có thể đã xảy ra trong thời gian chờ đợi.
Về phía khách hàng bộ nhớ đệm:
Một trình duyệt web sẽ luôn đợi yêu cầu của bạn ngay cả khi nó có một phản ứng từ một hoạt động POST trước. Ví dụ: bạn có thể gửi email bằng gmail cách nhau vài ngày. Họ có thể là cùng một chủ đề và cơ thể, nhưng cả hai email nên được gửi đi.
Về proxy caching:
Một máy chủ proxy HTTP cho phép gửi các thông điệp của bạn đến máy chủ sẽ không bao giờ bộ nhớ cache bất cứ điều gì nhưng một GET hoặc một yêu cầu HEAD.
Về máy chủ bộ nhớ đệm:
Một máy chủ theo mặc định sẽ không tự động xử lý một yêu cầu POST qua kiểm tra bộ nhớ cache của nó. Nhưng tất nhiên một yêu cầu POST có thể được gửi đến ứng dụng của bạn hoặc bổ trợ và bạn có thể có bộ nhớ cache của riêng bạn mà bạn đọc từ khi các tham số là như nhau.
hủy bỏ hiệu lực một nguồn lực:
Kiểm tra HTTP 1.1 RFC 2616 S. 13.10 cho thấy phương thức POST nên vô hiệu hóa các nguồn lực cho bộ nhớ đệm.
"Về cơ bản POST không phải là một hoạt động idempotent. Vì vậy, bạn không thể sử dụng nó cho bộ nhớ đệm." Đó chỉ là sai, và nó không thực sự có ý nghĩa, xem câu trả lời của reBoot để biết chi tiết. Thật không may, tôi không thể downvote được nêu ra, nếu không tôi sẽ có. –
Eugene: Tôi đã thay đổi "không phải là" thành "có thể không". –
Cảm ơn Brian, điều đó nghe hay hơn. Vấn đề của tôi với "POST không idemp. -> của bạn không thể được lưu trữ" mặc dù là - và tôi đã không làm cho rõ ràng đủ - mặc dù một hoạt động không phải là idempotent đó không có nghĩa là nó không phải là cacheable. Tôi đoán câu hỏi là bạn nhìn vào nó từ quan điểm của máy chủ, người cung cấp dữ liệu và biết ngữ nghĩa của nó, hoặc bạn đang nhìn nó từ phía bên nhận (có thể là một proxy caching, vv hoặc một khách hàng) . Nếu đó là khách hàng/proxy pov, tôi hoàn toàn đồng ý với bài viết của bạn. Nếu đó là máy chủ pov, nếu máy chủ nói: "client có thể cache", hơn client có thể cache. –
Theo RFC 2616 Mục 9.5:
"Responses to POST phương pháp không cache, trừ trường hợp phản ứng bao gồm thích hợp Cache-Control hoặc Expires header".
Vì vậy, CÓ, bạn có thể cache phản hồi yêu cầu POST nhưng chỉ khi nó đến với tiêu đề thích hợp. Trong hầu hết các trường hợp, bạn không muốn cache phản hồi. Nhưng trong một số trường hợp - chẳng hạn như nếu bạn không lưu bất kỳ dữ liệu nào trên máy chủ - nó hoàn toàn thích hợp.
Lưu ý, tuy nhiên nhiều trình duyệt, bao gồm Firefox 3.0.10 hiện tại, sẽ không lưu lại phản hồi POST bất kể tiêu đề. IE hoạt động thông minh hơn trong lĩnh vực này.
Bây giờ, tôi muốn xóa một số nhầm lẫn ở đây liên quan đến RFC 2616 S. 13.10. Phương thức POST trên một URI không "làm mất hiệu lực tài nguyên cho bộ nhớ đệm" như một số đã nêu ở đây. Nó tạo ra một phiên bản được lưu trước đó của phiên bản cũ của URI, ngay cả khi các tiêu đề kiểm soát bộ nhớ cache của nó cho thấy độ mới của thời lượng dài hơn.
+1 khởi động lại, cảm ơn bạn đã giải thích vấn đề tiêu đề và cũng sửa các tuyên bố sai về 13,10. Đáng ngạc nhiên những câu trả lời sai đã nhận được rất nhiều phiếu bầu. –
Sự khác nhau giữa "làm mất hiệu lực tài nguyên cho bộ nhớ đệm" và "tạo phiên bản cache cũ của URI" là gì? Bạn có nói rằng máy chủ được phép lưu trữ một phản hồi POST nhưng khách hàng có thể không? – Gili
BÀI ĐĂNG được sử dụng trong Ajax trạng thái. Trả về một phản hồi được lưu trong bộ nhớ cache cho POST sẽ đánh bại kênh truyền thông và các tác dụng phụ của việc nhận tin nhắn. Điều này rất rất tệ. Nó cũng là một nỗi đau thực sự để theo dõi. Rất khuyến khích chống lại.
Một ví dụ nhỏ nhặt sẽ là một thông điệp rằng, như là một tác dụng phụ, trả lương 10.000 đô la cho tuần hiện tại. Bạn KHÔNG muốn nhận được "OK, nó đã đi qua!" trang đã được lưu trữ vào tuần trước. Các trường hợp thế giới thực khác phức tạp hơn dẫn đến sự vui nhộn tương tự.
Không thực sự là một câu trả lời - POST được sử dụng cho tất cả các loại sự vật và đôi khi có lý do hợp lệ để * muốn * để phản hồi bộ nhớ cache. –
Với firefox 27.0 & với httpfox, trên 19 tháng 5 năm 2014, tôi thấy một dòng này: 00: 03: 58,777 0,488 657 (393) POST (Cache) text/html https://users.jackiszhp.info/S4UP
Rõ ràng, phản hồi của một phương thức bài được lưu trữ, và nó cũng có trong https. Không thể tin được!
Mark Nottingham đã phân tích khi có khả năng cache phản hồi của POST. Lưu ý rằng các yêu cầu tiếp theo muốn tận dụng bộ nhớ đệm phải là các yêu cầu GET hoặc HEAD. Xem thêm httpbis
BÀI VIẾT không đại diện cho trạng thái xác định, 99 lần trong số 100. Tuy nhiên, có một trường hợp; khi máy chủ ra khỏi cách của nó để nói rằng phản hồi POST này là một biểu thị của URI của nó, bằng cách đặt tiêu đề Vị trí nội dung giống như yêu cầu URI. Khi điều đó xảy ra, phản hồi POST giống như một phản hồi GET tới cùng một URI; nó có thể được lưu trữ và sử dụng lại - nhưng chỉ cho các yêu cầu GET trong tương lai .
Nếu bạn lưu vào bộ nhớ cache phản hồi POST, nó phải theo hướng của ứng dụng web. Đây là ý nghĩa của "Câu trả lời cho phương thức này không thể lưu vào bộ nhớ cache, trừ khi câu trả lời bao gồm các trường tiêu đề Cache-Control hoặc Expires thích hợp."
Một cách an toàn có thể giả định rằng ứng dụng, biết liệu kết quả của POST có phải là ngẫu nhiên hay không, quyết định có đính kèm các tiêu đề kiểm soát bộ nhớ cache cần thiết và thích hợp hay không. Nếu các tiêu đề gợi ý cho phép lưu vào bộ nhớ đệm có mặt, ứng dụng sẽ cho bạn biết rằng POST là, trong thực tế, một siêu GET; rằng việc sử dụng POST chỉ được yêu cầu do số lượng dữ liệu không cần thiết và không liên quan (sử dụng URI dưới dạng khóa bộ nhớ cache) cần thiết để thực hiện thao tác idempotent.
Theo dõi GET có thể được phân phát từ bộ nhớ cache theo giả định này.
Ứng dụng không đính kèm các tiêu đề cần thiết và chính xác để phân biệt giữa các phản hồi POST có thể lưu vào bộ nhớ cache và không thể lưu trữ là do lỗi cho bất kỳ kết quả bộ nhớ đệm không hợp lệ nào.
Điều đó cho biết, mỗi POST truy cập bộ nhớ cache yêu cầu xác thực bằng các tiêu đề có điều kiện. Điều này là cần thiết để làm mới nội dung bộ nhớ cache để tránh việc có kết quả của một POST không được phản ánh trong các phản hồi cho các yêu cầu cho đến sau khi thời gian tồn tại của đối tượng hết hạn.
Phần này áp dụng cho bộ nhớ đệm trung gian (như máy chủ proxy bộ nhớ đệm), không phải máy chủ gốc. –
Đúng, nhưng chúng cũng có thể được diễn giải trong ngữ cảnh này (và chúng có ý nghĩa). –
Máy chủ gốc là một nhà môi giới giữa HTTP và ứng dụng xử lý các yêu cầu POST. Ứng dụng nằm ngoài ranh giới HTTP và nó có thể làm bất cứ điều gì nó thích.Nếu bộ nhớ đệm có ý nghĩa đối với một yêu cầu POST cụ thể, nó miễn phí cho bộ nhớ cache, nhiều như hệ điều hành có thể lưu trữ các yêu cầu đĩa. –