用 nginx + FastCGI 接 HHVM...

看到「HHVM, Nginx and Laravel」這篇文章,加上 Rackspace 香港的機器用起來很愉快,就開一台起來測試...

文章內的方法都 okay,只是在裝 HHVM 前少了一步把 key 加到 apt 內的指令:

apt-key adv --recv-keys --keyserver keyserver.ubuntu.com 5A16E7281BE7A449

補上去以後 apt-get update 才會動 :p

速度上當然是沒話說,而且使用的習慣很接近 drop-in replacement 了... (更新檔案後不需要自己另外 purge cache,HHVM 會自己偵測到)

晚點來測試看看 ApacheFastCGI 接 HHVM,如果可行的話就更好了?(.htaccess 啊...)

PSR-4

剛剛看到「Composer now supports PSR-4」才發現有 PSR-4,而且出了好幾個禮拜了...

PSR-4

This PSR describes a specification for autoloading classes from file paths. It is fully interoperable, and can be used in addition to any other autoloading specification, including PSR-0. This PSR also describes where to place files that will be autoloaded according to the specification.

在已經有 PSR-0 的情況下,設計 PSR-4 讓人感覺有點怪,因為功能跟 PSR-0 是衝突的。

不過仔細看看以後發現 PSR-4 規則比較「乾淨」,有種想要汰換 PSR-0 的想法... 而且 Composercomposer.json 的設計也允許針對不同的 prefix 使用不同的邏輯,看起來是把 PSR-0 當作過渡期的設計,希望大家換到 PSR-4?

PSR-0 與 PSR-4 最明顯的差異是對底線 (underscore) 解讀不同,在 PSR-4 中的底線沒有任何意義:

Underscores have no special meaning in any portion of the fully qualified class name.

在 PSR-0 裡則是說 class name 的底線必須換成 DIRECTORY_SEPARATOR:

Each _ character in the CLASS NAME is converted to a DIRECTORY_SEPARATOR. The _ character has no special meaning in the namespace.

來想看看要怎麼轉換現有的系統...

關於 Non-null string 的處理...

上一篇「Filter Input & Escape Output...」有提到 Non-null UTF-8 string 的 filter,結果剛剛洗澡的時候想了想,好像寫錯了?

問題在於「到底是先 de-null 再 iconv(),還是先 iconv() 再 de-null」的問題。

這個問題其實跟 iconv() 成 UTF-8 時遇到不合法字元時怎麼實做有關,也就是 undefined behavior... 由於 \0 是合法的 UTF-8 character,所以我們假設某一種實做是當 iconv() 遇到不合法字元時會用 \0 帶進去:

先 de-null 再 iconv()

這是上一篇文章提到的方法。但在上面提到的 iconv() 實做下卻是有問題的方法。原因很簡單,de-null 後沒有 \0 的字串,卻會因為 iconv() 而產生 \0

先 iconv() 再 de-null

這邊要考慮的是最後 de-null 後會不會變成 invalid UTF-8 string。答案是不可能,因為 iconv() 轉出來後保證是 UTF-8 string (不論如何處理非 UTF-8 character 的部份),而 UTF-8 string 內的 \0 一定可以當 separator,所以切下去一定還是 UTF-8 string。(可以參考下圖關於 UTF-8 character 的規則)

所以?

可能以現在的 iconv() 實做來說,兩者都不會有問題,但寫程式的時候總是要避免 side-effect,所以後者的方法會比前者好。

HHVM 2.3.0 支援 FastCGI...

HHVM 官方的 blog 上看到 2.3.0 的消息:「HHVM 2.3.0 and Travis CI」。

GitHub 上的「FastCGI」這頁就有提到要怎麼透過 FastCGI 界面跟 Apache 配合,熟悉 nginx 的人也應該可以輕鬆對應過去。

另外一個重要的事情是 Travis CI 支援 HHVM 了,可以看到大量的專案加上 HHVM 測試:YiiSlimphpBBJoomlaDoctrineCodeIgniterIdiormPHPUnitParis

既然支援 FastCGI 了,來找機會測試看看...

php.net 被擋的後續分析...

昨天一整天 php.net 網域下的網站都被擋掉:

Twitter 上也有看到 Rasmus Lerdorf 在抱怨:

Rasmus 說是 false positive (誤判),不過我是不太直接相信他講的話...

剛剛看到 Netcraft 整理了一些資料出來「PHP.net blocked by Google: False positive or not?」,裡面有不少東西可以看...

其中最後這段:

However, a short moment ago, a Hacker News user posted some obfuscated JavaScript that was found appended to a possibly cached version of the userprefs.js script, suggesting that the PHP.net website may have been compromised recently.

The obfuscated JavaScript inserts an iframe into the webpage, which loads content from an external site known for distributing malware. Google Chrome blocks the inclusion of any content from known malware domains, although the injected content in this case no longer appears to be accessible.

這段有問題的 javascript code 的解讀可以在這裡看到說明。

如果的確是 compromise,那這事就沒完了,接下來還要找是從哪個洞進來的... 不過以 php.net 的情況,(消音)...

PHP 5.4 的 json_encode 增加 JSON_UNESCAPED_SLASHES...

剛剛翻資料發現 json_encode 奇怪的老問題總算有解...

這樣的程式碼:

<?php
echo json_encode("http://www.google.com/"), "\n";

會輸出這樣的結果:

"http:\/\/www.google.com\/"

這是合法的 JSON 沒錯 (JSON 規格允許 string 裡面使用 \/),但看起來就很不爽啊,明明 / 就是可以合法輸出的字元... 然後剛剛看到 PHP 5.4.0 加上這些東西:

JSON_PRETTY_PRINT, JSON_UNESCAPED_SLASHES, and JSON_UNESCAPED_UNICODE options were added.

測了 JSON_UNESCAPED_SLASHES,看起來舒服多了:

<?php
echo json_encode("http://www.google.com/", JSON_UNESCAPED_SLASHES), "\n";

輸出結果是:

"http://www.google.com/"

用起來有點苦的 Laravel...

Laravel 是個 PHP framework,是目前還蠻常看到討論的 PHP framework。不過實際在研究後發現用起來有點苦啊...

Laravel 官方覺得 PSR-2 是個鳥蛋 (參考 GitHub 上的 issue:「PSR-2 Conflicts」),而我也知道 PSR-2 不怎樣,但這好歹是個標準可以靠啊...

另外一個是 overhead,在 AWS 上用 m1.large 跑 Ubuntu 64bits 測試純 PHP 的 echo "Hello, world."; 可以到 8000 reqs/sec (這是開了 APC 的情況測試,比較接近 production),但同樣是要顯示 Hello, world.,用了 Laravel 後剩下 174 reqs/sec (debug mode 已經關閉),如果再套上 Laravel 的 View 就剩下 152 reqs/sec...

也就是說這個數字是起點 (往下的起點),這樣看起來有點慘烈啊...

網路安全歡樂記...

Twitter 上看到 John Resig 提到一串 reddit 上超歡樂的安全性議題:

討論串在「Creating a user from the web problem.」這邊。不僅是 escape 的問題,還有給予 web server 過大的權限...

貼圖也很好笑啊 XD

(噗)

Zend Framework 1 的 Zend_View 與 Zend Framework 2 的 Zend\View 的差異...

Zend Framework 1 的 Zend_View 實踐了 Rasmus Lerdorf (PHP 發明人) 的想法「PHP 本身就是 template language,不應該在 PHP 裡面再發明一套 template language」。

Zend_View 是可以獨立拿出來用的,使用方式很簡單:

$view = new Zend_View();
$view->setBasePath(realpath(__DIR__ . '/../application/view'));
echo $view->render('index/index.phtml');

這樣對應的 template 檔案是 application/view/scripts/index/index.phtml

Zend Framework 2 除了改用 namespace 外 (所以名稱從原來的 "_" 改成 "\"),還把 Zend\View 深度整合到 Zend\Mvc 裡,這使得要獨立拿出來用的手續就變得... 超... 麻... 煩...

透過 Composer 安裝的人除了在 composer.json 裡面要設定 zendframework/zend-view 外,還要設定 zendframework/zend-filter 才會動 (不知道為什麼沒被放進 dependency),像是這樣:

    "require": {
        "zendframework/zend-filter": "2.2.*",
        "zendframework/zend-view": "2.2.*"
    }

另外 ZF 2 的 Zend\View 則是透過 resolver 物件設定要讀哪個目錄,而非之前用 setBasePath 打發:

$resolver = new \Zend\View\Resolver\TemplatePathStack(
    array(
        'script_paths' => array(
            realpath(__DIR__ . '/../webdata/view/')
        )
    )
);

$renderer = new \Zend\View\Renderer\PhpRenderer();
$renderer->setResolver($resolver);

echo $renderer->render('index/index.phtml');

這樣對應的 template 檔案是 webdata/view/index/index.phtml,跟 ZF1 相比少了一個 scripts

ZF 的文件一如往常的難讀,還是要去翻 source code 才知道要這樣用,所以也跟往常一樣,寫下來避免之後又忘記...