The type of the client-side HTTP layer as a stand-alone BidiStage that can be put atop the TCP layer to form an HTTP client.
The type of the client-side HTTP layer as a stand-alone BidiStage that can be put atop the TCP layer to form an HTTP client.
+------+
HttpRequest ~>| |~> ByteString
| bidi |
HttpResponse <~| |<~ ByteString
+------+The type of the server-side HTTP layer as a stand-alone BidiStage that can be put atop the TCP layer to form an HTTP server.
The type of the server-side HTTP layer as a stand-alone BidiStage that can be put atop the TCP layer to form an HTTP server.
+------+
HttpResponse ~>| |~> ByteString
| bidi |
HttpRequest <~| |<~ ByteString
+------+Creates a Source of IncomingConnection instances which represents a prospective HTTP server binding
on the given endpoint.
Creates a Source of IncomingConnection instances which represents a prospective HTTP server binding
on the given endpoint.
If the given port is 0 the resulting source can be materialized several times. Each materialization will
then be assigned a new local port by the operating system, which can then be retrieved by the materialized
ServerBinding.
If the given port is non-zero subsequent materialization attempts of the produced source will immediately
fail, unless the first materialization has already been unbound. Unbinding can be triggered via the materialized
ServerBinding.
Convenience method which starts a new HTTP server at the given endpoint and uses the given handler
Convenience method which starts a new HTTP server at the given endpoint and uses the given handler
Note that there is no backpressure being applied to the connections Source, i.e. all
connections are being accepted at maximum rate, which, depending on the applications, might
present a DoS risk!
Convenience method which starts a new HTTP server at the given endpoint and uses the given handler
Convenience method which starts a new HTTP server at the given endpoint and uses the given handler
Note that there is no backpressure being applied to the connections Source, i.e. all
connections are being accepted at maximum rate, which, depending on the applications, might
present a DoS risk!
Convenience method which starts a new HTTP server at the given endpoint and uses the given handler
Convenience method which starts a new HTTP server at the given endpoint and uses the given handler
Note that there is no backpressure being applied to the connections Source, i.e. all
connections are being accepted at maximum rate, which, depending on the applications, might
present a DoS risk!
Returns a Flow which dispatches incoming HTTP requests to the per-ActorSystem pool of outgoing HTTP connections to the given target host endpoint.
Returns a Flow which dispatches incoming HTTP requests to the per-ActorSystem pool of outgoing HTTP connections to the given target host endpoint. For every ActorSystem, target host and pool configuration a separate connection pool is maintained. The HTTP layer transparently manages idle shutdown and restarting of connections pools as configured. The returned Flow instances therefore remain valid throughout the lifetime of the application.
The internal caching logic guarantees that there will never be more than a single pool running for the given target host endpoint and configuration (in this ActorSystem).
Since the underlying transport usually comprises more than a single connection the produced flow might generate
responses in an order that doesn't directly match the consumed requests.
For example, if two requests A and B enter the flow in that order the response for B might be produced before the
response for A.
In order to allow for easy response-to-request association the flow takes in a custom, opaque context
object of type T
Returns a Flow which dispatches incoming HTTP requests to the per-ActorSystem pool of outgoing HTTP connections to the given target host endpoint.
Returns a Flow which dispatches incoming HTTP requests to the per-ActorSystem pool of outgoing HTTP connections to the given target host endpoint. For every ActorSystem, target host and pool configuration a separate connection pool is maintained. The HTTP layer transparently manages idle shutdown and restarting of connections pools as configured. The returned Flow instances therefore remain valid throughout the lifetime of the application.
The internal caching logic guarantees that there will never be more than a single pool running for the given target host endpoint and configuration (in this ActorSystem).
Since the underlying transport usually comprises more than a single connection the produced flow might generate
responses in an order that doesn't directly match the consumed requests.
For example, if two requests A and B enter the flow in that order the response for B might be produced before the
response for A.
In order to allow for easy response-to-request association the flow takes in a custom, opaque context
object of type T
Constructs a ClientLayer stage using the given ClientConnectionSettings.
Constructs a ClientLayer stage using the configured default ClientConnectionSettings.
Starts a new connection pool to the given host and configuration and returns a Flow which dispatches the requests from all its materializations across this pool.
Starts a new connection pool to the given host and configuration and returns a Flow which dispatches the requests from all its materializations across this pool. While the started host connection pool internally shuts itself down automatically after the configured idle timeout it will spin itself up again if more requests arrive from an existing or a new client flow materialization. The returned flow therefore remains usable for the full lifetime of the application.
Since the underlying transport usually comprises more than a single connection the produced flow might generate
responses in an order that doesn't directly match the consumed requests.
For example, if two requests A and B enter the flow in that order the response for B might be produced before the
response for A.
In order to allow for easy response-to-request association the flow takes in a custom, opaque context
object of type T
Starts a new connection pool to the given host and configuration and returns a Flow which dispatches the requests from all its materializations across this pool.
Starts a new connection pool to the given host and configuration and returns a Flow which dispatches the requests from all its materializations across this pool. While the started host connection pool internally shuts itself down automatically after the configured idle timeout it will spin itself up again if more requests arrive from an existing or a new client flow materialization. The returned flow therefore remains usable for the full lifetime of the application.
Since the underlying transport usually comprises more than a single connection the produced flow might generate
responses in an order that doesn't directly match the consumed requests.
For example, if two requests A and B enter the flow in that order the response for B might be produced before the
response for A.
In order to allow for easy response-to-request association the flow takes in a custom, opaque context
object of type T
Creates a Flow representing a prospective HTTP client connection to the given endpoint.
Creates a Flow representing a prospective HTTP client connection to the given endpoint. Every materialization of the produced flow will attempt to establish a new outgoing connection.
Constructs a ServerLayer stage using the given ServerSettings.
Constructs a ServerLayer stage using the given ServerSettings. The returned BidiFlow isn't reusable and can only be materialized once.
Constructs a ServerLayer stage using the configured default ServerSettings.
Constructs a ServerLayer stage using the configured default ServerSettings. The returned BidiFlow can only be materialized once.
Triggers an orderly shutdown of all host connections pools currently maintained by the ActorSystem.
Triggers an orderly shutdown of all host connections pools currently maintained by the ActorSystem. The returned future is completed when all pools that were live at the time of this method call have completed their shutdown process.
If existing pool client flows are re-used or new ones materialized concurrently with or after this method call the respective connection pools will be restarted and not contribute to the returned future.
Fires a single HttpRequest across the (cached) host connection pool for the request's effective URI to produce a response future.
Fires a single HttpRequest across the (cached) host connection pool for the request's effective URI to produce a response future.
Note that the request must have either an absolute URI or a valid Host header, otherwise
the future will be completed with an error.
Creates a new "super connection pool flow", which routes incoming requests to a (cached) host connection pool depending on their respective effective URI.
Creates a new "super connection pool flow", which routes incoming requests to a (cached) host connection pool
depending on their respective effective URI. Note that incoming requests must have either an absolute URI or
a valid Host header.
Since the underlying transport usually comprises more than a single connection the produced flow might generate
responses in an order that doesn't directly match the consumed requests.
For example, if two requests A and B enter the flow in that order the response for B might be produced before the
response for A.
In order to allow for easy response-to-request association the flow takes in a custom, opaque context
object of type T
(httpExt: StringAdd).self
(httpExt: StringFormat).self
(httpExt: ArrowAssoc[HttpExt]).x
(Since version 2.10.0) Use leftOfArrow instead
(httpExt: Ensuring[HttpExt]).x
(Since version 2.10.0) Use resultOfEnsuring instead