diff --git a/src/main/asciidoc/built-in-handlers.asciidoc b/src/main/asciidoc/built-in-handlers.asciidoc index a53dbae..0edeceb 100644 --- a/src/main/asciidoc/built-in-handlers.asciidoc +++ b/src/main/asciidoc/built-in-handlers.asciidoc @@ -2,7 +2,7 @@ === Built in Handlers -Undertow contains a number of build in handlers that provide common functionality. Most of these handlers can be created +Undertow contains a number of built in handlers that provide common functionality. Most of these handlers can be created using static methods on the `io.undertow.Handlers` utility class. The most common of these handlers are detailed below. @@ -41,7 +41,7 @@ There are multiple handlers that deal with requests that expect a HTTP 100 Conti Handler will automatically send a continue response for requests that require it the first time a handler attempts to read the request body. The HTTP Continue Accepting handler will immediately either send a 100 or a 417 response depending on the value of a -predicate. If no predicate is supplied it all immediately accept all requests. If a 417 response code is send the +predicate. If no predicate is supplied it will immediately accept all requests. If a 417 response code is sent the next handler is not invoked and the request will be changed to be non persistent. Websocket:: diff --git a/src/main/asciidoc/undertow-handler-guide.asciidoc b/src/main/asciidoc/undertow-handler-guide.asciidoc index e9c6c24..c41cc3d 100644 --- a/src/main/asciidoc/undertow-handler-guide.asciidoc +++ b/src/main/asciidoc/undertow-handler-guide.asciidoc @@ -100,14 +100,14 @@ public void handleRequest(final HttpServerExchange exchange) throws Exception { } ---- -Because exchange is not actually dispatched until the call stack returns you can be sure that more that one thread is +Because exchange is not actually dispatched until the call stack returns you can be sure that more than one thread is never active in an exchange at once. The exchange is not thread safe, however it can be passed between multiple threads as long as both threads do not attempt to modify it at once, and there is a happens before action (such as a thread pool dispatch) in between the first and second thread access. ==== Ending the exchange -As mentioned above, and exchange is considered done once both the request and response channels have been closed and flushed. +As mentioned above, an exchange is considered done once both the request and response channels have been closed and flushed. There are two ways to end an exchange, either by fully reading the request channel, and calling `shutdownWrites()` on the response channel and then flushing it, or by calling `HttpServerExchange.endExchange()`. When `endExchange()` is called