ComfyUI Node

HTTP Session Manager

One login, one base URL, many requests

By wawahuy·Created about a year ago·Updated 11 months ago· 14
HTTP Session Manager
    • session
    session_namedefault_session
    base_url
    timeout30
    headers{}
    cookies{}
    auth_typenone
    username
    password
    token
    api_key
    api_key_headerX-API-Key
    verify_ssltrue
    proxy_url
    max_retries3
    retry_delay1.00

    Hit the same API five times in one workflow and you'll feel the pain this node cures: five nodes each asking for the same token, the same headers, the same cookie. HTTP Session Manager is the pack's "configure once, reuse everywhere" node. It holds your base URL, auth, headers, cookies, and retry settings in one place, then hands out a session object that every method node can share - so those five nodes just take a relative URL and the same session wire.

    It's the node you reach for as soon as a workflow makes more than one call to the same API.

    How it works

    Three required inputs:

    • session_name - the session's key (default default_session). Requests share a session by this name.
    • base_url - the API root. When a method node gets a relative URL like /users/me plus this session, the node joins them into the full URL. Big convenience, no string-building.
    • timeout - applied to every request on the session (default 30s).

    Then the configuration that replaces per-node setup: headers and cookies as JSON strings, auth_type (none/basic/bearer/api_key/token) with its matching username/password/token/api_key/api_key_header fields, plus verify_ssl, proxy_url, max_retries (default 3), and retry_delay (default 1s, with exponential backoff between retries).

    One output: session (HTTP_SESSION). Fan it out to as many request nodes as you like.

    The gotcha nobody mentions

    Sessions are stored in a class-level dictionary keyed by session_name, and they persist for the life of the ComfyUI process - across runs of the same workflow and even across different graphs. That's usually what you want (cookies survive, so a login handshake in one run carries into the next), but it cuts both ways:

    • Change the session's config and rerun: the old client object is reused, so stale headers or auth can linger. The node re-applies settings on every run, but cookies and connection state from previous runs stick around.
    • Two workflows using the same session_name share state. Rename sessions per workflow if you want isolation.
    • There's no UI to close a session - close_session/close_all_sessions exist in code but no node exposes them. A restart is the only reset from the graph.

    Install

    ComfyUI Manager → search "ComfyUI-HTTP" → Install, restart. Manual:

    cd ComfyUI/custom_nodes/
    git clone https://github.com/wawahuy/ComfyUI-HTTP.git
    cd ComfyUI-HTTP
    pip install -r requirements.txt
    

    No models; it's a requests.Session wrapper, so no heavy dependencies.

    Where people get burned

    The "stale state across runs" one is the classic - you change the token in the session manager, rerun, and the old token still goes out because cookies or auth persisted. If an authenticated workflow starts mysteriously failing after an unrelated change, restart ComfyUI or rename the session before you start debugging the API. And remember: a session only exists in memory, so it doesn't survive a ComfyUI restart - re-run the manager node and it rebuilds from scratch.

    CategoryHTTP/Session

    Inputs (15)

    NameTypeDefaultDescription
    session_nameSTRINGdefault_session
    base_urlSTRING
    timeoutINT301–300
    headersoptSTRING{}
    cookiesoptSTRING{}
    auth_typeoptCOMBOnone5 options: none, basic, bearer, api_key, token
    usernameoptSTRING
    passwordoptSTRING
    tokenoptSTRING
    api_keyoptSTRING
    api_key_headeroptSTRINGX-API-Key
    verify_ssloptBOOLEANtrue
    proxy_urloptSTRING
    max_retriesoptINT31–10
    retry_delayoptFLOAT1.000.1–10

    Outputs (1)

    NameTypeDescription
    sessionHTTP_SESSION