NGINX SSI 工作正常,但 LAST_MODIFIED 返回“(無)”?
我的 NGINX SSI 在 virtualHosts 文件(下面的程式碼)中工作正常,但
LAST_MODIFIED
返回“(無)”,儘管SSI 的 NGINX 文件聲明該ssi_last_modified
指令出現在版本 1.5.1 中(我們正在執行版本 1.14.2)。虛擬主機文件:
… location / { ssi on; ssi_last_modified on; … } …
並在 .html 文件中:
<!--#if expr="$footer_id='blackfooter'" --><div id="blackfooter"><!--#else --><div id="footer"><!--#endif --> <!--#config timefmt="%A %d %B %Y" --><p>Updated: <!--#echo var="LAST_MODIFIED" --> | Today: <!--#echo var="DATE_LOCAL" --></p> </div>
所以現在,我使用了 JavaScript:
<!--#if expr="$footer_id='blackfooter'" --><footer id="blackfooter"><!--#else --><footer><!--#endif --> <!--#config timefmt="%A %d %B %Y" --><p>Updated: <span id="updated"></span> | Today: <!--#echo var="DATE_LOCAL" --></p> </footer> <script> let lastmod = new Date(document.lastModified); updated.innerHTML = lastmod.toString().substring(4,15); </script>
為什麼NGINX 提供了其他記錄在案的 SSI 功能,但**不在
LAST_MODIFIED
**標頭中?我發現的唯一可能的線索是NGINX ngx_http_sub_module
sub_filter_last_modified
的文件中提到了AFAIK(而且我不是 NGINX 專家)我不確定這有多大幫助。
為什麼 NGINX 提供了其他記錄在案的 SSI 功能,但沒有在標頭中提供 LAST_MODIFIED?
因為 nginx 還沒有完全實現 SSI。引用文件:
目前,支持的 SSI 命令列表不完整。
有關支持的 SSI 命令和變數的列表,請在此處查看 nginx 的原始碼。
編輯:
如果需要完整的 SSI 支持,請嘗試在 nginx 後面使用 Apache httpd。
根據 NGIX(原文如此)文件(請參閱我文章中的連結)
這是大約 2021 年 7 月 21 日從
ssi_last_modified
文件中直接引用的內容:允許在 SSI 處理期間保留
Last-Modified
原始響應的標頭欄位,以促進響應記憶體。預設情況下,當響應的內容在處理過程中被修改時,標頭欄位會被刪除,並且可能包含動態生成的元素或部分,這些元素或部分會獨立於原始響應而更改。
預設情況下,當響應一個靜態文件的請求時,nginx 會添加
Last-Modified
HTTP 響應頭。使用 SSI 時,nginx 故意刪除這個 header,因為 nginx 是動態生成頁面而不是返回靜態文件,因此添加
Last-Modified
響應 header 是沒有意義的。
ssi_last_modified``Last-Modified
指令根據 SSI 腳本文件時間戳重新添加HTTP 響應標頭。絕不是說該指令將
LAST_MODIFIED
變數添加到 nginx 的 SSI。
LAST_MODIFIED
還是應該支持的AFAIK,沒有標準,也沒有 RFC,可以依靠它來完全實現 SSI。可以說,mod_include 的文件可能是這樣的標準,但同樣,它只是另一個產品的手冊。讓我知道是否有這樣的標準,我會修改這個答案。
通過向nginx 的 Trac送出功能請求,您將有更好的機會解決此問題。
Tangent:即使支持,如果加上
LAST_MODIFIED
,它的值應該是SSI腳本的時間戳,還是伺服器時間戳;因為 HTML 響應是即時生成的,而不是直接從文件中讀取。這適用於我從 Apache 遷移到 NGINX 的遺留站點。一些大型網站仍然使用 SSI,這是一種有用的輕量級方法,避免了 PHP 等。
我懷疑那些大型網站仍然在幕後使用 SSI。在這一點上,SSI 是一個遺留框架,有很多可用的替代方案。