LoginSignup
0
0

Node-REDのhttp inノードでワイルドカードを使う

Last updated at Posted at 2023-09-20

Node-REDのhttp inノードで若干ハマったのでメモ

Node-REDで簡単なWebサーバーを作る場合はhttp inノードを使用します。
以下のような存在しないページに対するアクセスにカスタムの404ページを返す動作を実現する方法がないか調べてみました。

  • /testへのアクセスには特定のWebページを返す。
  • /test以外(たとえば/とか/test/123とか/hogeとか)へのアクセスには404ページを返す。

一部のリソースだけは専用の応答を返し、それ以外は全部固定のエラーを返すようなイメージです。
ヘルプには載っていなかったのですが、Node-REDのフォーラムに以下の投稿がありました。

http inノードのURLはワイルドカード指定が可能のようです。
以下のようなフローを作ってみました。

image.png

/testにアクセスすると確かに/testのhttp inノードが呼ばれます。ちなみに/test/も同様でした。
image.png

//test/123/hogeにアクセスするとやはり/*のhttp inノードが呼ばれました。
image.png

どのhttp inノードが呼ばれるかはURLの最長一致で決まるんでしょうね。

ワイルドカードのhttp inは最後に置くべし?

これで完璧じゃんと思ったのですが、いろいろいじってみるとさっきと動作が違うことに気づきました。
ためしに/testのhttp inノードを削除後すぐに/testのhttp inノードを再配置してデプロイしてみます。
そして/testを再度呼び出してみるとなんということでしょう\*のhttp inノードが呼び出されています。
image.png

次に/*のhttp inノードを削除して同様に再配置してデプロイします。
今度は正常に戻りました。
image.png

ノードが配置された順番に待ち受けるパスが先着で決まっていくような挙動になっているように見えます。

  • すでに/*のhttp inノードが存在する場合、/以降のパスはすべて予約済みになり、
    後から/testのhttp inノードが来てもすでに先客がいるから/testで待ち受けることはできない。
  • 一方で/*のhttp inノードをいったん削除したら予約済みだったパスが解放されるので、
    /testのhttp inノードが待ち受けることができるようになる。

要はより曖昧なマッチングをするhttp inノードは最後に置けということになります。
今回のようなざっくりとしたものではなく、もっと細かく階層ごとにワイルドカード指定するような場合などは気づきにくいので注意が必要ですね。

こういうのってどこかのドキュメントに書いていたりしますかね?もしかして常識?

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0