NGINX Plus R29の発表

Principal Product Manager

Sr Product Manager

May 2, 2023

NGINX Plus Release 29 (R29)の提供を開始することをお知らせします。NGINX Plusは、NGINXオープンソースをベースにした、唯一のオールインワン・ソフトウェアWebサーバー、ロードバランサー、リバースプロキシ、コンテンツキャッシュ、およびAPIゲートウェイです。
NGINX Plus R29の新機能は以下の通りです。

MQTTプロトコルのサポート– Message Queuing Telemetry Transport(MQTT)は Internet Of Things(IoT)で利用するデバイス間の通信に利用される軽量なプロトコルです。NGINX Plus R29はMQTTプロトコルのサポートとともに、MQTTトラフィックのセキュアな管理を可能にする新たなディレクティブや変数を提供するPrereadやFilterモジュールをサポートします。

認証と認可で利用するSAMLのサポート – Security Assertion Markup Language(SAML)はウェブアプリケーションに対するシングルサインオン(SSO)を提供するために利用されるプロトコルです。NGINX Plusはユーザーを認証するSAML認証プロバイダ(IdP)に対する、SAMLサービスプロバイダ(SP)として設定することが可能となりました。

ネイティブOpen Telemetry – Open Telemetry(OTel)はベンダーに依存しない形で外部ソースからテレメトリーデータ(トレース、メトリクス、ログ)を生成、収集、出力するフレームワークです。新たに提供するNGINX OTeL動的モジュールはNGINX Plus で高性能なOTelの導入を提供し、HTTPリクエストのトレーシングを取得します。

実験的なQUIC＋HTTP/3パッケージ – QUIC+HTTP/3とNGINX Plus R29のプレビューパッケージが利用可能になりました。NGINX Plus R29 QUICパッケージはQUICの接続やHTTP/3のトラフィックを管理するためのHTTPコンテキスト、新たなディレクティブの提供をサポートします。

重要な動作の変化

注：もしNGINX Plus R28以外のリリースからアップグレードする場合、現在利用中のリリースから今回のリリースまでの過去のブログで紹介されている「重要な動作の変化」の項目を必ず確認してください。

パッケージ提供リポジトリの変更

古いパッケージ提供リポジトリplus-pkgs.nginx.comはNGINX Plus R29の提供と同時に廃止になります。このリポジトリはNGINX Plus R25からアップデートはされません。また、NGINX Plus R24から提供されるpkgs.nginx.comの利用が強く推奨されます

プラットフォーム対応の変更

新たに以下のプラットフォームがサポートされます。

Amazon Linux 2023

以下プラットフォームはサポート対象外となります。

Alpine 3.13(2022年11月1日にEOL)

以下プラットフォームはNGINX Plus R30でサポート対象外となる予定です。

Ubuntu 18.04(2023年6月にEOL)
Alpine 3.14(2023年5月にEOL)

ModSecurity EOLのアナウンスに関する対応

ModSecurityのEOL発表に合わせて、NGINX Plus R29はModSecurityパッケージのサポートを削除します。もしModSecurityパッケージの利用を利用している場合、まもなくModSecurityからNGINX App Protectへの切り替えプログラムの利用が可能になります。これらの詳細は近日案内されます。詳細についてはF5へお問い合わせください。

新機能の詳細

MQTTプロトコルのサポート

MQTT (Message Queuing Telemetry Transport)は人気で軽量なパブリッシュ-サブスクライブなメッセージ交換のプロトコルで、IoTデバイスやインターネット上のアプリケーション(クライアント)の接続に最適です。あるトピックに対してクライアントがメッセージをパブリッシュ(投稿)や他のトピックのサブスクライブ(購読)することが可能になります。サブスクライブを行ったクライアントはそのトピックに対してパブリッシュされたすべてのメッセージを受け取り、多くのデバイスやサービス間における効果的で耐障害性に優れたデータの交換が可能になります。

MQTTの中心となる機能がブローカーです。ブローカーはクライアントやそのクライアントがサブスクライブするトピックや、メッセージの処理、それらのメッセージを適切なシステムに転送することを役割に持つサーバです。NGINX Plus R29はMQTT 3.1.1とMQTT 5.0をサポートします。これはクライアントとブローカー間のプロキシとして動作し、システムの構成を簡素化し、機能のオフロードや、コストの削減を実現します。

このたび提供するMQTTの機能は以下の内容です。

MQTTブローカーの負荷分散
セッション維持(クライアントを同じブローカーに接続する)
TLSの終端
クライアント証明書認証
CONNECTメッセージのパースと書き換え

MQTTとプロトコルは複数のメッセージタイプを定義し、CONNECT、PUBLISH、SUBSCRIBEが含まれます。NGINX Plus R29は様々なMQTTのCONNECTメッセージをパースし書き換え、以前はカスタムスクリプトのみで可能であった設定のシナリオを実現することができるようになりました。

MQTTのメッセージのパースや書き換えはNGINX設定ファイルのStreamコンテキストに定義する必要があり、ngx_stream_mqtt_preread_module
やngx_stream_mqtt_filter_moduleによって可能となっています。

MQTTの記述例

MQTTのデバイスによって送付されるデフォルトのクライアント識別子を変更することにより、NGINXはデバイスのシリアルナンバーなど機密情報を隠すことが可能になります。このはじめのレイデイは、識別子がデバイスのIPアドレスとなっています。

注：デバイスのIPアドレスをMQTTのクライアントの識別子とすることは本番環境では推奨されていません。

stream {
      mqtt on;

      server {
          listen 1883;
          proxy_pass 10.0.0.8:1883;
          mqtt_rewrite_buffer_size 16k;
          mqtt_set_connect clientid '$remote_addr';
      }
  }

MQTTクライアントの一時的な性質を考慮すると、単純にデバイスのホスト名やIPアドレスを使ったブローカーへの負荷分散におけるセッションの維持は適切なものではありません。この例では、デバイスのMQTTクライアント識別子が、クラスタへの負荷分散の際に個々のMQTTブローカーへ通信の維持を行うためのハッシュキーとして利用されます。

stream {
      mqtt_preread on;

      upstream brokers{
          zone tcp_mem 64k;
          hash $mqtt_preread_clientid consistent;

          server 10.0.0.7:1883; # mqtt broker 1
          server 10.0.0.8:1883; # mqtt broker 2
          server 10.0.0.9:1883; # mqtt broker 3
      }

      server {
          listen 1883;
          proxy_pass brokers;
          proxy_connect_timeout 1s;
      }
  }

次のステップ

NGINX Plusにおける将来的な実装では、CONNECTメッセージの詳細なパースと同様に、その他のMQTTメッセージ種別のパースを含む可能性があり、以下のような機能が有効になります。

追加の認証、アクセスコントロール機能
ブローカー保護を目的とした、頻繁にメッセージを送るクライアントに対するレートリミット
メッセージに対する観測機能やコネクションのメトリクスの提供

我々は、みなさんがご興味のある機能に関する機能に対してのフィードバックを歓迎します。お気軽にコメントをお寄せください。

認証と認可で利用するSAMLのサポート

SAML(Security Assertion Markup Language)は認証プロバイダ(IdP)がリソースへの接続を行うためユーザーの認証(エンドユーザーが実際に誰であるのか確認すること)を行い、ユーザーが接続するシステムのアクセス権限と一緒に認証情報を、認可を行うサービスプロバイダ(SP)へ転送することを可能にする、オープンなフェデレーションの標準技術です。

ID データを交換するための安全な手段を提供してきた長い実績を持つSAMLは、IdPとSPの間で認証および認可の情報を交換するために広く採用されているプロトコルです。

企業や政府機関がSAMLの採用を選択する主な理由は次のとおりです。

大規模の認証情報に対する効果的に管理
顧客や従業員に対して強化された一貫性のある統合されたIDセキュリティ
標準化されたID管理プロセスによる運用効率の向上
規制やコンプライアンスの効率的な処理

SAMLはいくつかの利益を提供します。

優れたユーザー体験：IdPにおけるSSOの統合と単一箇所での認証の検証により、SAMLはユーザーが接続するすべてのサービスに対する単一の認証を提供します。これによりユーザー体験は向上し、ユーザーは複数のアプリケーションに対する複数の認証情報を覚える必要がなくなるため時間の節約が可能となります。
セキュリティの向上：組織のセキュリティおよび認証ポリシーに応じて、ユーザーは SP インターフェース (SP-initiated SSO) または IdP インターフェース (IdP-initiated SSO) で SSO 認証スキームを使用してログインできます。これにより、潜在的に弱いパスワードや繰り返されるパスワードに起因するセキュリティリスクを低減することができます。
管理コストの削減：SAML は、組織が ID 管理の責任を信頼できる IdP にオフロードするのに役立ちます。これにより、アカウント情報を維持するコストと関連する費用が削減されます。
標準化されたプロトコル：セキュリティを (可能な限り) アプリケーションロジックから独立させるという原則に基づいて設計された SAML は、ほぼすべての IdP およびアクセス管理システムでサポートされている標準化されたプロトコルです。プラットフォームアーキテクチャや特定のベンダーの実装からセキュリティフレームワークを抽象化することで、堅牢なセキュリティとシステム間の信頼性の高い統合を可能にします。

現在提供するSAMLの参考の実装はSAML 2.0を使用し、NGINX JavaScript (njs)フレームワークを使用して構築されています。この実装では、NGINX PlusはSAML SPとして機能し、SAML IdPを使用してSSO利用環境に参加できるようにします。現在の実装は、既存のNGINX Plusの機能であるキーバリューストアに依存しているため、追加で実装の変更をしない場合NGINXオープンソースには適用できません。

NGINX PlusでのSAMLのサポートは、GitHub 上にある参考の実装を利用できるというものです。GitHubリポジトリには、特定のユースケース向けのインストール、構成、および微調整に関する手順が記載されたサンプルの設定が含まれています。

OpenTelemetryのネイティブ提供

OpenTelemetry (OTel) は、アプリケーションの監視、トレース、トラブルシューティング、および最適化に使用できる標準的なテクノロジです。デプロイされたアプリケーションスタック内のプロキシ、アプリケーション、またはその他のサービスなど、OTelは様々なソースからテレメトリデータを収集することによって機能します。

プロトコル対応のリバースプロキシおよびロードバランサーとして、NGINXは、アプリケーションの要求と応答を追跡するためのテレメトリ呼び出しを開始するのに理想的な位置にあります。サードパーティのOTelモジュールはしばらくの間利用可能でしたが、新しい動的モジュールを使用してNGINX PlusでOTelのネイティブのサポートを発表できることを嬉しく思います。

新しいモジュールngx_otel_moduleは、nginx-plus-module-otelパッケージを使用してインストールすることができ、サードパーティモジュールに対して次のようないくつかの重要な改善を提供します。

パフォーマンスの向上 – ほとんどのOTel実装では、トレースが有効になっている場合、リクエスト処理のパフォーマンスが最大 50% 低下します。新しいネイティブモジュールは、この影響を約 10 ～ 15% に抑えます。
簡単なプロビジョニング – テレメトリコレクションのセットアップと導入が、NGINXの設定ファイルで直接行うことができます。
完全に動的な変数ベースのサンプリング – Cookie/トークンによって特定のセッションをトレースし、NGINX Plus APIおよびキーバリューストアモジュールを介してモジュールを動的に制御することが可能です。

OTelの動的モジュールの詳細については、NGINXのドキュメントを参照してください。

OTelによるトレーシングの例

アプリケーションの基本的な OTelトレース情報をNGINXが直接提供する例を次に示します。

load_module modules/ngx_otel_module.so;

  events {}

  http {
      otel_exporter {
          endpoint localhost:4317;
      }
   

      server {
          listen 127.0.0.1:8080;
          

          otel_trace on;
          otel_span_name app1;
      }
  }

この次の例では、受信するリクエストからトレースコンテキストを継承し、親スパンがサンプリングされた場合にのみスパンを記録します。また、トレースコンテキストとサンプリングの決定をアップストリームサーバーに伝達します。

load_module modules/ngx_otel_module.so;

  http {
      server {
          location / {
              otel_trace $otel_parent_sampled;
              otel_trace_context propagate;
              proxy_pass http://backend;
          }
      }
  }

この比率を指定した例では、トラフィックを指定した割合 (この場合は 10%) に対してトレースが構成されるようになります。

http {
      # trace 10% of requests
      split_clients "$otel_trace_id" $ratio_sampler {
          10%     on;
          *       off;
      }

      # or we can trace 10% of user sessions

      split_clients "$cookie_sessionid" $session_sampler {
          10%     on;
          *       off;
      }

      server {
          location / {
              otel_trace $ratio_sampler;
              otel_trace_context inject;

              proxy_pass http://backend;
          }
      }
  }

このAPI制御の例では、/apiエンドポイントを介してキーバリューストアを操作することにより、トレースが有効になります。

http {
      keyval "otel.trace" $trace_switch zone=name;

      server {
          location / {
              otel_trace $trace_switch;
              otel_trace_context inject;
              proxy_pass http://backend;
          }

          location /api {
              api write=on;
          } 
      }
  }

実験的なQUIC＋HTTP/3パッケージ

NGINXオープンソースのプレビューバイナリパッケージの発表に続いて、NGINX Plus R29の実験的なQUICパッケージを発表できることを嬉しく思います。これにより、NGINX Plus を使用した HTTP/3 のテストと評価が可能になります。

新しい基盤となるプロトコルスタックにより、HTTP/3 は UDP と QUIC をトランスポート層として利用します。 QUICは、接続の多重化を提供し、ヘッドオブラインブロッキングなどの問題を解決することにより、TCP を改善するように設計された暗号化されたトランスポートプロトコルです。接続の確立、輻輳制御、信頼性の高い配信など、HTTP/1.1 および HTTP/2 の多くの TCP機能を再実装および強化します。また、TLSを別のレイヤーとして持つ HTTP/1.1 および HTTP/2 とは異なり、QUICは、TLSを統合されたコンポーネントとして組み込みます。これは、HTTP/3 メッセージがデフォルトで暗号化された接続を介して送信されるため、本質的に安全であることを意味します。

通常、安全な通信と暗号化機能のために、NGINX Plusは、オペレーティングシステムに同梱されている SSL/TLSライブラリとして利用されているOpenSSLに依存しています。ただし、この記事の執筆時点では、QUICのTLSインターフェースはOpenSSLでサポートされていないため、HTTP/3 で必要とされる不足している TLS機能を提供するには、サードパーティライブラリが必要です。

この懸念に対処するために、QUICに用いるOpenSSLの互換性レイヤーを開発しました。これにより、quictls、BoringSSL、LibreSSL などのサードパーティのTLSライブラリを構築して出荷する必要がなくなりました。これにより、カスタムTLS実装の負担や、サードパーティライブラリのスケジュールやロードマップへの依存なしに、NGINXでエンドツーエンドのQUIC+HTTP/3エクスペリエンスを管理できます。

注: OpenSSL互換性レイヤーは実験的な NGINX Plus QUIC+HTTP/3 パッケージに含まれており、TLSv1.3(QUIC プロトコルで必要) を提供するにはOpenSSL 1.1.1以降が必要です。0-RTTはまだ実装されていません。

QUIC+HTTP/3のサンプル設定

NGINX Plus での QUIC+HTTP/3 の設定例を見てみましょう。

http {
      log_format quic '$remote_addr - $remote_user [$time_local]'
      '"$request" $status $body_bytes_sent '
      '"$http_referer" "$http_user_agent" "$http3"';

      access_log logs/access.log quic;

      server {
          # for better compatibility it's recommended
          # to use the same port for quic and https
          listen 8443 quic reuseport;
          listen 8443 ssl;

          ssl_certificate     certs/example.com.crt;
          ssl_certificate_key certs/example.com.key;

          location / {
              # required for browsers to direct them into quic port
              add_header Alt-Svc 'h3=":8443"; ma=86400';
          }
      }
  }

HTTP/2の実装と同様に、NGINX Plus がプロキシとして機能する場合、クライアント側で QUIC+HTTP/3 接続が作成され、バックエンドおよびアップストリームサービスに接続する際に HTTP/1.1に変換されます。

NGINX Plus QUIC+HTTP/3 実験的なパッケージは別のリポジトリから入手でき、既存のNGINX Plus証明書とキーでアクセスできます。実験的なQUICパッケージのインストールは、標準のNGINX Plusインストールに似ています。インストール手順で強調表示されているように、必ず QUIC リポジトリを使用してください。

QUIC+HTTP/3用にNGINXを構成する方法の詳細については、QQUIC+HTTP/3用にNGINXを構成するを参照してください。すべての新しいディレクティブと変数の詳細については、nginx-quic READMEの構成セクションを参照してください。

次のステップ

近い将来、QUIC+HTTP/3コードをNGINXメインラインブランチにマージする予定です。その後、QUIC+HTTP/3をサポートする NGINXメインラインの最新バージョンは、次のNGINX Plusリリースにマージされます。今年後半に、NGINX PlusでのQUIC+HTTP/3 サポートが正式に利用可能となることに関する発表を期待してください。

NGINX Plus R29 のその他の機能強化

OpenID Connectの変更点

OpenID Connect (OIDC) サポートは NGINX Plus R15 で導入され、その後のバージョンで大幅に強化されました。 NGINX Plus R29 は、以下の追加により、OIDC を強化し続けています。

アクセストークンのサポート

アクセストークンはトークンベースの認証で使用され、OIDC クライアントがユーザーに代わって保護されたリソースにアクセスできるようにします。 NGINX Plusは、ユーザーがアクセスの認証と認可に成功した後にアクセストークンを受け取り、それをキーバリューストアに保存します。 NGINX Plusは、後段のアプリケーションに送信されるすべてのリクエストのBearerトークンとして、HTTP Authorization ヘッダーでそのトークンを渡すことができます。

注: : NGINX Plus は、(IDトークンの場合のように) 各リクエストでアクセストークンの有効性を検証せず、アクセストークンが既に期限切れになっているかどうかを知ることができません。アクセストークンの有効期間が ID トークンの有効期間よりも短い場合は、proxy_intercept_errors on ディレクティブを使用する必要があります。これにより、401 Unauthorized応答が傍受されて NGINX にリダイレクトされ、アクセストークンが更新されます。

NGINX Plusを使用した OpenID ConnectおよびJSON Web Token (JWT) 検証の詳細については、Authenticating Users to Existing Applications with OpenID Connect and NGINX Plusを参照してください。

OIDC 認証エンドポイントに追加された引数

Keycloakなどの一部のIDプロバイダでは、認証リクエストに追加のクエリ文字列引数を追加して、追加機能を有効にすることができます。たとえば、Keycloakでは、認証リクエストにkc_idp_hintパラメーターを追加することで、デフォルトのIdPを指定できます。この機能強化の一環として、ユーザーはOIDC承認エンドポイントに追加の引数を指定できます。

Prometheus-njs モジュールの拡張された SSL カウンター

NGINX Plus R28 では、クライアントサイドとサーバーサイドの接続における HTTPモジュールとストリームモジュールの両方で、ハンドシェイクエラーと証明書検証の失敗に対する追加のSSLカウンターのサポートを追加しました。 NGINX PlusメトリクスをPrometheus 準拠の形式に変換するPrometheus-njsモジュールが、これらのカウンターをサポートするようになりました。

新しい`internal_redirect`ディレクティブ

新しいinternal_redirectディレクティブとモジュールにより、リクエスト処理の制限、接続処理の制限、およびアクセス制限を確認した後、内部リダイレクトが可能になります。

internal_redirect構成の例を次に示します。

http {
      limit_req_zone $jwt_claim_sub zone=jwt_sub:10m rate=1r/s; 

       server {
          location / {
              auth_jwt "realm";
              auth_jwt_key_file key.jwk;

               internal_redirect @rate_limited;
          }

           location @rate_limited {
              internal;
              limit_req zone=jwt_sub burst=10;

              proxy_pass http://backend;
          }
      }
  }

上記の例では、ロケーションブロックで JWT 認証が実行され、トークンが有効な場合は、リクエストが内部コンテンツハンドラ @rate_limited に渡されますが、ここではsub claimの値に基づいてリクエストレート制限が適用されます。これは、リクエストがアップストリームサービスに渡される前に JWT で発生します。

この設定は、攻撃者が、subの値として特定のユーザー情報がエンコードされた読み取り可能なJWT を持つリクエストのフラッドを送信するサービス妨害 (DoS) 攻撃を防ぎます。その大量のリクエストは認証を通過しませんが、レート制限にカウントされます。リクエストをコンテンツのハンドラに渡す前に JWT を認証することで、有効なリクエストのみがレート制限にカウントされるようになります。

NGINX オープンソースから継承された変更

NGINX Plus R29 は、NGINX Open Source 1.23.4 に基づいており、NGINX Plus R28 がリリースされてから(NGINX 1.23.3 から 1.23.4)行われた機能変更とバグ修正を継承しています。

変更点

TLSv1.3プロトコルがデフォルトで有効になり、これらのディレクティブのデフォルト値になりました。

リッスンするソケットのプロトコルパラメータが再定義された場合、NGINX は警告を発行するようになりました。
クライアントがパイプライン処理を使用した場合、NGINX は接続を残して閉じるようになりました。
いくつかのエラーのログレベルがcritからinfoに引き下げられました。
data length too long, length too short, bad legacy version, no shared signature algorithms, bad digest length, missing sigalgs extension, encrypted length too long, bad length, bad key update, mixed handshake and non-handshake data, ccs received early, data between ccs and finished, packet length too long, too many warn alerts, record too small, got a fin before a ccs SSL

機能

ngx_http_gzip_static_moduleでバイト範囲がサポートされるようになりました。

バグフィックス

機能しなかったリッスンディレクティブのポート範囲を修正しました。
設定で 255 文字を超えるプレフィックスのlocationが使用された場合に、リクエストを処理するために誤った場所が選択される可能性がある問題を修正しました。
ngx_http_autoindex_module、ngx_http_dav_module、および include ディレクティブでサポートされていなかった Windows 上のファイル名の非 ASCII 文字を修正しました。
HTTP/2とerror_pageディレクティブを使用してコード400のエラーをリダイレクトするときに時々発生するソケットリークを修正しました。
syslogへのロギング中にエラーが発生したという情報が含まれていなかった、syslogエラーへのロギングに関するメッセージを修正しました。
proxy -r でブロックされたクライアント読み取りイベントの処理を修正しました。
多数のTLVを含むPROXYプロトコルバージョン2ヘッダーを読み取るときに発生することがあったエラーを修正しました。
他のモジュールによって作成されたサブリクエストを処理するために SSIが使用された場合にワーカープロセスで発生することがあったセグメンテーションフォールトを修正しました。
バックエンドへの SSL 接続が使用されている場合、NGINX がバッファリングされていないプロキシ中に CPU を占有する可能性がある問題を修正しました。

ワークアラウンド

zlib-ngの使用時に、「zip filter failed to use pre-allocated memory」のアラートがログに示されます。
listenディレクティブで使用されるhostnameが複数のアドレスに解決される場合、NGINX はこれらのアドレス内の重複を無視するようになりました。

このリリースから継承された新機能、変更、バグ修正、およびワークアラウンドの完全なリストについては、CHANGESファイルを参照してください。

NGINX JavaScript モジュールへの変更

NGINX Plus R29 には、NGINX JavaScript (njs) モジュールバージョン 0.7.9 から 0.7.12 への変更が組み込まれています。 njs には、次のようないくつかの優れた機能が追加されました。

拡張されたフェッチ API サポート
拡張されたWeb 暗号 API
XMLドキュメントのサポート
XMLキュメントの解析
XMLドキュメントを変更するための XMLNode API
Zlib モジュール圧縮のサポート

njs バージョン 0.7.9 から 0.7.12 までのすべての機能、変更、およびバグ修正の包括的なリストについては、njs Changes logを参照してください。

拡張されたフェッチ API サポート

Headers()、Request()、およびResponse()コンストラクターが Fetch API に追加され、その他の機能強化が行われました。

async function makeRequest(uri, headers) {
      let h = new Headers(headers);
      h.delete("bar");
      h.append("foo", "xxx");
      let r = new Request(uri, {headers: h});
      return await ngx.fetch(r);
  }

拡張されたWeb 暗号 API

JSON Web Key (JWK) 形式をサポートするように Web Crypto API が拡張され、importKey() は JWK 形式のキーを入力として受け取るようになりました。

async function importSigningJWK(jwk) {
     return await crypto.subtle.importKey('jwk', jwk,
                                          {name: "RSASSA-PKCS1-v1_5"},
                                          true, ['sign']);
  }

njs 0.7.10 では、generateKey()およびexportKey()メソッドも追加されました。generateKey()メソッドを使用すると、対称アルゴリズムの新しい鍵または公開鍵アルゴリズムの鍵ペアを生成できます。exportKey()メソッドは、CryptoKeyオブジェクトを入力として取り、キーを外部の移植可能な形式で返します。 JWK 形式をサポートし、キーを JSONオブジェクトとしてエクスポートします。

詳細については、Web Crypto APIを参照してください。

XMLドキュメントのサポート

XMLモジュールは njs 0.7.10 で追加され、XMLドキュメントを操作するためのネイティブサポートを提供します。

XMLキュメントの解析

XMLドキュメントの文字列またはバッファを解析できるようになりました。これにより、解析された XMLドキュメントを表すXMLDocラッパーオブジェクトが返されます。

const xml = require("xml");
  let data = `<note><to b="bar" a= "foo">Tove</to><from>Jani</from></note>`;
  let doc = xml.parse(data);
   

  console.log(doc.note.to.$text) /* 'Tove' */
  console.log(doc.note.to.$attr$b) /* 'bar' */
  console.log(doc.note.$tags[1].$text) /* 'Jani' */

XMLドキュメントを変更するための XMLNode API

XML ドキュメントを変更するために、njs 0.7.11 で XMLNode API が追加されました。

Const xml = require("xml");
  let data = `<note><to b="bar" a="foo">Tove</to><from>Jani</from></note>`;
  let doc = xml.parse(data);
   

  doc.$root.to.$attr$b = 'bar2';
  doc.$root.to.setAttribute('c', 'baz');
  delete doc.$root.to.$attr$a;
   

  console.log(xml.serializeToString(doc.$root.to))
  /* '<to b="bar2" c="baz">Tove</to>' */
   

  doc.$root.to.removeAllAttributes();
  doc.$root.from.$text = 'Jani2';
   

  console.log(xml.serializeToString(doc))
  /* '<note><to>Tove</to><from>Jani2</from></note>' */
   

  doc.$root.to.$tags = [xml.parse(`<a/>`), xml.parse(`<b/>`)];
  doc.$root.to.addChild(xml.parse(`<a/>`));

  console.log(xml.serializeToString(doc.$root.to))
  /* '<to><a></a><b></b><a></a></to>' */
   

  doc.$root.to.removeChildren('a');
   

  console.log(xml.serializeToString(doc.$root.to))
  /* '<to><b></b></to>' */

すべての XML 関連の拡張機能の詳細については、XML documentsを参照してください。

Zlib モジュール圧縮のサポート

zlib モジュールは njs 0.7.12 で追加され、deflate および inflate アルゴリズムを使用した圧縮機能を提供します。

Const zlib = require('zlib');
  zlib.deflateRawSync('αβγ').toString('base64')
  /* "O7fx3KzzmwE=" */
   

  zlib.inflateRawSync(Buffer.from('O7fx3KzzmwE=', 'base64')).toString()
  /* "αβγ" */

zlib の詳細については、zlib documentsを参照してください。

NGINX Plusのアップグレードまたは試用

NGINX Plusを実行している場合、できるだけ早くNGINX Plus R29にアップグレードすることを強くお勧めします。また、いくつかの追加修正と改善点をピックアップし、サポートチケットを発行する必要があるときにNGINXを支援することができるようになります。

NGINX Plusをまだお試しでない方は、セキュリティ、ロードバランシング、APIゲートウェイとして、あるいは強化された監視・管理APIを備えたフルサポートのウェブサーバーとして、ぜひお試しください。30日間の無料トライアルlで、今すぐ始めることができます。

ソリューション クイック リンク

製品クイック リンク

製品クイック リンク

製品クイック リンク

リソースのクイック リンク

ブログのクイックリンク

ブログのクイック リンク

クイックリンク

パートナーのクイックリンク

NGINX Plus R29の発表

重要な動作の変化

パッケージ提供リポジトリの変更

プラットフォーム対応の変更

ModSecurity EOLのアナウンスに関する対応

新機能の詳細

MQTTプロトコルのサポート

次のステップ

認証と認可で利用するSAMLのサポート

OpenTelemetryのネイティブ提供

実験的なQUIC＋HTTP/3パッケージ

NGINX Plus R29 のその他の機能強化

OpenID Connectの変更点

Prometheus-njs モジュールの拡張された SSL カウンター

新しいinternal_redirectディレクティブ

NGINX オープン ソースから継承された変更

NGINX JavaScript モジュールへの変更

拡張されたフェッチ API サポート

拡張されたWeb 暗号 API

XMLドキュメントのサポート

XMLキュメントの解析

Zlib モジュール圧縮のサポート

NGINX Plusのアップグレードまたは試用

著者について

Prabhat Dixit

著者について

Michael Vernik

About F5 NGINX

NGINXを使ってみよう

NGINXを体験したい

質問をしたい

ソリューションクイックリンク

製品クイックリンク

製品クイックリンク

製品クイックリンク

リソースのクイックリンク

ブログのクイックリンク

新しい`internal_redirect`ディレクティブ

NGINX オープンソースから継承された変更