跳到主要內容

[野人獻曝]Apache上的Mod_rewrite的實作說明(上)

Rewrite

最近不小心沉迷在研究Apache的mod_rewrite,
剛好也有點心得,
所以寫篇簡單心得放在這裡吧。

其實一切都是因為我從Cakephp裡的.htaccess得到一些靈感開始的,
所以我就以Cakephp的rewrite方法來作點說明吧!

首先看到Cakephp根目錄下的.htaccess檔吧:

<IfModule mod_rewrite.c>
RewriteEngine on
RewriteRule ^$ app/webroot/ [L]
RewriteRule (.*) app/webroot/$1 [L]
</IfModule>


第一行和最後一行基本上算是必備,
所以不用問太多加下去就對了XD

第二行開始,代表著你要啟用RewriteEngine的功能,
這一行必加,因為不加的話,你也不會知道為啥你的rewrite無效~

第三、四行則代表要把所有的Request導向給app/webroot,
換言之,Cakephp根目錄下的index.php基本上是擺好玩的!

既然前面提到已經被導向至app/webroot了,
那麼就繼續看app/webroot/.htaccess的內容吧:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)$ index.php?url=$1 [QSA,L]
</IfModule>


第一行、第二行和最後一行內容跟前段相同,所以就不多說了,
比較有意思的是第三、四、五行。
其意義如下:

  • RewriteCond %{REQUEST_FILENAME} !-d
    意義:任何附掛的字串都不會被視為一個目錄
    比如你輸入http://localhost/cakephp/a/s/d,(cakephp是你放cakephp檔案的目錄)
    那麼rewrite將會把a/s/d當成一般字串,而不會繼續去尋找cakephp下是不是有目錄a、目錄s。


  • RewriteCond %{REQUEST_FILENAME} !-f
    意義:任何附掛的字串都不會被視為一個檔案
    比如你輸入http://localhost/cakephp/a/s/d.css,(cakephp是你放cakephp檔案的目錄)
    那麼rewrite將會把a/s/d當成一般字串,而不會繼續去尋找cakephp下是不是有目錄a、目錄s、或是檔案d.css。

  • RewriteRule ^(.*)$ index.php?url=$1 [QSA,L]
    以上所提到的附掛字串都被當成一個參數,其名稱為url,
    指派給這個目錄下的index.php(就是app/webroot/index.php啦)處理。
    注意後面的[QSA,L],
    QSA(Querystring appedned)代表著要附掛Querystring給index.php,
    至於L(Last)代表最後一條rewrite規則。

留言

Unknown寫道…
讚!讚!夠實用!
我也正巧在survey cakePHP,
正為其導向規則搞得暈頭轉向. :P
這篇文章使我茅塞頓開呀。
Faryne寫道…
其實很多框架大致上都是用這樣的導向規則,所以把這一套學會了,大概其他框架的導向規則就不難了XD
Unknown寫道…
作者已經移除這則留言。
Unknown寫道…
作者已經移除這則留言。
Unknown寫道…
抱歉, 之前的回應在表達上有不流暢的地方, 我修飾一下重貼。^^!

< IfModule mod_rewrite.c >
RewriteEngine On

# 條件一: %{REQUEST_FILENAME} 不是目錄。
# (換言之: 若 %{REQUEST_FILENAME} 是目錄, 則不符合條件)
RewriteCond %{REQUEST_FILENAME} !-d

# 條件二: %{REQUEST_FILENAME} 不是檔案。
# (換言之: 若 %{REQUEST_FILENAME} 是檔案, 則不符合條件)
RewriteCond %{REQUEST_FILENAME} !-f

# 以上兩個條件都必須成立: "%{REQUEST_FILENAME} 不是目錄 且 不是檔案", 才套用RewriteRule.

# 否則, 若無其它限制的話, 就是依照一般的存取規則來存取目錄或檔案了。這點可以透過url連結一個已存在的目錄或檔案來進行驗證。

# QSA代表QueryString Appended的意思,L是Last,在此的意義是最後一條RewriteRule。
RewriteRule ^(.*)$ index.php?url=$1 [QSA,L]

# 由於L的作用, 後續若有RewriteRule,也不再繼續套用了。
< /IfModule >

以上註解若有錯誤, 敬請指正。 ^^!
Faryne寫道…
雖然不知道你為什麼刪除文章,不過還是回一下好了!

基本上你沒錯,我的講法確實有點問題,
這是因為我有時候會故意講錯一些東西,
讓看我東西的人不會只把我的作品整個囫圇吞棗下去~(當然有很多時候真的是我打錯)!

總之,你有發現我文章中的問題,
也算是您比我厲害了XDD!
(頭一次碰到可以吐我嘲的人)

這個網誌中的熱門文章

[野人獻曝] 如何實作一個簡單的短網址服務站(前言)

善意提醒: 本系列文隨時有腰斬的可能,若您需要根據本系列文進行實作的話, 請先作好可能會無法繼續下去的心理準備。 ==正文開始== 事前準備項目 一台可以跑 Apache 、 MySQL 、 PHP 的主機 一個看起來還蠻酷的網址 一個不會讓你想砸了它的文字編輯器 一個夠清晰的腦袋 關於第一個和第二個項目, 可以考慮去租一般的虛擬主機, 通常可以一次解決! 第三個項目的話,我個人推薦 Notepad++ 啦, 當然你若有更好的選擇,也可以直接使用! 至於第四個項目,就請施主自求多福了! 第一步 當然先從創造資料庫開始囉(不然你怎麼放那些原始網址資料?), 請打開你的 phpmyadmin , 然後將 這段指令 交給phpmyadmin執行。 注意:如果你是用虛擬主機的話,請不要直接執行那段指令,否則會有出錯的問題。 請先在你的網站控制臺直接創造一個資料庫,再把上述SQL指令中的 CREATE...... 複製下來交給phpmyadmin執行。 如果順利執行這段SQL指令的話,那麼就請你打開你常用的文字編輯器,輸入以下內容: RewriteEngine On RewriteCond %{REQUEST_FILENAME} !-d RewriteCond %{REQUEST_FILENAME} !-f RewriteRule ^(.*)$ redirect.php?q=$1 [L,QSA] ( 原始內容 ) (......本文待續......)

[野人獻曝] 串接 OpenAI 的 Assistant

你就直接把 Assistant 當成你在 ChatGPT 看到的那些 GPT 玩具吧(?), 只是你可以透過 Assistant API 透過程式化來建立你的 GPT 並與你的網站功能結合。 雖然前面說了「用 Assistant API 」,但實際上其實需要以下三個類型的 API 相互結合才能生出一個 Assistant: Assistants API :設定給助手(?)的指示內容、要使用的模型等資訊。在絕大部分場合下,你通常只需要呼叫一次 Assistant 的 Create 方法一次,此後就可以把回傳的 id 記錄下來後用在其他地方。 Threads API : 建立對話串,這個對話串會與前述的 Assistant 相互結合,讓 Assistant 知道要在這個 Thread 開始監聽訊息,並針對指示做出相應的回覆。 Messages API :將使用者輸入的訊息送到 Thread Runs API :使用者送出訊息後,就要呼叫 Create Run ,讓後端知道有工作要做了 以下是其流程: 先呼叫 Assistant API 的 Create ,記得要拿到回傳中最重要的 id ,這會在接下來的步驟中使用到。如果沒什麼特殊狀況的話你可以把這個 id 持久化保存,之後就不用再重做一次這個步驟。 接著 建立一個新的 Thread ,並取回其中回傳的 id。這個步驟你可能會因應不同的使用的而需要頻繁產生。 以上兩個步驟完成後,接著就可以: 建立一條新的 Message ,並將使用者輸入的內容發送至剛才建立的 Thread 中(透過之前建立 Thread 成功所得到的 id) 接著 呼叫 Run API 的 Create ,將建立 Assistant 與 Thread 成功時所取得的 id 帶入後,就會開始根據使用者輸入的內容開始做分析處理。若是忘記呼叫這個 API 你會發現怎麼內容輸入了但卻沒有任何回應。 然後就可以定期去 呼叫取得 Run 資訊的 API ,看看是不是已經處理完畢。只有在 status 是 completed 時,才代表執行完畢。 執行完畢後,就可以 透過 Message API 取得訊息 。 看吧,很簡單吧? ㄍㄋㄋ,官網沒寫詳細用法只有提供 endpoint 資訊。害我先按照自己的想法寫出一個雛形發覺怎麼跑不起來一邊確認一邊問 ChatGPT...

[野人獻曝]Google Account Authentication實作(上)

Google Account Authentication的實作,可以用GET或POST模式去做出來。其主要的差異性只在於: 使用GET模式時,需要經過帳號持有者登入Google並授權後,才能存取帳號資源。 使用POST模式時,只要由我方將帳號、密碼傳送至Google登入即可。 普遍而言,第一種登入方式較適合一般的Web Application,也是讓使用者不用擔心帳號密碼外洩給不相關第三者的最佳方案。 而後者僅建議在單機應用程式或是自用的應用程式上執行。 關於Google Account Authentication,請參閱 Google的說明 。 使用GET模式取得授權 要使用這種授權方式,僅需要以GET方式將下列參數傳送至: https://www.google.com/accounts/AuthSubRequest。 next(必備參數) 授權成功要redirect的網址。若授權成功時,即會將授權token富於該指定網址後。 如:http://www.mydomain.com/app.php?token=...... scope(必備參數) 要存取的資源網址。 如:http://www.blogger.com/feeds/posts.... session(選用參數) 決定token是否要加密。如果應用程式已經註冊的話,可以選用1作為此參數之值,以便傳送加密的token。 secure(選用參數) 以下是一個請求授權的示例: GET https://www.google.com/accounts/AuthSubRequest?next=http%3A%2F%2Fwww.yourwebapp.com%2Fshowcalendar.html&scope=http%3A%2F%2Fwww.google.com%2Fcalendar%2Ffeeds%2F&session=0&secure=0 若授權成功後,則會將頁面redirect至: GET http://www.yourwebapp.com/showcalendar.html?token=CKF50YzIHxCT85KMAg 接著可以把這個token值存入變數之中,以供使用。 剛才的動作已經取得token(姑且稱為金鑰吧),接下來的只要把這個token以 Authorizati...