HTTPサーバー

http.serviceはリスナーを所有し、ルーター、エンドポイント、静的ファイルハンドラをホストします。

分類：サーバー設定リファレンス。 すべての参照先となるネットワーク、環境、ファイルシステム、ルーター、証明書、アクター、ポリシーの各エントリを定義していないブロックは、レジストリの一部分です。

設定

- name: gateway
  kind: http.service
  addr: ":8080"
  timeouts:
    read: "5s"
    write: "30s"
    idle: "60s"
  host:
    buffer_size: 1024
    worker_count: 4
  lifecycle:
    auto_start: true
    security:
      actor:
        id: "http-gateway"
      policies:
        - app:http_policy

タイムアウト

リソースの枯渇を防ぐためにタイムアウトを設定します：

timeouts:
  read: "10s"    # Max time to read the entire request (headers + body)
  write: "60s"   # Max time to write response
  idle: "120s"   # Keep-alive timeout

• read — APIでは短く（5～10秒）、アップロードでは長く設定
• write — 想定されるレスポンス生成時間に合わせて設定
• idle — 接続の再利用とリソース使用量のバランスを取って設定

ホスト設定

hostセクションは、WebSocketリレーなどのコンポーネントが使用する、サーバー内部のメッセージリレーを設定します：

host:
  buffer_size: 2048
  worker_count: 8

セキュリティ

HTTPサーバーには、ライフサイクル設定を通じてデフォルトのセキュリティコンテキストを適用できます：

lifecycle:
  auto_start: true
  security:
    actor:
      id: "gateway-service"
    policies:
      - app:http_access_policy

これにより、すべてのリクエストに基本となるアクターとポリシーが設定されます。認証されたリクエストでは、token_authミドルウェアが検証済みトークンに基づいてアクターを上書きし、ユーザーごとのセキュリティポリシーを適用できるようにします。

ライフサイクル

サーバーはスーパーバイザーによって管理されます：

lifecycle:
  auto_start: true
  start_timeout: 30s
  stop_timeout: 60s
  requires:
    - app:database

コンポーネントの接続

ルーターと静的ハンドラは、メタデータを介してサーバーを参照します：

entries:
  - name: gateway
    kind: http.service
    addr: ":8080"

  - name: api
    kind: http.router
    meta:
      server: gateway
    prefix: /api

  - name: static
    kind: http.static
    meta:
      server: gateway
    path: /
    fs: app:public

複数のサーバー

目的ごとに別のサーバーを実行できます：

entries:
  # Public API
  - name: public
    kind: http.service
    addr: ":8080"
    lifecycle:
      auto_start: true

  # Admin (localhost only)
  - name: admin
    kind: http.service
    addr: "127.0.0.1:9090"
    lifecycle:
      auto_start: true

TLS

サーバーはTLSを直接終端できます。独自の証明書を指定する場合はtls.modeをmanualに、オーバーレイネットワークドライバーから証明書を取得する場合はauto（network.tailscaleなど）に設定します。通常のクリアネットリスナーではautoを使用できません。平文HTTPで実行するには、tlsを省略するかモードを空のままにします。

autoモードではサーバーはcert/keyを指定してはいけません — ネットワークドライバが提供します。

手動証明書

mode: manualでは、certとkeyがPEMコンテンツを保持します。そのコンテンツは次の3つの方法のいずれかで指定します（フィールドごとに1つを選び、混在させないでください）：

1. インラインPEM — PEM文字列そのもの。
2. file://参照 — マニフェストからの相対パス。読み込み時に解決されインライン化されます（トラバーサル安全）。
3. 環境レジストリ参照 — ${env:NAME}プレースホルダを使い、デコード時に登録済みの環境変数からPEMを取得します。

- name: api
  kind: http.service
  addr: ":443"
  tls:
    mode: manual
    cert: file://./certs/server.pem
    key:  file://./certs/server.key

- name: api
  kind: http.service
  addr: ":443"
  tls:
    mode: manual
    cert: ${env:app.env:tls_cert}
    key:  ${env:app.env:tls_key}

${env:NAME}プレースホルダは、環境レジストリを通じてNAMEを解決します — 登録済み変数の公開名またはそのエントリID（例: app.env:tls_cert）です。これは生のOS環境変数ではありません。OSの値に到達できるのは、env.storage.osをバックエンドとする変数がその名前で登録されている場合のみです。デフォルト値は${env:NAME|default}で指定できます。

相互TLS（mTLS）

mode: manualでは、クライアント証明書も検証できます：

tls:
  mode: manual
  cert: ${env:app.env:tls_cert}
  key:  ${env:app.env:tls_key}
  client_ca: file://./certs/clients-ca.pem
  client_auth: require_and_verify

client_caはcert/keyと同じ3つの形式（インラインPEM、file://、${env:NAME}）を受け付けます。従来のclient_ca_envの対応フィールドも同様に非推奨であり、client_ca: ${env:NAME}を推奨します。

verify_if_givenとrequire_and_verifyにはCAが必要です。requestとrequire_anyは、CA検証なしですべてのクライアント証明書を受け入れます。

関連項目

• ルーティング - ルーターとエンドポイント
• 静的ファイル - 静的ファイルの配信
• ミドルウェア - 利用可能なミドルウェア
• セキュリティ - セキュリティポリシー
• WebSocketリレー - WebSocketメッセージング