Sự khác biệt giữa không có bộ đệm và phải xác nhận lại

Từ RFC 2616

http://www.w3.org/Prot Protocol / rfc2616 / rfc2616-sec14.html # sec14.9.1

không có bộ nhớ cache

Nếu chỉ thị không có bộ đệm không chỉ định tên trường, thì bộ đệm KHÔNG PHẢI sử dụng phản hồi để đáp ứng yêu cầu tiếp theo mà không cần xác nhận lại thành công với máy chủ gốc. Điều này cho phép một máy chủ gốc ngăn chặn bộ nhớ đệm ngay cả bởi các bộ đệm đã được cấu hình để trả về các phản hồi cũ cho các yêu cầu của máy khách.

Vì vậy, nó chỉ đạo các đại lý để xác nhận lại tất cả các phản ứng.

So sánh với

phải xác nhận lại

Khi chỉ thị phải xác nhận lại xuất hiện trong phản hồi nhận được bởi bộ đệm, bộ đệm đó KHÔNG ĐƯỢC sử dụng mục nhập sau khi nó trở nên cũ để đáp ứng yêu cầu tiếp theo mà không xác nhận lại trước với máy chủ gốc

Vì vậy, nó chỉ đạo các đại lý để xác nhận lại các phản ứng cũ .

Đặc biệt liên quan đến no-cache, đây có phải là cách các tác nhân người dùng thực sự, thực nghiệm đối xử với chỉ thị này?

Quan điểm của no-cachenếu có must-revalidatevà là max-agegì?

Xem bình luận này:

http://palauge.plynt.com/issues/2008Jul/cache-control-attribut/

không có bộ nhớ cache

Mặc dù lệnh này nghe có vẻ như đang hướng dẫn trình duyệt không lưu bộ đệm vào trang, nhưng có một sự khác biệt tinh tế. Theo chỉ thị RFC, bộ nhớ cache không có bộ nhớ cache, cho trình duyệt biết rằng nó sẽ xác nhận lại với máy chủ trước khi phục vụ trang từ bộ đệm. Xác nhận lại là một kỹ thuật gọn gàng cho phép ứng dụng bảo tồn độ rộng băng tần. Nếu trang trình duyệt đã lưu trong bộ nhớ cache không thay đổi, máy chủ sẽ báo hiệu cho trình duyệt và trang được hiển thị từ bộ đệm. Do đó, trình duyệt (về lý thuyết, ít nhất), lưu trữ trang trong bộ đệm của nó, nhưng chỉ hiển thị nó sau khi xác nhận lại với máy chủ. Trong thực tế, IE và Firefox đã bắt đầu xử lý chỉ thị không có bộ đệm như thể nó chỉ thị cho trình duyệt không lưu bộ đệm vào trang. Chúng tôi bắt đầu quan sát hành vi này khoảng một năm trước.

Có ai có bất cứ điều gì chính thức hơn về điều này?

Cập nhật

Lệnh phải xác nhận lại phải được sử dụng bởi các máy chủ nếu và chỉ khi không xác thực yêu cầu trên đại diện có thể dẫn đến hoạt động không chính xác, chẳng hạn như một giao dịch tài chính âm thầm không được thực hiện.

Đó là điều mà tôi chưa bao giờ nghĩ đến cho đến bây giờ. RFC đang nói không sử dụng phải xác nhận lại một cách nhẹ nhàng. Vấn đề là, với các dịch vụ web, bạn phải có cái nhìn tiêu cực và cho rằng điều tồi tệ nhất đối với các ứng dụng khách chưa biết của bạn. Bất kỳ tài nguyên cũ có khả năng gây ra vấn đề.

Và một cái gì đó khác mà tôi vừa xem xét, không có Sửa đổi lần cuối hoặc ETags, trình duyệt chỉ có thể lấy lại toàn bộ tài nguyên. Tuy nhiên, với ETags, tôi đã quan sát thấy rằng Chrome ít nhất dường như xác nhận lại theo mọi yêu cầu. Điều này làm cho cả hai chỉ thị này không được đặt tên hoặc ít nhất là được đặt tên kém vì chúng không thể xác nhận lại một cách chính xác trừ khi yêu cầu cũng bao gồm các tiêu đề khác sau đó gây ra 'luôn luôn xác nhận lại'.

Tôi chỉ muốn làm cho điểm cuối cùng rõ ràng hơn. Bằng cách chỉ cài đặt must-revalidatenhưng không bao gồm ETag hoặc Sửa đổi lần cuối, đại lý chỉ có thể lấy lại nội dung vì nó không có gì để gửi đến máy chủ để so sánh.

Tuy nhiên, thử nghiệm theo kinh nghiệm của tôi đã chỉ ra rằng khi bao gồm dữ liệu tiêu đề hoặc sửa đổi ETag trong các phản hồi, các tác nhân luôn xác nhận lại bằng mọi cách, bất kể sự hiện diện của must-revalidatetiêu đề.

Vì vậy, quan điểm must-revalidatelà để buộc một 'bỏ qua bộ nhớ cache' khi nó đi cũ, mà chỉ có thể xảy ra khi bạn đã thiết lập một đời / tuổi, do đó nếu must-revalidateđược thiết lập trên một phản ứng không có tuổi hoặc tiêu đề khác, nó có hiệu quả trở nên tương đương với no-cachetừ các phản ứng sẽ được xem xét ngay lập tức cũ.

- Vì vậy, cuối cùng tôi sẽ đánh dấu câu trả lời của Gili!

Tôi tin rằng must-revalidatecó nghĩa là:

Khi bộ đệm hết hạn, hãy từ chối trả lại các phản hồi cũ cho người dùng ngay cả khi họ nói rằng các phản hồi cũ có thể chấp nhận được.

Trong khi đó no-cachengụ ý:

must-revalidate cộng với thực tế các phản ứng trở nên cũ kỹ ngay lập tức.

Nếu một phản hồi được lưu trong bộ nhớ cache trong 10 giây, sau đó must-revalidatekhởi động sau 10 giây, trong khi no-cachengụ ý must-revalidatesau 0 giây.

Ít nhất, đó là cách giải thích của tôi.

max-age=0, must-revalidatevà no-cachekhông hoàn toàn giống hệt nhau. Với must-revalidate, nếu máy chủ không đáp ứng yêu cầu xác nhận lại, trình duyệt / proxy có nghĩa vụ phải trả về lỗi 504. Với no-cache, nó sẽ chỉ hiển thị nội dung được lưu trong bộ nhớ cache, có thể sẽ được người dùng ưa thích (tốt hơn là có một cái gì đó cũ hơn là không có gì cả). Đây là lý do tại sao must-revalidatechỉ dành cho các giao dịch quan trọng.

Với cách giải thích của Jeffrey Fox no-cache, tôi đã thử nghiệm dưới chrome 52.0.2743.116 m, kết quả cho thấy no-cachecó hành vi tương tự must-revalidate, tất cả họ sẽ KHÔNG sử dụng bộ đệm cục bộ khi máy chủ không thể truy cập được và tất cả họ sẽ sử dụng bộ đệm trong khi quay lại trình duyệt / Nút chuyển tiếp khi máy chủ không thể truy cập. Như trên, tôi nghĩ max-age=0, must-revalidatelà giống hệt no-cache, ít nhất là trong việc thực hiện.

Tôi nghĩ rằng có một sự khác biệt giữa max-age=0, must-revalidatevà no-cache:

Trong must-revalidatetrường hợp khách hàng được phép gửi If-Modified-Sinceyêu cầu và phục vụ phản hồi từ bộ đệm nếu 304 Not Modifiedđược trả về.

Trong no-cachetrường hợp, máy khách không được lưu trữ phản hồi, vì vậy không nên sử dụng If-Modified-Since.