@@ -49,3 +49,48 @@ Echoサーバでは `req.pipe(res);` という形でリクエストをそのま
4949
5050> ** Note** _ middleware_となる関数の引数が4つであると、それはエラーハンドリングの_middleware_とするという、Connect独自のルールがあります。
5151
52+ ##どういう仕組み
53+
54+ Connectの_middleware_がどのような仕組みで動いているのかを見ていきます。
55+
56+ ` app ` に登録した_middleware_は、リクエスト時に呼び出されているので、
57+ ` app ` のどこかに利用する_middleware_を保持していることは推測できると思います。
58+
59+ Connectでは` app.stack ` にまだに_middleware_が保持されています。
60+ 次のような` app.stack ` の中身を表示見ることで、_ middleware_が登録順で保持されていることがわかります。
61+
62+ [ import connect-trace-example.js] ( ../../src/connect/connect-trace-example.js )
63+
64+ 後は、サーバへリクエストがやってきた時に、それぞれの_middleware_を順番に呼び出しています。
65+
66+ 上記の例だと以下の順番で_middleware_が呼び出されることになります。
67+
68+ - errorHandler
69+ - nosniff
70+ - hello
71+
72+ エラーハンドリングの_middleware_はエラー時のみ呼ばれるため例外なので、
73+ [ nosniff.js] ( #nosniff.js ) ->[ hello.js] ( #hello.js ) と呼び出されます。
74+
75+ [ import nosniff.js] ( ../../src/connect/nosniff.js )
76+
77+ ` nosniff.js ` は、処理が終わったら` next() ` を呼び出していて、
78+ この` next() ` が次の_middleware_へ行くという意味になります。
79+
80+ 次に、` hello.js ` を見てみると、` next() ` がないことがわかります。
81+
82+ [ import hello.js] ( ../../src/connect/hello.js )
83+
84+ ` next() ` がないということは` hello.js ` がこの連続する_middleware_の最後となっていることがわかります。
85+ 仮に、これより先に_middleware_が登録されていたとしても無視されます。
86+
87+ このような_middleware_を繋げた形を_middleware stack_と呼ぶことがあります。
88+
89+ HTTPサーバではこのような_middleware stack_を作って使うものは既にあり、
90+ PythonのWSGI MiddlewareやRubyのRackなどが該当します。
91+
92+ Connectは` use ` というメソッドで_middleware_を使うことからも分かりますが、
93+ Rackを参考にして実装されています。
94+
95+ - [ Ruby - Rack解説 - Rackの構造とRack DSL - Qiita] ( http://qiita.com/higuma/items/838f4f58bc4a0645950a#2-5 " Ruby - Rack解説 - Rackの構造とRack DSL - Qiita ")
96+