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 ~>| |~> SslTlsOutbound | bidi | HttpResponse <~| |<~ SslTlsInbound +------+
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 ~>| |~> SslTlsOutbound | bidi | HttpRequest <~| |<~ SslTlsInbound +------+
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.
If an HttpsContext is given it will be used for setting up TLS encryption on the binding. Otherwise the binding will be unencrypted.
If no
is explicitly given (or the port value is negative) the protocol's default port will be used,
which is 80 for HTTP and 443 for HTTPS.
port
Convenience method which starts a new HTTP server at the given endpoint and uses the given
Flow for processing all incoming connections.handler
Convenience method which starts a new HTTP server at the given endpoint and uses the given
Flow for processing all incoming connections.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
Flow for processing all incoming connections.handler
Convenience method which starts a new HTTP server at the given endpoint and uses the given
Flow for processing all incoming connections.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
Flow for processing all incoming connections.handler
Convenience method which starts a new HTTP server at the given endpoint and uses the given
Flow for processing all incoming connections.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
from the application which is emitted together with the corresponding response.
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
from the application which is emitted together with the corresponding response.
T
Same as cachedHostConnectionPool but for encrypted (HTTPS) connections.
Same as cachedHostConnectionPool but for encrypted (HTTPS) connections.
If an explicit HttpsContext is given then it rather than the configured default HttpsContext will be used for encryption on the connections.
Constructs a ClientLayer stage using the given ClientConnectionSettings.
Constructs a ClientLayer stage using the configured default ClientConnectionSettings.
Gets the current default client-side HttpsContext.
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
from the application which is emitted together with the corresponding response.
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
from the application which is emitted together with the corresponding response.
T
Same as newHostConnectionPool but for encrypted (HTTPS) connections.
Same as newHostConnectionPool but for encrypted (HTTPS) connections.
If an explicit HttpsContext is given then it rather than the configured default HttpsContext will be used for encryption on the connections.
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.
Same as outgoingConnection but for encrypted (HTTPS) connections.
Same as outgoingConnection but for encrypted (HTTPS) connections.
If an explicit HttpsContext is given then it rather than the configured default HttpsContext will be used for encryption on the 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.
Sets the default client-side HttpsContext.
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.
If an explicit HttpsContext is given then it rather than the configured default HttpsContext will be used for setting up the HTTPS connection pool, if required.
Note that the request must have an absolute URI, 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 an absolute URI.
If an explicit HttpsContext is given then it rather than the configured default HttpsContext will be used for setting up HTTPS connection pools, if required.
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
from the application which is emitted together with the corresponding response.
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