Amazon S3 上 Protected Content 的 URL Sign...

Amazon S3 可以在上傳時設定為 non-public,這種檔案如果要讓使用者讀取,就必須透過 URL 簽名的方式...

官方的文件是「Authenticating REST Requests」這篇,不過官方文件把所有細節都寫上去,如果第一次接觸的人反而不知道要怎麼辦...

Thomas Riboulet 給了一個 Quickstart 的範例:「Signing Amazon S3 URLs」,裡面雖然是 Ruby code,不過 code 的邏輯很簡單...

以 test.gslin.org 為例,想要產生出從現在開始 3600 秒內有效的 url 可以這樣寫,用過一次後再回去看官方文件,就會發現其實就是官方文件的「REST Authentication Example 3: Query String Authentication Example」這段,如果以 PHP 寫會長這樣:

<?php

$access_key = "";
$secret_key = "";

$timestamp = time() + 3600;
$data = "GET\n\n\n${timestamp}\n/test.gslin.org/test.txt";

$sign = urlencode(
    base64_encode(
        hash_hmac('sha1', $data, $secret_key, true)
    )
);

echo "http://test.gslin.org.s3.amazonaws.com/test.txt?" .
    "AWSAccessKeyId=${access_key}&" .
    "Expires=${timestamp}&" .
    "Signature=${sign}\n";

接下來來研究 CloudFront 的部份...

同時用 mod_deflate 與 mod_fastcgi 所產生的問題...

今天花了不少時間找到的問題...

問題是使用 mod_fastcgi 以及 mod_deflate 時,Content-Encoding 會是 gzip,但 Content-Length 會是未壓縮的長度。

也就是說,伺服器端在 header 提供的 Content-Length 可能寫 8KB,但實際上只丟出 2KB (壓縮後的大小),於是瀏覽器讀完這 2KB 後會停下來一直等,等到 Keep-Alive timeout 斷線 (在我機器上預設是 5 秒)。

在 timeout 斷線後 browser 會就抓到的資料直接解開執行 (因為這 2KB 都有抓到,於是都正確執行)。如果用瀏覽器這邊的 debugger 觀察,就會發現從 first byte 後 5.00 秒才 document ready。

解法有人在 2008 年給過:「Content-Length header should be set using ap_set_content_length」,不過因為 mod_fastcgi 一直沒出新的正式版,所以大家都還是拿到舊的版本。

所以,與之前修正 multi-threading 的問題一樣,往 ports 本身丟 patch:「Update www/mod_fastcgi to fix mod_deflate issue.」,修正後再測試就正常了。

Google 調整參數處罰 Content Farm 的進度

Slashdot 上有人提到 Google 最近調整的情況,繼續調降 low-quality site (這次是 eHow) 在搜尋的排名:「Google Tweaks Algorithm; EHow Traffic Plummets」。

最近用中文版的 search 發現愈來愈找不到想要的東西了,把語系切到英文版試一陣子看看...