HTTP-сервер

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"    # Макс. время чтения заголовков запроса
  write: "60s"   # Макс. время записи ответа
  idle: "120s"   # Таймаут keep-alive

• read — короткий (5-10с) для API, больше для загрузок
• write — соответствует ожидаемому времени генерации ответа
• idle — баланс между переиспользованием соединений и потреблением ресурсов

Конфигурация Host

Секция host настраивает внутренний relay сообщений сервера, используемый такими компонентами, как WebSocket relay:

host:
  buffer_size: 2048
  worker_count: 8

Безопасность

HTTP-серверы могут иметь контекст безопасности по умолчанию, применяемый через конфигурацию lifecycle:

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

Это устанавливает базового актёра и политики для всех запросов. Для аутентифицированных запросов middleware token_auth переопределяет актёра на основе валидированного токена, что позволяет применять политики безопасности на уровне пользователя.

Lifecycle

Серверы управляются supervisor'ом:

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

Подключение компонентов

Роутеры и статические обработчики ссылаются на сервер через metadata:

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:
  # Публичное API
  - name: public
    kind: http.service
    addr: ":8080"
    lifecycle:
      auto_start: true

  # Админка (только localhost)
  - name: admin
    kind: http.service
    addr: "127.0.0.1:9090"
    lifecycle:
      auto_start: true

TLS

Сервер может сам терминировать TLS. Установите tls.mode в manual (вы предоставляете свой сертификат) или auto (сертификат предоставляется драйвером overlay-сети, напр. network.tailscale). Обычные clearnet-listener'ы не поддерживают auto. Опустите tls или оставьте mode пустым для работы по обычному HTTP.

В режиме auto сервер не должен указывать cert/key — их предоставляет сетевой драйвер.

Ручной сертификат

При mode: manual поля cert и key содержат PEM. Задать это содержимое можно одним из трёх способов (выберите один на поле, никогда не смешивайте):

1. Inline PEM — буквальная PEM-строка.
2. Ссылка file:// — путь относительно манифеста, разрешается и встраивается при загрузке (защищён от обхода каталогов).
3. Ссылка на реестр окружения — извлечение PEM из зарегистрированной переменной окружения при декодировании через плейсхолдер ${env:NAME}.

- 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). Это не сырая переменная окружения ОС; значение ОС доступно только если под этим именем зарегистрирована переменная на базе env.storage.os. Значение по умолчанию задаётся как ${env:NAME|default}.

Mutual 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 (inline PEM, file:// или ${env:NAME}). Устаревшее парное поле client_ca_env также объявлено устаревшим в пользу client_ca: ${env:NAME}.

verify_if_given и require_and_verify требуют CA. request и require_any принимают любой клиентский сертификат без проверки CA.

См. также

• Маршрутизация — роутеры и эндпоинты
• Статические файлы — раздача статики
• Middleware — доступные middleware
• Безопасность — политики безопасности
• WebSocket Relay — WebSocket-сообщения