HTTP Form Data
The glue that turns fields and files into a multipart body
- item1
- item2
- item3
- item4
- item5
- item6
- item7
- item8
- item9
- item10
- form_data
Plain JSON bodies are easy - you type a string. Multipart form data is where it gets fiddly, because a single form can carry a text field in one slot and a file in another, and those need completely different handling on the wire. HTTP Form Data is the bucket you pour those mixed pieces into. It takes up to ten form items and packages them into one form_data object that HTTPPost can send with content_type = form-data.
How it works
The node itself has no required inputs - it's just a container. It has ten optional sockets, boringly named item1 through item10, each accepting an HTTP_FORM_ITEM. You feed those from the pack's item nodes:
- HTTP Form Data Item / HTTP Form Text Item - text fields.
- HTTP Form File Item - a file from disk.
- HTTP Form Image Item - a ComfyUI
IMAGEtensor, encoded in memory.
Internally it splits the items into two buckets: text values go into a data dict, files and images go into a files dict (as (filename, bytes, content_type) tuples). That split is exactly what a multipart POST needs, and it's why you can mix a caption with an image in one submission.
One output: form_data (HTTP_FORM_DATA). That plugs into HTTPPost's form_data input, with content_type set to form-data.
What matters in practice
If an endpoint expects even one file field, this is the node you need - a JSON body can't carry a file, and a plain form body won't either. The classic combo for uploading a generated image:
[KSampler → VAE Decode] → [HTTP Form Image Item] ─┐
├→ [HTTP Form Data] → [HTTP Post: form-data]
[Prompt text] → [HTTP Form Text Item] ────────────┘
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 model downloads. The pillow requirement for image encoding is already present in any ComfyUI install.
Where people get burned
The ten-item cap is real - if a form needs more fields, chain a couple of HTTPFormData nodes through HTTP Form Data Concat. And an item whose file path doesn't exist doesn't fail the run: the node stuffs a "File not found: ..." string into the data dict, and the API gets a text field where it expected a file. Always double-check paths before you wire up the form, because the error is easy to miss.
Inputs (10)
| Name | Type | Default | Description |
|---|---|---|---|
| item1opt | HTTP_FORM_ITEM | — | |
| item2opt | HTTP_FORM_ITEM | — | |
| item3opt | HTTP_FORM_ITEM | — | |
| item4opt | HTTP_FORM_ITEM | — | |
| item5opt | HTTP_FORM_ITEM | — | |
| item6opt | HTTP_FORM_ITEM | — | |
| item7opt | HTTP_FORM_ITEM | — | |
| item8opt | HTTP_FORM_ITEM | — | |
| item9opt | HTTP_FORM_ITEM | — | |
| item10opt | HTTP_FORM_ITEM | — |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| form_data | HTTP_FORM_DATA | — |