4b89fcd643
* #20466 added checks to the TimeoutDirectivesExampleSpec * #20466 added missing Java directive wrapper, added Java test, added some comments to Scala spec * #20466 test minor fixes (typos, comments, unused code) * #20466 replaced placeholders with proper snippets in Java docs * #20466 added proper withRequestTimeout example to JavaTestServer * #20466 comment - clarifies the request-timeout = infinite case * #20466 post-review changes (#20812)
42 lines
No EOL
2.3 KiB
ReStructuredText
42 lines
No EOL
2.3 KiB
ReStructuredText
.. _-withRequestTimeout-java-:
|
||
|
||
withRequestTimeout
|
||
==================
|
||
|
||
Description
|
||
-----------
|
||
|
||
This directive enables "late" (during request processing) control over the :ref:`request-timeout-java` feature in Akka HTTP.
|
||
|
||
The timeout can be either loosened or made more tight using this directive, however one should be aware that it is
|
||
inherently racy (which may especially show with very tight timeouts) since a timeout may already have been triggered
|
||
when this directive executes.
|
||
|
||
In case of pipelined HTTP requests (multiple requests being accepted on the same connection before sending the first response)
|
||
a the request timeout failure of the ``n-th`` request *will shut down the connection* causing the already enqueued requests
|
||
to be dropped. This is by-design, as the request timeout feature serves as a "safety net" in case of programming errors
|
||
(e.g. a Future that never completes thus potentially blocking the entire connection forever) or malicious attacks on the server.
|
||
|
||
Optionally, a timeout handler may be provided in which is called when a time-out is triggered and must produce an
|
||
``HttpResponse`` that will be sent back to the client instead of the "too late" response (in case it'd ever arrive).
|
||
See also :ref:`-withRequestTimeoutResponse-java-` if only looking to customise the timeout response without changing the timeout itself.
|
||
|
||
.. warning::
|
||
Please note that setting the timeout from within a directive is inherently racy (as the "point in time from which
|
||
we're measuring the timeout" is already in the past (the moment we started handling the request), so if the existing
|
||
timeout already was triggered before your directive had the chance to change it, an timeout may still be logged.
|
||
|
||
It is recommended to use a larger statically configured timeout (think of it as a "safety net" against programming errors
|
||
or malicious attackers) and if needed tighten it using the directives – not the other way around.
|
||
|
||
For more information about various timeouts in Akka HTTP see :ref:`http-timeouts-java`.
|
||
|
||
Example
|
||
-------
|
||
.. includecode2:: ../../../../code/docs/http/javadsl/server/directives/TimeoutDirectivesExamplesTest.java
|
||
:snippet: withRequestTimeout-plain
|
||
|
||
With setting the handler at the same time:
|
||
|
||
.. includecode2:: ../../../../code/docs/http/javadsl/server/directives/TimeoutDirectivesExamplesTest.java
|
||
:snippet: withRequestTimeout-with-handler |