Làm cách nào để ngăn lighttpd lưu các tệp tĩnh, ngay cả khi được sửa đổi trên đĩa?


10

Tôi đang sử dụng lighttpd để phục vụ các tệp tĩnh. Tôi có một loạt các hình ảnh trong một thư mục mà tôi thường xuyên cập nhật. Điều này sẽ thay đổi nội dung tệp (và kích thước tệp) cũng như ngày sửa đổi, nhưng không phải tên tệp của chúng.

Khi tôi truy cập các tệp qua http, các bản cập nhật không được tính đến và nhẹ nhàng phục vụ tệp cũ. Tôi có thể tự đổi tên tệp thành một cái gì đó khác, sau đó lighttpd sẽ trả về lỗi 404 và nếu tôi đổi tên tệp của mình trở lại, tôi sẽ nhận được phiên bản cập nhật chính xác. Có vẻ như lightty đang sử dụng một số loại cơ chế bộ đệm của riêng mình (điều này tốt) để trả về các tệp tĩnh. Thật không may, có vẻ như cơ chế này không tự cập nhật khi các tệp được sửa đổi.

Tôi đã kiểm tra thông qua Wireshark và trình duyệt của tôi thực sự đang yêu cầu tệp, đây không phải là vấn đề về bộ nhớ đệm của trình duyệt. Nó trả về 200 OK khi yêu cầu nó từ bộ đệm trống và 304 Không được sửa đổi theo cách khác, như mong đợi. Nhưng tệp được trả về với tiêu đề Sửa đổi lần cuối sai, không phản ánh ngày sửa đổi cuối cùng thực sự.

Có lẽ có một số chỉ thị cấu hình mà tôi không biết?

Tôi muốn các tệp được trả về bằng ánh sáng để phản ánh trực tiếp các thay đổi được thực hiện trên đĩa hoặc ít nhất là có thể làm mất hiệu lực bộ đệm của nó.

Cập nhật cho bất cứ ai theo dõi câu hỏi này: Tôi tìm thấy một thủ phạm. Nếu tôi cập nhật một tệp tĩnh, Lighty không trả về nội dung mới, nhưng sẽ trả về Độ dài nội dung mới trong các tiêu đề của nó, dẫn đến rác được hiển thị. Nếu tôi nén tệp bằng mod_compress, vấn đề sẽ biến mất khi mod_compress sử dụng hệ thống bộ đệm riêng của nó. Thật không may, tôi không thể nén tất cả các tệp (ví dụ: tệp hình ảnh). Vì vậy, nó chỉ là một sửa chữa một phần, nhưng tôi sẽ quay lại với nó sau và sẽ cẩn thận tìm ra giải pháp.

Câu trả lời:


6

Cuối cùng tôi đã tìm thấy vấn đề. Và nó đến từ VirtualBox.

Khi chỉnh sửa tệp trong Máy chủ (Win), lighttpd trong máy khách (Linux) không cập nhật chính xác nội dung tệp (nhưng cập nhật chính xác kích thước tệp), do đó trả về nội dung bị cắt hoặc bị cắt xén.

Ngắt kết nối các ổ đĩa được chia sẻ của tôi và gắn lại chúng hoặc chỉnh sửa các tệp trực tiếp trong máy khách, đã khắc phục sự cố.

Tôi đã mất 6 tháng để tìm ra điều đó.


3

Bạn không đề cập đến việc bạn đã cài đặt mod_cache hay chưa? Mô-đun này mặc định là 'được bật' khi được cài đặt.

Tôi không thích đề xuất nó, nhưng bật Etags có giúp được không?


mod_cache chưa được cài đặt. ETags được kích hoạt (nhưng inode không được sử dụng để tạo ETag). Tôi đã thử kích hoạt inode hoặc vô hiệu hóa ETag nhưng không có kết quả.
Pixelastic

2

Hãy thử đặt bộ nhớ đệm động cơ stat thành 'bị vô hiệu hóa':

server.stat-cache-engine = "disable'

Cảm ơn, nhưng điều này không có tác dụng. Tuy nhiên, tôi không biết chỉ thị đó và nó có thể có ích sau này.
Pixelastic

Có thể có một proxy trung gian giữa bạn và máy chủ? Hãy thử khởi động lại máy chủ của bạn và truy cập cùng một tệp. Bạn đang sử dụng mod_compress?
Aleksey Korzun

Tôi đang chạy Ubuntu VM trong máy chủ Windows 7. Lighty là trong VM. Tôi không nghĩ rằng có thể có một vấn đề proxy ở đây. Tôi đã khởi động lại máy chủ, nhưng điều này không xóa bộ nhớ cache nhẹ. Tôi đang sử dụng mod_compress nhưng không phải trên các tệp đó. Tôi sẽ thử khởi động lại toàn bộ VM và vô hiệu hóa mod_compress để xem nó có thay đổi gì không. Cảm ơn các ý tưởng.
Pixelastic

Hmm, tôi có thể có một cái gì đó ở đây. Nếu tôi thay đổi tệp thành một tệp nhỏ hơn (nhưng vẫn giữ nguyên tên), tôi chỉ nhận được nửa trên của tệp. Có vẻ như tệp cũ được hiển thị với độ dài nội dung của tệp hiện tại. Nếu tôi thay thế bằng một tệp lớn hơn, toàn bộ tệp (cũ) sẽ được hiển thị. Có vẻ như các thay đổi kích thước tệp được đưa vào tài khoản nhưng không phải là nội dung tệp.
Pixelastic

Xin lỗi vì spam bình luận: vô hiệu hóa mod_compress không thay đổi bất cứ điều gì, cũng như không khởi động lại toàn bộ VM.
Pixelastic

2

Tùy chọn lighttpd này làm việc cho tôi

server.network-backend = "writev" 

Làm việc như một cơ duyên đối với tôi, trên máy ảo Debian trên máy tính để bàn Debian, cảm ơn!
Yvan

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 cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.