Khi kiểm tra website bằng DevTools, bạn có thể bắt gặp HTTP status code 304 Not Modified và dễ nhầm rằng đây là một lỗi cần khắc phục. Thực tế, 304 là một phản hồi hợp lệ được sử dụng trong cơ chế caching, giúp trình duyệt tận dụng lại tài nguyên đã lưu thay vì tải lại toàn bộ dữ liệu từ server. Cơ chế này không chỉ giảm lượng dữ liệu truyền tải mà còn góp phần cải thiện tốc độ tải trang và giảm tải cho máy chủ. Vậy 304 Not Modified là gì, hoạt động như thế nào và có ý nghĩa gì đối với hiệu suất website? Trong bài viết này, chúng ta sẽ cùng tìm hiểu cơ chế Cache Validation, vai trò của ETag, Last-Modified và cách tối ưu caching để tận dụng HTTP status 304 hiệu quả.
- 304 Not Modified là gì?
- Ý nghĩa của 304 Not Modified status code
- Cơ chế Cache Validation và cách mã 304 hoạt động
- Phân biệt HTTP status 304 với 200, 301 và 302
- Cách kiểm tra HTTP 304 Not Modified status code trên website
- Lợi ích của HTTP status 304 đối với website
- Làm thế nào để biết 304 status code xuất hiện bất thường?
- Đánh giá nguyên nhân gây ra lỗi 304 status code không mong muốn
- Hướng dẫn khắc phục sự cố 304 Not Modified cho người dùng và quản trị viên
- Cách tối ưu caching để tận dụng HTTP status 304 hiệu quả
- Một số câu hỏi thường gặp về 304 Not Modified status code
- 1. Mã HTTP status 304 Not Modified có phải là lỗi (error) không?
- 2. Làm sao để biết website đang trả về mã 304 status code đúng cách?
- 3. Tại sao đã sửa nội dung bài viết, giao diện nhưng website vẫn trả về mã 304?
- 4. ETag và Last-Modified có vai trò gì trong 304 Not Modified?
- 5. Khi nào lập trình viên NÊN và KHÔNG NÊN cho phép trả về mã HTTP status 304?
304 Not Modified là gì?
304 Not Modified là một HTTP status code cho biết tài nguyên mà client yêu cầu chưa thay đổi so với phiên bản đang được lưu trong cache. Khi server xác nhận tài nguyên vẫn còn hợp lệ, nó trả về phản hồi 304 thay vì gửi lại toàn bộ nội dung. Trình duyệt khi đó có thể sử dụng phiên bản tài nguyên đã lưu để tiếp tục hiển thị hoặc xử lý. Cơ chế này giúp hạn chế truyền lại những dữ liệu không thay đổi, qua đó giảm băng thông, giảm tải cho server và cải thiện tốc độ phản hồi. Tuy nhiên, phản hồi 304 Not Modified không chứa nội dung tài nguyên mới; client cần sử dụng bản sao tương ứng đã có trong cache.
Mã 304 thường được sử dụng trong Cache Validation, kết hợp với các HTTP Header như ETag và Last-Modified. Dựa trên những thông tin này, server có thể xác định tài nguyên đã thay đổi hay chưa và quyết định trả về 304 Not Modified hoặc gửi phiên bản mới. Quan trọng hơn, 304 Not Modified không phải là lỗi mà là một cơ chế hợp lệ được sử dụng để tối ưu hiệu suất và hoạt động caching của website.
Ý nghĩa của 304 Not Modified status code
Mã 304 Not Modified không chỉ đơn thuần là một HTTP status code mà còn đóng vai trò quan trọng trong cơ chế caching của website. Khi server trả về mã này, trình duyệt có thể sử dụng lại tài nguyên đã lưu thay vì tải lại dữ liệu.
1. 304 không phải là lỗi
304 Not Modified không phải là lỗi mà là một phản hồi HTTP thuộc nhóm 3xx - Redirection, được sử dụng trong quá trình kiểm tra cache. Mặc dù nằm trong nhóm 3xx, 304 có ý nghĩa khá đặc biệt vì nó không yêu cầu client chuyển hướng sang một URL khác.
Khi nhận được 304, trình duyệt hiểu rằng tài nguyên chưa thay đổi và có thể tiếp tục sử dụng phiên bản đang được lưu trong cache. Vì vậy, việc nhìn thấy status code 304 trong DevTools không đồng nghĩa website đang gặp sự cố. Đây thường là dấu hiệu cho thấy cơ chế HTTP caching đang hoạt động đúng.
2. 304 có phải là redirect không?
304 Not Modified không phải là redirect theo nghĩa thông thường. Các mã như 301 Moved Permanently hoặc 302 Found thường yêu cầu client truy cập đến một URL khác, trong khi 304 không cung cấp nội dung mới và cũng không yêu cầu chuyển sang địa chỉ khác.
HTTP status 304 chỉ cho client biết rằng tài nguyên được yêu cầu không có thay đổi so với phiên bản đã cache. Trình duyệt có thể sử dụng bản sao cục bộ thay vì thực hiện lại quá trình tải dữ liệu từ server. Do đó, dù thuộc nhóm status code 3xx, 304 chủ yếu phục vụ cơ chế xác thực cache, không phải điều hướng người dùng.
3. Khi nào server trả về 304 status code?
Server thường trả về 304 status code khi client gửi request có điều kiện để kiểm tra xem tài nguyên đã thay đổi hay chưa. Hai cơ chế phổ biến là sử dụng If-None-Match kết hợp với ETag và If-Modified-Since kết hợp với Last-Modified.
Ví dụ, trình duyệt đã lưu một file CSS và gửi request mới kèm If-None-Match chứa giá trị ETag của phiên bản đang lưu. Server kiểm tra ETag hiện tại. Nếu tài nguyên chưa thay đổi, server trả về 304 Not Modified thay vì gửi lại toàn bộ file CSS. Trình duyệt sau đó sử dụng phiên bản đã có trong cache.
Ngược lại, nếu tài nguyên đã được cập nhật, server sẽ trả về nội dung mới, thường đi kèm 200 OK, để client thay thế phiên bản cũ. Cơ chế này giúp website tận dụng cache hiệu quả mà vẫn đảm bảo người dùng nhận được tài nguyên mới khi nội dung thực sự thay đổi.
Cơ chế Cache Validation và cách mã 304 hoạt động
Cache Validation là cơ chế giúp trình duyệt kiểm tra xem tài nguyên đã lưu trong cache có còn mới hay không trước khi tải lại từ server. Thay vì luôn yêu cầu server gửi toàn bộ dữ liệu, trình duyệt có thể gửi thông tin xác thực của phiên bản đang lưu thông qua các HTTP Header như ETag hoặc Last-Modified. Cơ chế Cache Validation hoạt động như thế nào? Cùng tìm hiểu chi tiết ngay sau đây!
1. Khái niệm Cache Validation (Xác thực Bộ nhớ tạm)
Cache Validation là cơ chế kiểm tra tính hợp lệ và mức độ cập nhật của tài nguyên đang được lưu trong cache của client. Khi trình duyệt đã lưu một tài nguyên như HTML, CSS, JavaScript hoặc hình ảnh, nó có thể sử dụng lại tài nguyên này cho những lần truy cập tiếp theo thay vì tải lại từ đầu.
Khi cần xác định tài nguyên trong cache có còn mới hay không, trình duyệt gửi một conditional request đến server kèm thông tin nhận diện phiên bản tài nguyên. Server sẽ so sánh thông tin này với phiên bản hiện tại. Nếu tài nguyên chưa thay đổi, server trả về 304 Not Modified để yêu cầu trình duyệt tiếp tục sử dụng bản cache. Nếu tài nguyên đã thay đổi, server trả về nội dung mới, thường với 200 OK.
2. Bộ cặp HTTP Header quyết định cơ chế Cache Validation
Trong Cache Validation, client và server sử dụng các cặp HTTP header để xác định tài nguyên trong cache có còn hợp lệ hay cần tải phiên bản mới. Hai phương pháp phổ biến nhất là phương pháp xác thực theo thời gian thông qua Last-Modified và If-Modified-Since hoặc phương pháp xác thực theo mã định danh thông qua ETag và If-None-Match. Mỗi phương pháp có cách xác định sự thay đổi của tài nguyên khác nhau nhưng đều có thể dẫn đến phản hồi 304 Not Modified khi nội dung chưa được cập nhật.
Phương pháp xác thực theo thời gian (Time-based validation)
Time-based validation là phương pháp kiểm tra tài nguyên trong cache dựa trên thời điểm tài nguyên được cập nhật lần cuối. Cơ chế này chủ yếu sử dụng hai HTTP header là Last-Modified và If-Modified-Since.
Có thể hiểu quy trình đơn giản như sau:
(1) Server gửi thời gian cập nhật tài nguyên
Khi trình duyệt tải một tài nguyên, chẳng hạn file CSS, server có thể gửi kèm header Last-Modified để thông báo thời điểm tài nguyên được chỉnh sửa lần cuối.
(2) Trình duyệt lưu thông tin vào cache
Trình duyệt lưu tài nguyên cùng thời gian Last-Modified để sử dụng trong những lần truy cập tiếp theo.
(3) Trình duyệt kiểm tra tài nguyên khi cần
Khi muốn sử dụng lại tài nguyên, trình duyệt gửi request đến server và thêm header If-Modified-Since, chứa thời điểm cập nhật mà trình duyệt đã lưu.
(4) Server so sánh thời gian
Server kiểm tra xem tài nguyên có được cập nhật sau thời điểm được gửi trong If-Modified-Since hay không.
(5) Server trả về kết quả phù hợp
- Nếu tài nguyên chưa thay đổi, server trả về 304 Not Modified. Trình duyệt sử dụng lại bản cache hiện có.
- Nếu tài nguyên đã thay đổi, server gửi phiên bản mới, thường với 200 OK.
Ví dụ, một file style.css có Last-Modified là ngày 25/08/2026. Khi trình duyệt gửi request với If-Modified-Since: 25/08/2026, nếu server xác nhận file vẫn chưa được chỉnh sửa, nó trả về 304 Not Modified thay vì gửi lại toàn bộ file. Nhờ đó, Time-based validation giúp hạn chế truyền lại những tài nguyên chưa thay đổi, từ đó tiết kiệm băng thông và cải thiện hiệu suất tải website.
Phương pháp xác thực theo mã định danh (ETag-based validation)
ETag-based validation là phương pháp kiểm tra tài nguyên trong cache dựa trên một mã định danh (ETag) do server tạo ra cho từng phiên bản của tài nguyên. Thay vì dựa vào thời gian cập nhật, server sử dụng ETag để xác định nội dung hiện tại có giống với phiên bản mà trình duyệt đang lưu hay không.
Có thể hiểu cơ chế này qua các bước đơn giản:
(1) Server tạo ETag cho tài nguyên
Khi trình duyệt tải một tài nguyên, chẳng hạn file style.css, server gửi kèm header ETag để xác định phiên bản của file.
(2) Trình duyệt lưu ETag cùng tài nguyên
Trình duyệt lưu file vào cache và ghi nhớ giá trị ETag nhận được từ server.
(3) Trình duyệt gửi ETag khi kiểm tra lại
Khi cần xác thực tài nguyên, trình duyệt gửi request kèm header If-None-Match, chứa giá trị ETag đã lưu.
(4) Server so sánh ETag
Server so sánh ETag trong If-None-Match với ETag hiện tại của tài nguyên.
- Nếu ETag giống nhau, tài nguyên chưa thay đổi → Server trả về 304 Not Modified.
- Nếu ETag khác nhau, tài nguyên đã thay đổi → Server gửi phiên bản mới, thường với 200 OK.
Ví dụ, trình duyệt đang lưu style.css với ETag là "abc123". Khi gửi request mới, trình duyệt gửi If-None-Match: "abc123". Nếu server xác định file vẫn có cùng ETag, server chỉ trả về 304 Not Modified, giúp trình duyệt tiếp tục sử dụng file trong cache. ETag giúp server xác định chính xác hơn phiên bản của tài nguyên, hạn chế truyền lại dữ liệu không cần thiết và góp phần cải thiện hiệu suất website.
3. Quy trình 4 bước xử lý mã 304 Not Modified
304 Not Modified được tạo ra thông qua quá trình trao đổi giữa trình duyệt và server để kiểm tra phiên bản tài nguyên đang được lưu trong cache. Quy trình này thường diễn ra qua 4 bước, bắt đầu từ lần truy cập đầu tiên khi tài nguyên được tải về đến những lần truy cập tiếp theo khi trình duyệt gửi yêu cầu kiểm tra lại. Hiểu rõ từng bước giúp dễ dàng hình dung cách Cache Validation hoạt động và lý do server trả về mã 304.
Bước 1: Lần truy cập đầu - 200 OK
Khi người dùng truy cập website lần đầu, trình duyệt chưa có tài nguyên cần thiết trong cache nên phải gửi request đến server để yêu cầu dữ liệu. Server xử lý request và trả về tài nguyên tương ứng, chẳng hạn như HTML, CSS, JavaScript hoặc hình ảnh, cùng với status code 200 OK.
Trong response, server có thể gửi thêm các HTTP header như ETag hoặc Last-Modified để xác định phiên bản và thời điểm cập nhật của tài nguyên. Những thông tin này sẽ được trình duyệt lưu lại và sử dụng cho quá trình Cache Validation ở những lần truy cập sau.
Bước 2: Lưu trữ cache
Sau khi nhận được response từ server, trình duyệt sẽ lưu trữ tài nguyên vào cache nếu các quy tắc caching cho phép. Các tài nguyên như HTML, CSS, JavaScript, hình ảnh hoặc font có thể được lưu lại để sử dụng trong những lần truy cập tiếp theo.
Bên cạnh nội dung tài nguyên, trình duyệt cũng có thể lưu các thông tin xác thực như ETag hoặc Last-Modified. Những dữ liệu này giúp trình duyệt gửi yêu cầu kiểm tra phiên bản tài nguyên với server thay vì phải tải lại toàn bộ nội dung. Nhờ cơ chế này, khi người dùng quay lại website, trình duyệt có thể tận dụng dữ liệu đã lưu trong cache, từ đó giảm số lượng dữ liệu phải tải xuống và cải thiện tốc độ phản hồi của website.
Bước 3: Lần truy cập sau - Yêu cầu có điều kiện / Conditional Request
Khi người dùng truy cập lại website, trình duyệt kiểm tra tài nguyên đã được lưu trong cache. Nếu cần xác thực lại với server, trình duyệt sẽ gửi một Conditional Request thay vì yêu cầu tải lại toàn bộ tài nguyên.
Trong request này, trình duyệt gửi thông tin về phiên bản tài nguyên đã lưu thông qua các HTTP header như If-None-Match hoặc If-Modified-Since. Server dựa vào những thông tin này để kiểm tra xem tài nguyên hiện tại có thay đổi so với phiên bản mà trình duyệt đang lưu hay không.
Nếu tài nguyên chưa thay đổi, server có thể trả về 304 Not Modified. Khi đó, trình duyệt sử dụng lại phiên bản đã lưu trong cache, giúp giảm dữ liệu truyền tải và rút ngắn thời gian tải tài nguyên.
Bước 4: Đối soát & phản hồi 304
Sau khi nhận Conditional Request, server sẽ đối chiếu thông tin mà trình duyệt gửi lên với phiên bản hiện tại của tài nguyên. Kiểm tra thường dựa trên ETag thông qua If-None-Match hoặc thời gian cập nhật thông qua If-Modified-Since.
- Nếu server xác định tài nguyên chưa thay đổi, server trả về 304 Not Modified và không cần gửi lại phần nội dung của tài nguyên. Trình duyệt khi đó sử dụng phiên bản đã lưu trong cache để hiển thị hoặc xử lý.
- Ngược lại, nếu tài nguyên đã thay đổi, server sẽ gửi nội dung phiên bản mới, thường đi kèm 200 OK, để trình duyệt cập nhật lại cache. Nhờ cơ chế này, website không phải truyền lại những dữ liệu đã có sẵn, góp phần tiết kiệm băng thông và cải thiện hiệu suất tải trang.
Phân biệt HTTP status 304 với 200, 301 và 302
Các HTTP status code 200, 304, 301 và 302 đều được sử dụng để phản hồi request từ client nhưng có mục đích khác nhau. 200 OK cho biết request thành công và server trả về tài nguyên, 304 Not Modified cho phép client sử dụng lại dữ liệu trong cache, còn 301 và 302 được sử dụng để chuyển hướng đến URL khác.
| Tiêu chí | 200 OK | 304 Not Modified | 301 Moved Permanently | 302 Found |
| Ý nghĩa | Request được xử lý thành công. | Tài nguyên chưa thay đổi. | Tài nguyên đã chuyển sang URL mới vĩnh viễn. | Tài nguyên tạm thời được chuyển sang URL khác. |
| Mục đích | Trả về tài nguyên được yêu cầu. | Tận dụng tài nguyên đã lưu trong cache. | Chuyển hướng vĩnh viễn. | Chuyển hướng tạm thời. |
| Server gửi nội dung? | Có. | Không, client dùng bản cache. | Thường không cần gửi lại tài nguyên cũ. | Thường không cần gửi lại tài nguyên cũ. |
| Có chuyển hướng? | Không. | Không. | Có. | Có. |
| Liên quan đến cache? | Có thể. | Có, là mục đích chính. | Có thể. | Có thể. |
| URL có thay đổi? | Không. | Không. | Có. | Có. |
| Ví dụ | Trình duyệt tải example.com/about thành công. | File CSS chưa thay đổi nên dùng bản cache. | /old-page chuyển vĩnh viễn sang /new-page. | /promotion tạm thời chuyển sang /sale. |
Cách kiểm tra HTTP 304 Not Modified status code trên website
HTTP 304 Not Modified status code có thể được kiểm tra trực tiếp thông qua công cụ dành cho lập trình viên trên trình duyệt. Khi kiểm tra, cần quan sát cả status code, Request Headers và Response Headers để xác định trình duyệt có gửi yêu cầu xác thực cache hay server có thực sự phản hồi 304 hay không.
1. Kiểm tra bằng Chrome DevTools
Để kiểm tra website có trả về 304 Not Modified hay không, bạn có thể thực hiện theo các bước sau:
Bước 1: Mở Chrome DevTools
Bạn truy cập website cần kiểm tra trên Google Chrome, sau đó nhấn F12 hoặc Ctrl + Shift + I trên Windows/Linux (Cmd + Option + I trên macOS) để mở Chrome DevTools.
Bước 2: Mở tab Network
Trong giao diện DevTools, bạn chọn tab Network. Đây là nơi hiển thị toàn bộ request mà trình duyệt gửi đến server khi tải website.
Bước 3: Tải lại trang
Sau đó, nhấn Ctrl + R hoặc nút Reload để tải lại trang. Bạn cũng có thể nhấn Ctrl + Shift + R để thực hiện hard reload khi cần kiểm tra lại hành vi tải tài nguyên.
Bước 4: Kiểm tra cột Status
Bạn quan sát cột Status trong danh sách request và tìm các tài nguyên như .css, .js, hình ảnh hoặc các file khác có status 304. Nếu xuất hiện 304 Not Modified, điều đó cho thấy server xác nhận tài nguyên chưa thay đổi và trình duyệt có thể sử dụng phiên bản đã lưu trong cache.
Bước 5: Kiểm tra HTTP Header
Bạn nhấp vào request có status 304, sau đó chuyển sang tab Headers. Tại đây, bạn có thể kiểm tra các header liên quan đến cache validation như:
- If-None-Match: Được client gửi lên để đối chiếu với ETag hiện tại của tài nguyên.
- If-Modified-Since: Cho server biết thời điểm tài nguyên được lưu hoặc cập nhật lần cuối.
- ETag: Mã định danh của một phiên bản tài nguyên.
- Last-Modified: Thời điểm server xác định tài nguyên được chỉnh sửa gần nhất.
- Cache-Control: Quy định cách trình duyệt và các cache trung gian xử lý tài nguyên.
2. Kiểm tra Request Headers
Sau khi mở Chrome DevTools → Network, bạn chọn request của tài nguyên muốn kiểm tra, chẳng hạn file CSS, JavaScript hoặc hình ảnh. Tiếp theo, chuyển sang tab Headers và tìm phần Request Headers. Đây là nơi hiển thị những thông tin mà trình duyệt gửi đến server trong quá trình xác thực tài nguyên được lưu trong cache.
Khi kiểm tra HTTP 304, cần chú ý hai header quan trọng:
- If-None-Match: Chứa giá trị ETag của phiên bản tài nguyên mà trình duyệt đang lưu. Server sẽ sử dụng giá trị này để kiểm tra xem tài nguyên hiện tại có giống với phiên bản trong cache hay không.
- If-Modified-Since: Chứa thời điểm cập nhật gần nhất của tài nguyên mà trình duyệt đã lưu. Server dựa vào thông tin này để xác định tài nguyên có được thay đổi kể từ thời điểm đó hay chưa.
3. Kiểm tra Response Headers
Sau khi chọn request trong Chrome DevTools → Network, chuyển đến tab Headers và tìm phần Response Headers. Đây là nơi hiển thị các thông tin mà server trả về sau khi xử lý request, giúp xác định tài nguyên có được xác thực và sử dụng lại từ cache hay không.
Khi kiểm tra 304 Not Modified, cần chú ý một số header quan trọng:
- ETag: Mã định danh đại diện cho một phiên bản cụ thể của tài nguyên. Giá trị này có thể được sử dụng để đối chiếu với If-None-Match trong request.
- Last-Modified: Cho biết thời điểm tài nguyên được server cập nhật lần cuối.
- Cache-Control: Xác định các quy tắc liên quan đến việc lưu trữ và sử dụng tài nguyên trong cache.
- Expires: Cho biết thời điểm tài nguyên được xem là hết hạn trong một số cơ chế caching.
Quan trọng nhất, bạn hãy kiểm tra Status Code của request. Nếu kết quả là 304 Not Modified, server xác nhận tài nguyên chưa thay đổi và không cần gửi lại nội dung. Trình duyệt sẽ sử dụng phiên bản đã lưu trong cache, giúp giảm dữ liệu truyền tải và cải thiện hiệu suất website.
Lợi ích của HTTP status 304 đối với website
HTTP status 304 Not Modified không chỉ giúp trình duyệt tận dụng dữ liệu đã lưu trong cache mà còn góp phần cải thiện hiệu suất tổng thể của website. Khi tài nguyên chưa thay đổi, server chỉ cần xác nhận trạng thái thay vì gửi lại toàn bộ nội dung. Nhờ đó, website có thể giảm lượng dữ liệu truyền tải, hạn chế tài nguyên máy chủ phải xử lý và mang đến trải nghiệm truy cập nhanh, ổn định hơn.
1. Tối ưu tốc độ tải trang
Một trong những lợi ích rõ rệt nhất của 304 Not Modified là giúp website giảm thời gian tải các tài nguyên đã được trình duyệt lưu trong cache. Khi người dùng truy cập website lần đầu, trình duyệt sẽ tải các tài nguyên như CSS, JavaScript, hình ảnh, font hoặc các file tĩnh khác và lưu chúng theo chính sách cache. Ở những lần truy cập sau, nếu tài nguyên vẫn chưa thay đổi, trình duyệt có thể gửi Conditional Request để kiểm tra với server.
Nếu server xác nhận tài nguyên chưa được cập nhật, nó trả về 304 Not Modified thay vì gửi lại toàn bộ nội dung. Trình duyệt sau đó sử dụng phiên bản đã lưu trong cache. Điều này giúp giảm lượng dữ liệu cần tải xuống và hạn chế thời gian chờ khi website phải lấy lại những tài nguyên đã có sẵn. Lợi ích này đặc biệt rõ rệt với những website có nhiều tài nguyên tĩnh hoặc người dùng thường xuyên quay lại cùng một trang.
2. Tiết kiệm tài nguyên máy chủ & băng thông
304 Not Modified giúp giảm lượng dữ liệu mà server phải truyền đến client. Thay vì gửi lại toàn bộ nội dung của một tài nguyên, server chỉ cần xử lý Conditional Request, kiểm tra thông tin như ETag hoặc Last-Modified và trả về phản hồi 304 nếu tài nguyên chưa thay đổi.
Ví dụ, một file JavaScript có dung lượng vài trăm KB đã được trình duyệt lưu trong cache. Khi người dùng truy cập lại website, nếu file này chưa được cập nhật, server có thể trả về 304 thay vì truyền lại toàn bộ file. Với một request đơn lẻ, lượng dữ liệu tiết kiệm được có thể không quá lớn, nhưng khi website có hàng nghìn hoặc hàng triệu request, mức giảm tải có thể trở nên đáng kể.
3. Hỗ trợ SEO và crawl budget
304 Not Modified không phải là yếu tố xếp hạng SEO trực tiếp, nhưng cơ chế này có thể mang lại một số lợi ích gián tiếp cho website, đặc biệt khi website có quy mô lớn và thường xuyên được công cụ tìm kiếm thu thập dữ liệu. Khi crawler truy cập lại website và tài nguyên chưa thay đổi, phản hồi 304 cho phép hệ thống tránh truyền lại những dữ liệu không cần thiết. Điều này có thể giúp quá trình thu thập dữ liệu sử dụng tài nguyên hiệu quả hơn. Với các website lớn có hàng nghìn hoặc hàng triệu URL, tối ưu cách server phản hồi các request lặp lại có thể trở nên đáng chú ý.
Đặc biệt, crawl budget liên quan đến cách công cụ tìm kiếm phân bổ tài nguyên để thu thập dữ liệu website. Sử dụng HTTP Status 304 hợp lý có thể giúp giảm lượng dữ liệu cần truyền trong những lần crawler kiểm tra lại các tài nguyên không thay đổi.
Làm thế nào để biết 304 status code xuất hiện bất thường?
304 Not Modified vốn là một phản hồi HTTP bình thường trong cơ chế cache validation, vì vậy website xuất hiện nhiều mã 304 không đồng nghĩa với lỗi. Để xác định 304 status code có xuất hiện bất thường hay không, cần xem xét đồng thời status code, HTTP headers, thời gian cache và hành vi thực tế của website.
1. Nội dung website không cập nhật dù đã thay đổi
Một dấu hiệu dễ nhận biết là nội dung hoặc tài nguyên trên website đã được cập nhật nhưng trình duyệt vẫn hiển thị phiên bản cũ. Ví dụ, quản trị viên đã thay đổi file CSS, JavaScript hoặc hình ảnh nhưng sau khi tải lại trang, người dùng vẫn nhìn thấy phiên bản trước đó.
Trong trường hợp này, cần kiểm tra ETag, Last-Modified, Cache-Control và các header liên quan đến cache. Nếu server liên tục xác nhận tài nguyên là "Not Modified" trong khi nội dung thực tế đã thay đổi, cấu hình cache validation có thể đang gặp vấn đề.
2. 304 xuất hiện quá nhiều ở những tài nguyên đáng lẽ phải được cập nhật
Không có một tỷ lệ 304 cố định để xác định website đang hoạt động bất thường. Việc nhiều request trả về 304 có thể hoàn toàn bình thường nếu website có nhiều tài nguyên được cache và người dùng thường xuyên truy cập lại.
Tuy nhiên, nếu những tài nguyên thường xuyên thay đổi lại liên tục nhận 304, cần kiểm tra cách server tạo và xác thực ETag hoặc Last-Modified. Chẳng hạn, ETag không được cập nhật đúng khi nội dung thay đổi có thể khiến server nhận diện sai rằng tài nguyên vẫn giống phiên bản cũ.
3. Request và Response Headers không khớp
Có thể kiểm tra Request Headers và Response Headers trong Chrome DevTools để phát hiện vấn đề. Nếu trình duyệt gửi If-None-Match hoặc If-Modified-Since, server cần sử dụng những thông tin này để thực hiện xác thực tài nguyên.
Chẳng hạn, nếu If-None-Match chứa một ETag cũ nhưng server vẫn trả về 304 dù nội dung tài nguyên đã thay đổi, cần kiểm tra lại quá trình tạo và cập nhật ETag. Tương tự, với If-Modified-Since, thời gian Last-Modified cần phản ánh đúng trạng thái cập nhật của tài nguyên.
4. Website hiển thị dữ liệu cũ sau khi deploy
Sau khi deploy phiên bản mới, nếu người dùng vẫn nhìn thấy giao diện hoặc chức năng cũ, cache có thể là một trong những nguyên nhân cần kiểm tra. Đặc biệt với các file CSS, JavaScript hoặc hình ảnh, việc sử dụng cache không phù hợp có thể khiến trình duyệt tiếp tục sử dụng tài nguyên cũ.
Trong trường hợp này, không nên mặc định kết luận rằng 304 là nguyên nhân gây lỗi. Cần kiểm tra toàn bộ chuỗi cache từ browser, CDN, reverse proxy đến origin server để xác định thành phần nào đang giữ phiên bản cũ.
5. Cách kiểm tra nhanh 304 có bất thường hay không
Bạn có thể mở Chrome DevTools → Network, tải lại trang và kiểm tra các request trả về 304. Sau đó đối chiếu:
- Status: Có thực sự trả về 304 Not Modified không?
- Request Headers: Có If-None-Match hoặc If-Modified-Since không?
- Response Headers: ETag, Last-Modified, Cache-Control có hợp lý không?
- Nội dung thực tế: Tài nguyên đang hiển thị có đúng phiên bản mới nhất không?
- Sau khi deploy: Tài nguyên có được cập nhật đúng hay vẫn sử dụng bản cũ?
Nếu 304 xuất hiện nhưng nội dung vẫn chính xác và website hoạt động bình thường, đây thường không phải vấn đề. Ngược lại, nếu HTTP Status Code 304 khiến tài nguyên mới không được cập nhật, nội dung cũ tiếp tục xuất hiện hoặc cache hoạt động sai với chính sách của website, cần kiểm tra lại cấu hình Cache-Control, ETag, Last-Modified và CDN/cache layer.
Đánh giá nguyên nhân gây ra lỗi 304 status code không mong muốn
Mặc dù 304 Not Modified không phải là lỗi, mã trạng thái này đôi khi có thể xuất hiện không như mong đợi và khiến website hiển thị nội dung cũ hoặc không cập nhật thay đổi mới nhất. Nguyên nhân thường liên quan đến cơ chế caching, cấu hình HTTP Header, trình duyệt, CDN hoặc server. Xác định đúng nguyên nhân sẽ giúp quản trị viên lựa chọn cách xử lý phù hợp mà không làm mất đi lợi ích của caching.
1. Cache trình duyệt bị xung đột hoặc lỗi
Browser cache lưu lại các tài nguyên của website để sử dụng cho những lần truy cập sau. Nếu cache chứa phiên bản cũ hoặc thông tin xác thực không còn phù hợp, trình duyệt có thể gửi Conditional Request và nhận phản hồi 304, sau đó tiếp tục sử dụng tài nguyên cũ. Điều này có thể khiến người dùng không nhìn thấy những thay đổi mới nhất trên website.
Tình trạng này thường dễ nhận biết sau khi website vừa deploy phiên bản mới, thay đổi CSS, JavaScript hoặc hình ảnh nhưng giao diện trên một số thiết bị vẫn hiển thị phiên bản trước. Để kiểm tra, có thể thử mở website ở chế độ ẩn danh, xóa cache hoặc sử dụng tùy chọn Disable cache trong Chrome DevTools. Nếu website hiển thị đúng sau khi bỏ qua cache, vấn đề có thể liên quan đến dữ liệu được lưu trên trình duyệt.
2. Cấu hình sai HTTP Header trên server
Các HTTP Header như ETag, Last-Modified, Cache-Control và Expires đóng vai trò quan trọng trong quá trình Cache Validation. Nếu những header này được cấu hình không chính xác, server có thể nhận diện sai trạng thái của tài nguyên và trả về 304 trong trường hợp không phù hợp.
Ví dụ, nội dung file đã thay đổi nhưng giá trị ETag không được cập nhật tương ứng. Khi trình duyệt gửi If-None-Match với ETag cũ, server có thể xác định sai rằng tài nguyên chưa thay đổi và trả về 304. Tương tự, Last-Modified không chính xác cũng có thể ảnh hưởng đến quá trình xác thực dựa trên thời gian.
Khi gặp vấn đề, nên kiểm tra Request Headers và Response Headers, đồng thời đối chiếu cách server, framework hoặc web server như Nginx, Apache đang thiết lập chính sách cache.
3. Lỗi cấu hình DNS hoặc CDN
Nếu website sử dụng CDN, reverse proxy hoặc nhiều máy chủ, phản hồi 304 không nhất thiết chỉ đến từ origin server. Một node CDN hoặc lớp cache trung gian có thể đang lưu trữ phiên bản tài nguyên khác với phiên bản hiện tại trên server gốc.
Trường hợp này có thể xảy ra sau khi website cập nhật nội dung nhưng CDN chưa purge hoặc invalidate cache. Người dùng ở những khu vực khác nhau thậm chí có thể nhận được các phiên bản tài nguyên khác nhau tùy theo edge server mà request được phân phối đến.
DNS cũng cần được kiểm tra nếu website vừa thay đổi máy chủ hoặc hệ thống CDN. Việc DNS trỏ không đúng origin hoặc các bản ghi chưa được cập nhật đồng nhất có thể khiến request được chuyển đến một server vẫn đang phục vụ phiên bản tài nguyên cũ.
4. Tập tin bị nhiễm malware / Đã bị chỉnh sửa ngầm
Trong một số trường hợp, nội dung tài nguyên có thể bị malware hoặc mã độc chỉnh sửa trái phép. Nếu hệ thống cache hoặc ETag vẫn xác định tài nguyên là phiên bản hợp lệ, website có thể tiếp tục phục vụ nội dung đã bị thay đổi thông qua cache.
Nếu phát hiện những file bất thường, mã JavaScript không rõ nguồn gốc, redirect lạ hoặc nội dung thay đổi mà quản trị viên không thực hiện, nên tiến hành quét malware, kiểm tra quyền truy cập, đối chiếu file với bản sao sạch và xem lại log hệ thống. Xử lý cần tập trung vào nguyên nhân bảo mật thực tế thay vì cố gắng "sửa" mã 304, bởi 304 tự thân không phải lỗi cần loại bỏ.
Hướng dẫn khắc phục sự cố 304 Not Modified cho người dùng và quản trị viên
304 Not Modified không phải lỗi cần khắc phục trong mọi trường hợp, bởi đây là một phần bình thường của cơ chế cache validation. Tuy nhiên, nếu mã 304 khiến website hiển thị nội dung cũ, tài nguyên không được cập nhật hoặc phát sinh lỗi giao diện, người dùng và quản trị viên có thể áp dụng các phương pháp xử lý khác nhau. Người dùng cuối nên ưu tiên làm mới hoặc xóa cache, trong khi quản trị viên cần kiểm tra sâu hơn về HTTP Header, server, CDN và hệ thống lưu trữ cache.
1. Dành cho người dùng cuối (end-users)
Nếu website hiển thị nội dung cũ, giao diện không cập nhật hoặc hoạt động không đúng và nghi ngờ nguyên nhân liên quan đến cache, người dùng có thể thử một số cách xử lý đơn giản trước khi liên hệ với quản trị viên.
(1) Tải lại trang
Trước tiên, bạn hãy nhấn Ctrl + R trên Windows hoặc Cmd + R trên macOS để tải lại trang. Cách này cho phép trình duyệt thực hiện lại quá trình request và kiểm tra tài nguyên với server.
(2) Hard Refresh
Nếu tải lại thông thường không giải quyết được vấn đề, bạn có thể thực hiện Hard Refresh để yêu cầu trình duyệt tải lại tài nguyên. Trên Chrome, nhấn Ctrl + Shift + R trên Windows hoặc Cmd + Shift + R trên macOS.
(3) Xóa cache của trình duyệt
Nếu vấn đề vẫn tiếp diễn, người dùng có thể xóa dữ liệu cache của trình duyệt. Sau khi xóa, website sẽ phải tải lại các tài nguyên từ server thay vì sử dụng những phiên bản đã lưu trước đó.
(4) Kiểm tra website bằng chế độ ẩn danh
Bạn mở website trong Incognito Mode hoặc cửa sổ riêng tư để kiểm tra. Nếu website hoạt động bình thường ở chế độ này nhưng vẫn gặp lỗi ở cửa sổ thông thường, nguyên nhân có thể liên quan đến cache, cookie hoặc dữ liệu trình duyệt hiện tại.
(5) Thử trình duyệt hoặc thiết bị khác
Người dùng cũng có thể mở website bằng một trình duyệt hoặc thiết bị khác. Nếu chỉ một thiết bị gặp vấn đề, khả năng cao nguyên nhân nằm ở cache hoặc cấu hình cục bộ. Ngược lại, nếu nhiều thiết bị đều hiển thị cùng một phiên bản cũ, vấn đề có thể nằm ở server, CDN hoặc cấu hình cache của website.
2. Dành cho quản trị viên
Đối với quản trị viên, xử lý 304 Not Modified cần tập trung vào nguyên nhân thay vì cố gắng loại bỏ mã 304. Trước tiên, cần xác định tài nguyên nào đang bị cache sai, sau đó kiểm tra HTTP Header, cấu hình web server, CDN và hành vi thực tế của trình duyệt. Tùy nguyên nhân, quản trị viên có thể điều chỉnh cấu hình cache, cập nhật ETag hoặc xóa cache tại các lớp trung gian.
- Kiểm tra file cấu hình: Bạn kiểm tra cấu hình của web server, framework hoặc hệ thống cache để xác định các quy tắc liên quan đến ETag, Last-Modified, Cache-Control và Expires. Nếu các header này được thiết lập không phù hợp, server có thể xác thực sai phiên bản tài nguyên và trả về 304 ngoài mong muốn. Đặc biệt, cần kiểm tra các file cấu hình của Nginx, Apache hoặc cấu hình cache được thiết lập trong ứng dụng. Sau khi thay đổi cấu hình, nên kiểm tra lại response thực tế để đảm bảo server đang gửi đúng HTTP Header.
- Xóa cache CDN: Nếu website sử dụng CDN, bạn hãy kiểm tra xem CDN có đang lưu phiên bản cũ của tài nguyên hay không. Sau khi cập nhật website, có thể cần thực hiện Purge Cache hoặc Cache Invalidation đối với những file đã thay đổi. Sau khi xóa cache CDN, kiểm tra lại request từ nhiều khu vực hoặc sử dụng Chrome DevTools để xác định CDN đã phân phối phiên bản mới hay chưa. Điều này đặc biệt quan trọng khi website sử dụng nhiều edge server.
- Vô hiệu hóa ETag nếu cần: Trong một số hệ thống, ETag có thể gây ra vấn đề nếu website chạy trên nhiều server và mỗi server tạo ETag theo cách khác nhau. Khi đó, cùng một tài nguyên có thể nhận các giá trị ETag khác nhau tùy server xử lý request. Nếu ETag không mang lại lợi ích hoặc gây xung đột với cơ chế cache hiện tại, quản trị viên có thể cân nhắc vô hiệu hóa ETag và sử dụng các phương pháp caching khác phù hợp. Tuy nhiên, không nên tắt ETag một cách mặc định chỉ vì website xuất hiện 304, bởi ETag là một cơ chế xác thực cache hợp lệ và hữu ích.
- Debug bằng Chrome DevTools: Bạn sử dụng Chrome DevTools → Network để theo dõi request và response của tài nguyên gặp vấn đề. Quản trị viên nên so sánh phiên bản tài nguyên thực tế trên server với phiên bản trình duyệt đang nhận được. Nếu file trên server đã thay đổi nhưng request vẫn nhận 304 và trình duyệt hiển thị nội dung cũ, cần tiếp tục kiểm tra các lớp cache như browser, CDN, reverse proxy và application cache.
Cách tối ưu caching để tận dụng HTTP status 304 hiệu quả
Để HTTP status 304 Not Modified phát huy hiệu quả, website cần được xây dựng chính sách caching phù hợp thay vì chỉ dựa vào việc bật cache mặc định. Quản trị viên nên xác định đặc điểm của từng loại tài nguyên, thiết lập thời gian cache hợp lý và sử dụng các HTTP Header như Cache-Control, ETag và Last-Modified. Cách tiếp cận này giúp giảm request không cần thiết, tiết kiệm băng thông nhưng vẫn đảm bảo người dùng nhận được nội dung mới khi tài nguyên thay đổi.
1. Phân loại tài nguyên
Không phải tài nguyên nào trên website cũng nên áp dụng cùng một chính sách caching. Trước tiên, cần phân loại tài nguyên dựa trên tần suất thay đổi và mức độ quan trọng để lựa chọn thời gian cache phù hợp.
- Các tài nguyên ít thay đổi như hình ảnh, font, file CSS hoặc JavaScript của phiên bản ổn định có thể được thiết lập thời gian cache dài hơn. Khi người dùng truy cập lại, trình duyệt có thể tận dụng tài nguyên đã lưu thay vì tải lại từ server.
- Ngược lại, những tài nguyên thường xuyên thay đổi như HTML của trang tin tức, dữ liệu API hoặc nội dung động nên có chính sách cache thận trọng hơn. Có thể sử dụng Cache Validation với ETag hoặc Last-Modified để server kiểm tra tài nguyên trước khi quyết định trả về 304 hay nội dung mới.
2. Kết hợp Cache-Control với ETag
Cache-Control và ETag đảm nhiệm hai vai trò khác nhau nhưng có thể kết hợp để caching hiệu quả hơn. Trong đó, Cache-Control quy định trình duyệt được phép lưu và sử dụng tài nguyên trong bao lâu, còn ETag giúp server xác định tài nguyên trong cache có còn giống với phiên bản hiện tại hay không.
Ví dụ, website có thể sử dụng Header:
- Cache-Control : max-age=3600
- ETag : "abc123"
Trong thời gian max-age=3600 (1 giờ), trình duyệt có thể sử dụng bản cache mà không cần hỏi lại server. Sau khi thời gian này hết, trình duyệt có thể gửi request kèm If-None-Match chứa giá trị ETag trước đó: If-None-Match: "abc123".
Server so sánh ETag hiện tại với ETag gửi lên:
- Nếu giống nhau, server trả về: 304 Not Modified. Trình duyệt sau đó tiếp tục sử dụng bản tài nguyên đã lưu.
- Nếu khác nhau, server sẽ trả về 200 OK cùng ETag mới phù hợp.
Cách kết hợp này giúp giảm lượng dữ liệu phải truyền qua mạng, đặc biệt với các tài nguyên có kích thước lớn nhưng không thay đổi thường xuyên. Thay vì tải lại toàn bộ tài nguyên mỗi khi người dùng truy cập, trình duyệt có thể kiểm tra phiên bản đã lưu với server và nhận phản hồi 304 Not Modified nếu nội dung chưa thay đổi. Điều này đặc biệt hiệu quả với các tài nguyên có kích thước lớn như file JavaScript, CSS, hình ảnh hoặc dữ liệu API nhưng không thay đổi thường xuyên, qua đó giảm băng thông và cải thiện tốc độ phản hồi của website.
3. Sử dụng immutable và file fingerprint cho static assets
Đối với các tài nguyên tĩnh được tạo ra trong quá trình build như file JavaScript, CSS hoặc hình ảnh, website có thể kết hợp file fingerprint với immutable để tối ưu caching. Thay vì yêu cầu trình duyệt kiểm tra lại tài nguyên sau mỗi lần truy cập, hệ thống sử dụng mã hash trong tên file để nhận biết chính xác phiên bản của tài nguyên.
File fingerprint hay còn gọi là cache busting là kỹ thuật thêm một mã hash được tạo dựa trên nội dung file vào tên tài nguyên. Ví dụ, thay vì sử dụng đường dẫn cố định: /assets/ app.js.
Website có thể tạo file: /assets/ app.3f2a91c.js.
Khi nội dung của app.js thay đổi, hệ thống build sẽ tạo ra một mã hash mới, chẳng hạn: /assets/app.8d71e2f.js.
Lúc này, trình duyệt nhận thấy URL đã thay đổi nên sẽ xem đây là một tài nguyên mới và tải lại file. Trong khi đó, phiên bản cũ vẫn có thể được giữ trong cache mà không ảnh hưởng đến phiên bản mới. Nhờ vậy, website có thể thiết lập thời gian cache rất dài cho các file đã fingerprint mà không lo người dùng tiếp tục sử dụng nhầm phiên bản cũ.
Với những tài nguyên này, có thể sử dụng Header chẳng hạn như:
Cache-Control: public, max-age=31536000, immutable.
Trong đó, immutable cho biết tài nguyên được xem là không thay đổi trong suốt thời gian cache. Trình duyệt vì vậy không cần gửi request lên server để kiểm tra lại tài nguyên, kể cả trong một số trường hợp người dùng thực hiện thao tác Refresh. Điều này giúp loại bỏ cả request xác thực cache và có thể mang lại hiệu quả tốt hơn so với việc thường xuyên phải kiểm tra rồi nhận phản hồi 304 Not Modified.
4. Không cache dữ liệu động một cách tùy tiện
Không phải dữ liệu nào trên website cũng phù hợp để lưu vào cache. Đặc biệt, các nội dung cá nhân hóa, nhạy cảm hoặc thay đổi liên tục cần được xử lý thận trọng. Nếu cấu hình sai, cache không chỉ khiến người dùng nhận dữ liệu cũ mà còn có thể gây ra vấn đề về bảo mật.
Một rủi ro phổ biến là cache nhầm dữ liệu cá nhân hóa. Ví dụ, thông tin giỏ hàng, tài khoản hoặc lịch sử giao dịch của người dùng không nên được lưu tại cache dùng chung của CDN hoặc proxy. Nếu cấu hình không đúng, có thể xảy ra tình trạng người dùng này nhận được dữ liệu được tạo cho người dùng khác.
Đối với thông tin nhạy cảm hoặc được cá nhân hóa, cần cân nhắc kỹ các chỉ thị như private hoặc no-store thay vì áp dụng cache công khai:
Ví dụ: Cache-Control: private, no-store.
Như vậy, mục tiêu của caching không phải là cache càng nhiều càng tốt, mà là lựa chọn đúng tài nguyên để cache. Static assets có thể cache dài hạn, trong khi dữ liệu động cần chính sách linh hoạt hơn. Khi được cấu hình hợp lý, website vừa giảm tải cho server, tiết kiệm băng thông vừa tận dụng hiệu quả cơ chế 304 Not Modified.
Một số câu hỏi thường gặp về 304 Not Modified status code
HTTP status 304 Not Modified thường khiến người mới hiểu nhầm là một mã lỗi vì không trả về nội dung trang như 200 OK. Thực tế, đây là một phản hồi hợp lệ thuộc nhóm HTTP 3xx, được sử dụng để tối ưu cơ chế caching giữa trình duyệt và server. Dưới đây là những câu hỏi phổ biến giúp làm rõ cách hoạt động và sử dụng mã 304 đúng cách.
1. Mã HTTP status 304 Not Modified có phải là lỗi (error) không?
Không. 304 Not Modified không phải là mã lỗi mà là một phản hồi cho biết tài nguyên được yêu cầu chưa thay đổi kể từ lần tải trước. Server không cần gửi lại toàn bộ nội dung mà yêu cầu trình duyệt sử dụng phiên bản đã được lưu trong cache. Nhờ đó, website có thể giảm lượng dữ liệu truyền tải và cải thiện tốc độ phản hồi.
2. Làm sao để biết website đang trả về mã 304 status code đúng cách?
Có thể kiểm tra trực tiếp bằng Developer Tools của trình duyệt. Mở DevTools bằng phím F12, chuyển sang tab Network, sau đó tải lại trang và tìm các request đến file HTML, CSS, JavaScript hoặc hình ảnh. Nếu một tài nguyên được cache validation và không thay đổi, cột Status có thể hiển thị 304 Not Modified.
Ngoài status code, có thể kiểm tra các HTTP Header như ETag, Last-Modified, If-None-Match và If-Modified-Since. Nếu trình duyệt gửi thông tin xác thực cache và server phản hồi 304 khi tài nguyên thực sự chưa thay đổi, cơ chế caching đang hoạt động đúng. Ngược lại, nếu nội dung đã thay đổi nhưng trình duyệt vẫn sử dụng phiên bản cũ, cần kiểm tra lại cấu hình cache.
3. Tại sao đã sửa nội dung bài viết, giao diện nhưng website vẫn trả về mã 304?
304 Not Modified không có nghĩa là toàn bộ website chưa được cập nhật. Mã này được trả về dựa trên tài nguyên cụ thể mà trình duyệt đang yêu cầu và thông tin xác thực cache của tài nguyên đó.
Nếu đã chỉnh sửa nội dung nhưng vẫn thấy dữ liệu cũ, nguyên nhân có thể đến từ browser cache, CDN cache, reverse proxy hoặc cấu hình ETag và Last-Modified chưa được cập nhật chính xác. Ngoài ra, với website sử dụng cache nhiều tầng, phiên bản cũ có thể vẫn tồn tại ở một tầng trung gian.
4. ETag và Last-Modified có vai trò gì trong 304 Not Modified?
ETag và Last-Modified là hai cơ chế giúp server xác định tài nguyên trong cache của trình duyệt có còn mới hay không. Hai cơ chế này có thể được sử dụng riêng hoặc kết hợp tùy theo cách triển khai caching của website.
- ETag cung cấp một mã định danh đại diện cho một phiên bản cụ thể của tài nguyên. Khi gửi request tiếp theo, trình duyệt có thể sử dụng If-None-Match để gửi lại giá trị ETag. Nếu tài nguyên chưa thay đổi, server trả về 304.
- Last-Modified cho biết thời điểm tài nguyên được chỉnh sửa lần cuối. Trình duyệt có thể gửi giá trị này thông qua Header If-Modified-Since để hỏi server liệu tài nguyên có thay đổi kể từ thời điểm đó hay chưa.
5. Khi nào lập trình viên NÊN và KHÔNG NÊN cho phép trả về mã HTTP status 304?
Lập trình viên nên sử dụng 304 khi tài nguyên có khả năng được cache và không thay đổi thường xuyên. Các file CSS, JavaScript, hình ảnh, font hoặc những nội dung có thể xác thực phiên bản bằng ETag hay Last-Modified là những trường hợp phù hợp. Khi đó, 304 giúp tránh phải truyền lại toàn bộ tài nguyên đã có sẵn trong cache.
Ngược lại, không nên tùy tiện sử dụng caching hoặc 304 cho dữ liệu nhạy cảm, thông tin cá nhân hóa hoặc nội dung yêu cầu tính chính xác theo thời gian thực. Ví dụ, dữ liệu tài khoản, số dư, trạng thái giao dịch hoặc một số API real-time cần được kiểm soát chặt chẽ để tránh trả về thông tin cũ hoặc lưu nhầm dữ liệu tại cache dùng chung.
Qua bài viết của Phương Nam Vina, có thể thấy 304 Not Modified là một HTTP status code quan trọng trong cơ chế caching, giúp trình duyệt tận dụng lại tài nguyên đã lưu thay vì tải lại toàn bộ dữ liệu từ server. Nhờ đó, website có thể giảm băng thông, giảm tải máy chủ và cải thiện tốc độ phản hồi, đặc biệt với những tài nguyên ít thay đổi. Tuy nhiên để tận dụng hiệu quả 304 Not Modified, quản trị viên và lập trình viên cần xây dựng chính sách caching phù hợp cho từng loại tài nguyên. Việc kết hợp Cache-Control, ETag, Last-Modified, file fingerprint và immutable giúp kiểm soát tốt thời gian lưu cache cũng như quá trình xác thực tài nguyên. Đồng thời, dữ liệu động và thông tin nhạy cảm cần được xử lý thận trọng để tránh tình trạng hiển thị nội dung cũ hoặc phát sinh rủi ro bảo mật.
Tham khảo thêm:
Lỗi 401 là gì? Nguyên nhân và cách sửa lỗi 401 Unauthorized
Lỗi 413 request entity too large là gì? Nguyên nhân & cách xử lý
Lỗi 400 là gì? Cách khắc phục lỗi 400 Bad Request nhanh chóng
