FluxFlow.Components.Http
3.0.1
See the version list below for details.
dotnet add package FluxFlow.Components.Http --version 3.0.1
NuGet\Install-Package FluxFlow.Components.Http -Version 3.0.1
<PackageReference Include="FluxFlow.Components.Http" Version="3.0.1" />
<PackageVersion Include="FluxFlow.Components.Http" Version="3.0.1" />
<PackageReference Include="FluxFlow.Components.Http" />
paket add FluxFlow.Components.Http --version 3.0.1
#r "nuget: FluxFlow.Components.Http, 3.0.1"
#:package FluxFlow.Components.Http@3.0.1
#addin nuget:?package=FluxFlow.Components.Http&version=3.0.1
#tool nuget:?package=FluxFlow.Components.Http&version=3.0.1
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
};
BoundedCapacity, MaxResponseBodyBytes, and MaxDegreeOfParallelism must be
greater than zero. DefaultTimeoutMilliseconds, when set, must also be greater
than zero. Invalid options fail fast during node construction.
Composition
Building a workflow — reading config, creating nodes, linking them — is a separate concern from the node. This package is just the node.
Add FluxFlow.Components.Http.Composition when a host wants to instantiate
HttpClientNode from FluxFlow.Composition fluent/config definitions. That
optional package registers the http.client factory and resolves a keyed
HttpClient resource named client; the host still owns the client lifetime
and transport policy.
The optional composition package also exposes
HttpComponentDesignMetadataProvider for neutral Designer metadata over the
http.client composition node type. The standalone HTTP package remains free
of Designer, Composition, and Engine dependencies.
| 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.1.2)
-
net8.0
- FluxFlow.Nodes (>= 1.1.2)
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 |
Hardens HttpClientNode option validation so non-positive capacities, response body limits, concurrency, and default timeout values fail fast during node construction.