Node-REDのhttp inノードで若干ハマったのでメモ
Node-REDで簡単なWebサーバーを作る場合はhttp inノードを使用します。
以下のような存在しないページに対するアクセスにカスタムの404ページを返す動作を実現する方法がないか調べてみました。
-
/test
へのアクセスには特定のWebページを返す。 -
/test
以外(たとえば/
とか/test/123
とか/hoge
とか)へのアクセスには404ページを返す。
一部のリソースだけは専用の応答を返し、それ以外は全部固定のエラーを返すようなイメージです。
ヘルプには載っていなかったのですが、Node-REDのフォーラムに以下の投稿がありました。
http inノードのURLはワイルドカード指定が可能のようです。
以下のようなフローを作ってみました。
/test
にアクセスすると確かに/test
のhttp inノードが呼ばれます。ちなみに/test/
も同様でした。
/
や/test/123
、/hoge
にアクセスするとやはり/*
のhttp inノードが呼ばれました。
どのhttp inノードが呼ばれるかはURLの最長一致で決まるんでしょうね。
ワイルドカードのhttp inは最後に置くべし?
これで完璧じゃんと思ったのですが、いろいろいじってみるとさっきと動作が違うことに気づきました。
ためしに/test
のhttp inノードを削除後すぐに/test
のhttp inノードを再配置してデプロイしてみます。
そして/test
を再度呼び出してみるとなんということでしょう\*
のhttp inノードが呼び出されています。
次に/*
のhttp inノードを削除して同様に再配置してデプロイします。
今度は正常に戻りました。
ノードが配置された順番に待ち受けるパスが先着で決まっていくような挙動になっているように見えます。
- すでに
/*
のhttp inノードが存在する場合、/
以降のパスはすべて予約済みになり、
後から/test
のhttp inノードが来てもすでに先客がいるから/test
で待ち受けることはできない。 - 一方で
/*
のhttp inノードをいったん削除したら予約済みだったパスが解放されるので、
/test
のhttp inノードが待ち受けることができるようになる。
要はより曖昧なマッチングをするhttp inノードは最後に置けということになります。
今回のようなざっくりとしたものではなく、もっと細かく階層ごとにワイルドカード指定するような場合などは気づきにくいので注意が必要ですね。
こういうのってどこかのドキュメントに書いていたりしますかね?もしかして常識?