Bị lôi cuốn bởi sự phức tạp

Gần đây chúng tôi đã gặp phải một vấn đề thú vị khi chạy trang web mà chúng tôi đang xây dựng trên 'máy sao chép người dùng' nơi bạn có thể truy cập ứng dụng thông qua trình duyệt web chạy trên Citrix.

Vấn đề chúng tôi gặp phải là kết quả của một yêu cầu chuyển hướng bài đăng mà chúng tôi đã thực hiện thông qua plugin jQuery Form đã không cập nhật chính xác đoạn của trang. Có vẻ như nó đã thay thế nó bằng HTML gốc.

Chúng tôi đang chạy trên Internet Explorer 6 trên máy đó nhưng nó hoạt động tốt trên trình duyệt đó trên một vài máy phát triển của chúng tôi.

Chúng tôi đã quyết định tạm thời thay đổi mã để không thực hiện yêu cầu bài đăng và thay vào đó chỉ để trả lại trang mới trực tiếp từ POST. Mọi thứ được cập nhật chính xác bằng cách sử dụng phương pháp đó.

Đã đưa ra tất cả các lý thuyết lớn về cách vấn đề liên quan đến vấn đề nào đó liên quan đến thực tế là chúng tôi đang chạy qua Citrix, chúng tôi phần nào đã đến / được hướng dẫn một chút trong danh sách gửi thư nội bộ của Ian Robinson rằng trang này có lẽ đã bị lưu vào bộ nhớ cache bằng WinINet hoặc proxy công ty, bởi vì chúng tôi đã không đưa ra chỉ thị 'không lưu trữ' trong các tiêu đề của phản hồi.

không có cửa hàng

Mục đích của chỉ thị không lưu trữ là để ngăn chặn việc
vô tình phát hành hoặc lưu giữ thông tin nhạy cảm (
ví dụ: trên các băng dự phòng). Lệnh không có cửa hàng áp dụng cho
toàn bộ tin nhắn và CÓ THỂ được gửi trong phản hồi hoặc trong
yêu cầu. Nếu được gửi trong một yêu cầu, bộ đệm KHÔNG PHẢI lưu trữ bất kỳ phần nào của
yêu cầu này hoặc bất kỳ phản hồi nào đối với yêu cầu đó. Nếu được gửi trong phản hồi,
bộ đệm KHÔNG PHẢI lưu trữ bất kỳ phần nào của phản hồi này hoặc
yêu cầu đã gợi ra nó. Lệnh này áp dụng cho cả
bộ nhớ cache không chia sẻ và chia sẻ. "PHẢI KHÔNG lưu trữ" trong ngữ cảnh này có nghĩa là
bộ đệm KHÔNG PHẢI lưu trữ thông tin trong bộ nhớ
không bay hơi và PHẢI nỗ lực hết sức để
xóa thông tin khỏi bộ lưu trữ dễ bay hơi càng sớm càng
tốt sau khi chuyển tiếp nó.

Ngay cả khi lệnh này được liên kết với một phản hồi, người dùng
có thể lưu trữ rõ ràng một phản hồi như vậy bên ngoài
hệ thống bộ đệm (ví dụ: với hộp thoại "Lưu dưới dạng"). Bộ đệm lịch sử CÓ THỂ lưu trữ
các phản hồi như là một phần của hoạt động bình thường của chúng.

JKG đã đăng một số mã xác định một thuộc tính mà chúng ta có thể thực hiện trên các hành động mà chúng ta không muốn lưu vào bộ đệm trong ứng dụng ASP.NET MVC:

public class NoCache : ActionFilterAttribute, IActionFilter
{  
    public override void OnResultExecuting(ResultExecutingContext filterContext)
    {
        filterContext.HttpContext.Response.Cache.SetExpires(DateTime.UtcNow.AddDays(-1));
        filterContext.HttpContext.Response.Cache.SetValidUntilExpires(false);
        filterContext.HttpContext.Response.Cache.SetRevalidation(HttpCacheRevalidation.AllCaches);
        filterContext.HttpContext.Response.Cache.SetCacheability(HttpCacheability.NoCache);
        filterContext.HttpContext.Response.Cache.SetNoStore();
 
        base.OnResultExecuting(filterContext);
    }
 
    public override void OnResultExecuted(ResultExecutedContext filterContext)
    {
        base.OnResultExecuted(filterContext);
    }
}

Chúng tôi đặt mã đó vào và trang bắt đầu làm mới chính xác.

Chris Leishman chỉ ra rằng một cách tiếp cận khác sẽ là sử dụng ' ETags ' trên tiêu đề phản hồi để trang sẽ chỉ được truy xuất từ ​​máy chủ nếu nó thực sự thay đổi.

Dù bằng cách nào, chúng tôi thấy thật thú vị khi chúng tôi tự động cho rằng một cái gì đó phức tạp đã sai khi thực sự nó là bất cứ thứ gì nhưng!