@@ -49,3 +49,48 @@ Echoサーバでは `req.pipe(res);` という形でリクエストをそのま
49
49
50
50
> ** Note** _ middleware_となる関数の引数が4つであると、それはエラーハンドリングの_middleware_とするという、Connect独自のルールがあります。
51
51
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
+
0 commit comments