Boundary Test (Error Handling)

評估資料來源，是否確定一定不會有例外資料進來，如果不會有，就不用檢查，如果資料來源有可能超乎預期，就要檢查。

也或者說提供別人呼叫的 API 都要檢查進來的資料最保險。

1. Web UI
2. CGI (HTTP 的 Request 不一定來自瀏覽器，也可以擷取封包自己塞資料)
3. API

透過 HTTP 傳送資料給 CGI 的注意事項

Web 用戶端 (瀏覽器) 可以透過 HTTP Get 或 Post 的方式將資料傳送給 Server 的 CGI 處理。
但我們也可以透過仿造 URL 或擷取封包修改內容的方式，將修改過後的內容傳送給 Server，不經由原本用戶端的 Form 或 JavaScript。因此除了在用戶端驗證資料的正確性與合法性，也必須在 Server 端作相同的驗證。

以下舉出幾種必須驗證的 Case：

1. 資料長度太長。
2. CGI 要接收數字但傳送過來的資料包含數字與其他字符。
3. 資料沒有落在定義的範圍中。
4. 沒有限制接收檔案的大小。

如果涉及敏感的資料如帳號密碼，必須要先加密後再傳輸。

Cookie 在 HTTP 和 HTTPS 間的使用限制

在相同 Domain 的情況下：

• HTTP Cookie, with "Secure" will be returned only on HTTPS connections (pointless to do this)
• HTTPS Cookie, with "Secure" will be returned only on HTTPS connections
• HTTP Cookie, without "Secure" will be returned on HTTP or HTTPS connections
• HTTPS Cookie, without "Secure" will be returned on HTTP or HTTPS connections (could leak secure information)

Reference:
http://stackoverflow.com/questions/2163828/reading-cookies-via-https-that-were-set-using-http
RFC2965 3.3

PHP 與 MySQL 溝通的資料編碼問題

PHP 和 MySQL 雙方傳遞資料的編碼要正確才能避免亂碼的問題。

要避免亂碼的問題以下兩個條件必須使用一致的編碼：
1. 網頁在瀏覽器所使用的編碼
2. MySQL Client 設定使用的編碼

針對 PHP 和 MySQL 間溝通所使用的編碼，
我們可以使用 mysql_client_encoding 來確認目前 MySQL Client 所使用的編碼，
並用 mysql_set_charset 來做設定的動作。

Reference:
mysql_client_encoding
mysql_set_charset