我想用尾隨“.pdf”重寫所有 URL 以打開 mozilla.pdf.js 中的 pdf 檔案，并在我的 HTTP 虛擬主機上成功地按照 RewriteRule 和 RewriteCond 進行測驗（順便說一下，我在 ubuntu 服務器上使用 apache2）：
要重寫的示例 URL：
http://server-test.local/downloads/dir2/file5/test.pdf
重寫后的示例目標 URL：
http://server-test.local/libs/mozilla.pdf.js/web/viewer.html?file=/downloads/dir2/file5/test.pdf
RewriteCond %{HTTP_REFERER} !viewer.html
RewriteRule ^(. )(\.pdf)$ http://server-test.local/libs/mozilla.pdf.js/web/viewer.html?file=$1 [R=301,L]
因此，這RewriteCond可以防止另一個重定向，這將導致mozilla.pdf.js嘗試加載自身而不是 PDF 檔案并導致錯誤。（如果描述不清楚，我不是很喜歡這個話題）
現在我已經嘗試為我的另一個虛擬主機 (https) 應用完全相同的 RewriteCond 和 RewriteRule，它與“服務器測驗”虛擬主機完全相同 - 除了 SSL 和 Kerberos 實作：
RewriteCond %{HTTP_REFERER} !viewer.html
RewriteRule ^(. )(\.pdf)$ https://server-prod.local/libs/mozilla.pdf.js/web/viewer.html?file=$1 [R=301,L]
但似乎不知何故RewriteCond不適用。結果是，重定向到mozilla.pdf.js作品，但不會呈現 PDF 并出現錯誤mozilla.pdf.js（“無效的 PDF 結構”），因為 - 這是我的理論 - 還有另一個重定向，所以mozilla.pdf.js不會加載/渲染 pdf 但它嘗試加載自己的viewer.html。
我也嘗試了以下RewriteConds，但沒有一個改變了行為：
RewriteCond %{REQUEST_URI} !viewer.html*
RewriteCond %{REQUEST_URI} !^/libs/mozilla.pdf.js/web/viewer.html*
RewriteCond !viewer.html
我對這些RewriteConds 的目的是防止另一個（回圈）重定向，如果重寫前的 URL 包含字串“viewer.html”，那么如果[...]/viewer.html?file=/downloads/dir2/file5/test.pdf是REQUEST_URI，則不應再進行重寫。
有人可以向我解釋一下，為什么RewriteCond可以在測驗虛擬主機 (HTTP) 上運行，而不能在生產虛擬主機 (HTTPS) 上運行？除了 SSL 和 SSL 安全虛擬主機具有 Kerberos 實作這一事實之外，兩個虛擬主機、它們的目錄和它們的配置大體相同。SSL 是問題嗎？有誰知道我如何在 SSL 虛擬主機上解決這個問題？我需要以某種方式找到解決方案......
我將不勝感激各種提示/幫助。
uj5u.com熱心網友回復：
重寫后的示例目標 URL：
http://example.com/libs/mozilla.pdf.js/web/viewer.html?file=/downloads/dir2/file5/test.pdf
但是，您的指令目前不這樣做。它重定向（而不是“重寫”）到http://example.com/libs/mozilla.pdf.js/web/viewer.html?file=downloads/dir2/file5/test- 注意fileURL 引數值開頭缺少的斜杠和缺少的檔案擴展名。
如果在前者上啟用了 MultiViews，這可能會在一臺服務器上運行，而不是在另一臺服務器上運行。（這有效地使無擴展名的 URL 能夠“作業”。）
要更正RewriteRule指令：
RewriteRule \.pdf$ https://example.com/libs/mozilla.pdf.js/web/viewer.html?file=%{REQUEST_URI} [R=301,L]
該fileURL引數現在將包含/downloads/dir2/file5/test.pdf。
您需要在測驗前清除瀏覽器快取。但是，這應該是 301（永久）重定向嗎？您在問題中提到了“重寫”，并且您已經標記了該問題url-rewriting- 這不是。您是否希望用戶物理重定向到這個新 URL？看起來這真的應該是內部重寫（即不公開mozilla.pdf.js）？在這種情況下，這應該重寫如下：
RewriteRule \.pdf$ /libs/mozilla.pdf.js/web/viewer.html?file=%{REQUEST_URI} [L]
出現 mozilla.pdf.js 的錯誤（“無效的 PDF 結構”），因為 - 那是我的理論 - 還有另一個重定向，所以 mozilla.pdf.js 不會加載/渲染 pdf，但它會嘗試加載自己的viewer.html 代替。
雖然如果是這種情況，那么它會導致重定向回圈，但您看到的錯誤并不表明這一點。
另外，您是否確認Referer瀏覽器正在為此請求發送 HTTP 請求標頭并按預期設定？這里的問題Referer是不可靠。瀏覽器可以出于多種原因抑制它。
更好的方法是將mozilla.pdf.js自定義標頭設定為請求的一部分，這可以在 mod_rewrite條件中可靠地檢查。
或者，使 URL 路徑與實際檔案系統路徑不同。（盡管如果檔案路徑已知，則可以請求實際檔案。）
在旁邊：
因此，這
RewriteCond可以防止另一個重定向，這將導致mozilla.pdf.js嘗試加載自身而不是 PDF 檔案并導致錯誤。
它不會嘗試加載“自身”。該RewriteRule模式已經可以防止這種情況發生，因為它只匹配.pdf檔案（盡管這不是這里發生的事情）。對 的檢查Referer是為了防止遞回回圈......以防止viewer.html重復呼叫并.pdf在fileURL 引數中傳遞相同的檔案。
我假設mozilla.pdf.js對在fileURL 引數中傳遞的 PDF 檔案發出 HTTP 請求。“問題”（在外部重定向的情況下）是區分來自用戶的直接請求和來自腳本的請求（兩者都是來自瀏覽器的客戶端請求）。
uj5u.com熱心網友回復：
我想，我能夠通過另外添加來解決我的問題
RewriteCond %{QUERY_STRING} !file=
到我的 RewriteRule 的 RewriteConds。現在 mozilla.pdf.js 打開并向我展示 PDF 檔案。@MrWhite Thx 再次為您解釋。
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/376346.html
上一篇：Apache虛擬主機子域不起作用