HTTP 请求 (N8N风格)
An N8N-style HTTP request node that lives inside your workflow
- image_input
- vars_workflow
- vars_browser
- 响应文本
- 响应图像
- 状态码
- 响应JSON
If you've used n8n or Zapier, you know the drill: a node that fires a configurable HTTP request - method, URL, headers, auth, body - and hands back the response. ZML_N8N_HTTP_Full brings that to ComfyUI. The README says it's an n8n imitation "about 80% similar," and honestly the 80% is the useful part.
Why would a diffusion workflow need an HTTP node? Because the ecosystem keeps drifting toward API calls. The KB's API-wrapper doc covers the big one - cloud models that only exist behind an endpoint - but the humbler case is just automation: pinging a webhook, POSTing a finished image to a service, fetching a config, calling an LLM API mid-graph. A general-purpose request node is the glue that makes any of that possible without installing a pack per service.
How it works
The entire configuration lives in one hidden settings STRING field as JSON - method, URL, auth, query params, headers, body. The frontend gives you a proper editor UI for it; you rarely hand-write the JSON. Then the genuinely nice part:
- Template variables. Any
{{变量}}in your URL, headers, or body gets replaced at runtime. A workflow variable bundle (vars_workflow) and a browser-cached variable bundle (vars_browser) both feed the pool, and if you connect an image_input, a{{IMAGE_B64}}variable becomes available with your image base64-encoded. That's the hook for sending images to APIs. - Auth modes.
none,basic,bearer, or a customheader- the common API-authentication shapes, all template-aware. - Body types. raw text,
form-urlencoded, or JSON. A default Content-Type is set for you if you don't provide one. - Timeout - configurable, default 30s.
Outputs are the useful four:
- 响应文本 - the raw response body.
- 响应图像 - if the response Content-Type is an image, it's decoded straight into an IMAGE tensor (which closes the loop: fetch an image from an API, use it in your graph).
- 状态码 - the HTTP status.
- 响应JSON - parsed JSON if the response is JSON; otherwise a
{"error": ..., "raw": ...}dict so you're never left guessing.
Failures don't kill the workflow: a request error returns the error text, status 500, and an error dict instead of throwing.
Security, seriously
This node is where the KB's API-wrapper warning gets real: it reaches the network and it carries credentials. Your API keys in headers or auth fields are part of the settings JSON, which means they're baked into the workflow. The pack's own philosophy helps here - the author's LLM nodes store keys in browser cache specifically so shared workflows don't leak them - so prefer variable bundles over hardcoding secrets, and remember that every custom node runs arbitrary code (the ComfyUI_LLMVISION incident is the canonical warning).
Install
One node in ComfyUI-ZML-Image:
cd ComfyUI/custom_nodes
git clone https://github.com/zml-w/ComfyUI-ZML-Image
# restart ComfyUI
or ComfyUI Manager → search "ComfyUI-ZML-Image". Uses requests (in the pack requirements). Chinese-first UI; translation patch at https://github.com/zml-w/ZZZ_ZML_English_Patch.
It's an upgrade of the author's earlier plain HTTP node, so it's had iteration time. The trap beginners hit is expecting it to do something with the response - it doesn't; it returns data for you to wire onward. The image-output path is the exception and it's genuinely slick.
Inputs (4)
| Name | Type | Default | Description |
|---|---|---|---|
| settings | STRING | {} | — |
| image_inputopt | IMAGE | 输入图像,将自动转换为Base64格式,可在请求中使用{{IMAGE_B64}}变量引用 | |
| vars_workflowopt | HTTP_VARS | 工作流变量包 | |
| vars_browseropt | HTTP_VARS | 浏览器变量包 |
Outputs (4)
| Name | Type | Description |
|---|---|---|
| 响应文本 | STRING | — |
| 响应图像 | IMAGE | — |
| 状态码 | INT | — |
| 响应JSON | JSON | — |