W3 Total Cache 0.9.2.6 的災情慘重...

W3 Total Cache 出了新版,升級上去後 WordPress 就爛掉了,最後是先 downgrade 到 0.9.2.5,然後再進系統把 W3 Total Cache 完全 deactive...

有看到升級資訊的人可以先等一下,這次的 0.9.2.5 到 0.9.2.6 不是 minor version upgrade:

-rw-r--r--   1 gslin  staff   854455 Feb  6 04:12 w3-total-cache.0.9.2.3.zip
-rw-r--r--   1 gslin  staff   915186 Feb  6 04:11 w3-total-cache.0.9.2.4.zip
-rw-r--r--   1 gslin  staff   915384 Feb  6 04:02 w3-total-cache.0.9.2.5.zip
-rw-r--r--   1 gslin  staff  1292961 Feb  6 04:11 w3-total-cache.0.9.2.6.zip

看起來這個作者沒什麼版本號的觀念,之後升級他的東西小心一點... XD

Google 對字串處理的最佳化

Google Research 上看到 Google 針對字串處理最佳化問題所發的論文:「Automated Locality Optimization Based on the Reuse Distance of String Operations (PDF)」。

大原則是想辦法善用 L2/L3 cache,這沒什麼特別的,比較有趣的地方是解決方案,除了自動化的方式外,另外還有工具「提醒」撰寫程式的人,另外還有一些數據以及 code name 可以看...

W3 Total Cache 安全性問題...

在「W3 Total Cache Implementation Vulnerability」這篇說明了 WordPress 知名外掛 W3 Total Cache 的安全性問題,原來的在通報在 Full Disclosure Mailing List 上:「WordPress Remote Exploit - W3 Total Cache」。

當沒有 opcode cache (像是 APC) 而使用 disk DB cache 時,會有安全性問題。

除了關掉 DB cache 以外,目前的 workaround 建議是針對 /wp-content/w3tc/dbcache 擋掉,像是用 .htaccess 擋:

#
deny from all

用 JavaScript 遠端攻陷 Intel Core2Duo...

Hacker News 上看到了「Intel Core2Duo cpu cache controller bug PoC」,透過 JavaScript 遠端攻擊 Intel Core2Duo,直接突破所有 application & OS 保護機制... exploit 說明裡提到測過 Intel Core 2 Duo T5750Intel Atom N270 這兩顆 CPU。

另外,從 exploit 給的資料中,可以找到 Kris KasperskyHITB 2008 給出來的 PDF:「Remote Code Execution through Intel CPU Bugs」。

居然用 JavaScript 戳...

Update:很像是假的:「http://news.ycombinator.com/item?id=4246338」。

Squid 3.1 的 forward proxy 設定...

因為打算給 portsnap 用,所以得用 Squid 3.1 架 forward proxy,可以避免大量對外抓同樣的資料...

由於是內部的機器,不需要擋 acl,設定起來超簡單... ports 裝完 www/squid31 後,把 squid.conf 寫成:

#
http_access allow all
#
access_log /home/squid/logs/access.log squid
cache_dir aufs /home/squid/cache1 1024 16 16
cache_effective_group squid
cache_effective_user squid
cache_log /home/squid/logs/cache.log
cache_mem 256 MB
http_port 3128

這樣就「會動」了... (先不管效率) 照 squid 的慣例,第一次必須先跑 /usr/local/sbin/squid -z 讓目錄建立出來,後面就是標準的 /usr/local/etc/rc.d/squid start

WordPress plugins 安全性問題

TechCrunch 上看到 WordPress.org 強制所有 WordPress.org 的使用者更新密碼 (不是 WordPress.com):「WordPress.org Forces Password Resets Due To Compromised Plugins」。

起因是 AddThisWPtouch 以及 W3 Total Cache 這三個 plugin 有異常 commit 塞入 backdoor code。(瞬間就中兩槍)

這幾天有更新 plugin 的人最好趕快看一下... 慘啊 :/

W3 Total Cache 0.9.2 與 0.9.2.1 的問題...

W3 Total Cache 最近的版本更新把一堆站台弄壞 (很像是 css naked day?XD),可以在 Plugin 網頁的回報資訊看出來:

後來在 forum 上看到有人提:「[Plugin: W3 Total Cache] Minify just won't work」,於是先手動把 minify 功能關閉測試,發現這樣就正常許多,發現看起來應該是跟 minify 有關的問題...

有遇到的人不需要把 W3 Total Cache 全關,還是可以用其他功能加速並降低負載...

Bing 與 Google 都使用 HTML5 的 localStorage 加速手機瀏覽速度...

Steve Souders 分析了手機瀏覽 BingGoogle 的手機平台時,這兩個平台如何處理 cache issue:「Storager case study: Bing, Google」。

這兩個平台不約而同都用上 HTML5 的 localStorage,其中 Bing 用了 ~170KB (未壓縮大小) 的 localStorage,內容包括 CSS/JS/JSON,而 Google 也用了 154KB 存放這些資料。

這應該是因為手機平台的 browser cache 共用一塊不大的空間,很容易被 purge:(我的 Desire 跑 Android 2.2,剛剛看設定,預設值是最大值 6MB)

而 localStorage 則是每個 domain 自己一份空間,相對於共用的空間反而更適合當 cache...

HTTPS 的 Persistent Cache...

Twitter 上又看到有人在講 HTTPS 的資料無法 persistent cache (寫入硬碟保存),所以當瀏覽器重開後就消失,如果能避免使用就應該避免...

但實際上並不是這樣,HTTPS 的資料是「可以」被 persistent cache 的,只是預設不會這樣作。

只要在 response header 裡告訴瀏覽器 Cache-Control: public,瀏覽器就會 persistent cache。因為你已經跟瀏覽器說這個檔案是公開資料,就算是透過 HTTPS 傳輸也可以寫到硬碟裡保存。在「HTTPS Performance Tuning」這篇文章裡有提到 IE 與 Firefox 都沒有問題...

有用 HTTPS 的可以檢查看看是不是能夠加速...

Blog 關掉 CloudFront CDN...

剛剛用手機看自己的 blog 發現版面亂掉,看起來是 CSS 有問題...

測了一些東西後發現,如果 W3 Total Cache 使用 CloudFront CDN,會使得 WPTouch 失效,拿掉 CDN 的部份就會恢復正常...

那只好先拿掉了,現在用手機看 blog 的人應該就正常了...