FluxFlow.Components.Http
3.0.0
See the version list below for details.
dotnet add package FluxFlow.Components.Http --version 3.0.0
NuGet\Install-Package FluxFlow.Components.Http -Version 3.0.0
<PackageReference Include="FluxFlow.Components.Http" Version="3.0.0" />
<PackageVersion Include="FluxFlow.Components.Http" Version="3.0.0" />
<PackageReference Include="FluxFlow.Components.Http" />
paket add FluxFlow.Components.Http --version 3.0.0
#r "nuget: FluxFlow.Components.Http, 3.0.0"
#:package FluxFlow.Components.Http@3.0.0
#addin nuget:?package=FluxFlow.Components.Http&version=3.0.0
#tool nuget:?package=FluxFlow.Components.Http&version=3.0.0
FluxFlow.Components.Http
A standalone HTTP node for FluxFlow — a "blockified" HttpClient.
What it is
HttpClientNode is a self-contained TPL Dataflow processor. You give it an
HttpClient, post HttpRequestInputs to its input, and it broadcasts
HttpResponseOutputs on its output (failures on the error port, notes on the
event port). It needs nothing else — no engine, registry, or runtime:
await using var node = new HttpClientNode(httpClient);
node.Output.LinkTo(logger.Input); // broadcast: link the output to as many
node.Output.LinkTo(mapper.Input); // downstream nodes as you like
await node.Input.SendAsync(new HttpRequestInput
{
Method = "GET",
Url = "https://api.example.com/things/42"
});
Ports
| Port | Block | Purpose |
|---|---|---|
Input |
BufferBlock<HttpRequestInput> |
bounded intake — SendAsync applies backpressure |
Output |
BroadcastBlock<HttpResponseOutput> |
the response, fanned out to every linked consumer |
Errors |
BroadcastBlock<FlowError> |
request failures (invalid URL, timeout, network, send, non-success) |
Events |
BroadcastBlock<FlowEvent> |
http.request.succeeded / http.request.failed notes |
Outputs are broadcast (latest-wins, no backpressure): a consumer that keeps up sees every message; one that falls badly behind may miss some. That is the deliberate trade for simplicity. If a graph genuinely must not drop, bridge that edge through its own bounded buffer.
Transport policy lives on the HttpClient
The node owns no transport policy. Base address, connection pooling, redirects,
default headers, TLS, proxy, and any allow-list / SSRF guard all belong on the
HttpClient you inject — exactly as you configure a regular .NET client
(typically via IHttpClientFactory and a DelegatingHandler). The node never
disposes the client; the host owns its lifetime. A relative Url resolves
against the client's BaseAddress.
Options
new HttpClientNodeOptions
{
BoundedCapacity = 128, // input buffer size
MaxResponseBodyBytes = 1_048_576, // bodies past this are read to the cap, BodyTruncated = true
TreatNonSuccessStatusAsError = false,
MaxDegreeOfParallelism = 1, // >1 to send concurrently (output order not guaranteed)
DefaultTimeoutMilliseconds = null // per-request timeout when the input omits one
};
Composition
Building a workflow — reading config, creating nodes, linking them — is a
separate concern from the node. This package is just the node; wire it from
whatever composition/host layer you use (appsettings.json → construct nodes →
LinkTo).
| Product | Versions Compatible and additional computed target framework versions. |
|---|---|
| .NET | net8.0 is compatible. net8.0-android was computed. net8.0-browser was computed. net8.0-ios was computed. net8.0-maccatalyst was computed. net8.0-macos was computed. net8.0-tvos was computed. net8.0-windows was computed. net9.0 was computed. net9.0-android was computed. net9.0-browser was computed. net9.0-ios was computed. net9.0-maccatalyst was computed. net9.0-macos was computed. net9.0-tvos was computed. net9.0-windows was computed. net10.0 is compatible. net10.0-android was computed. net10.0-browser was computed. net10.0-ios was computed. net10.0-maccatalyst was computed. net10.0-macos was computed. net10.0-tvos was computed. net10.0-windows was computed. |
-
net10.0
- FluxFlow.Nodes (>= 1.0.0)
-
net8.0
- FluxFlow.Nodes (>= 1.0.0)
NuGet packages (2)
Showing the top 2 NuGet packages that depend on FluxFlow.Components.Http:
| Package | Downloads |
|---|---|
|
FluxFlow.Components.Http.AspNetCore
ASP.NET Core HTTP trigger adapter for FluxFlow: maps an endpoint's HttpContext onto the request/reply bridge so an inbound request flows into a graph and the correlated response is written back. The only FluxFlow package that references ASP.NET Core. |
|
|
FluxFlow.Components.Http.Composition
Canonical HTTP FlowContent/result registration and Designer metadata over host-owned keyed HttpClient resources. |
GitHub repositories
This package is not used by any popular GitHub repositories.
| Version | Downloads | Last Updated |
|---|---|---|
| 7.0.0-rc.1 | 82 | 9/5/2026 |
| 6.0.0 | 231 | 8/3/2026 |
| 3.0.2 | 146 | 7/3/2026 |
| 3.0.1 | 207 | 7/2/2026 |
| 3.0.0 | 148 | 6/19/2026 |
| 2.0.0 | 137 | 6/18/2026 |
| 1.2.1 | 120 | 6/15/2026 |
| 1.2.0 | 419 | 6/12/2026 |
| 1.1.0 | 118 | 6/5/2026 |
| 1.0.0 | 117 | 6/4/2026 |
| 0.2.0-alpha.1 | 246 | 6/2/2026 |
| 0.1.1-alpha.1 | 91 | 6/2/2026 |
| 0.1.0-alpha.1 | 101 | 6/1/2026 |
Rebuilt as a single standalone http.client node over an injected HttpClient: request in, response broadcast out, failures on the error port. The connection-resource node, sender-factory layer, and in-node SSRF guard are removed — all transport policy lives on the injected HttpClient. The node depends only on FluxFlow.Nodes and runs without the engine.