From stan.rosenberg at acm.org Sun Sep 9 20:00:37 2018 From: stan.rosenberg at acm.org (Stan Rosenberg) Date: Sun, 9 Sep 2018 20:00:37 -0400 Subject: [undertow-dev] how to implement request processing timeout In-Reply-To: References:

Message-ID: We ended up implementing hard timeout using CAS; no noticeable drop in throughput or p99 latency. I thought I'd share in case others on the list may need it. Here is the code snippet (using Kotlin). override fun handleRequest(exchange: HttpServerExchange) { val timeoutWhenTrue = AtomicBoolean(true) exchange.getIoThread().executeAfter({ if (timeoutWhenTrue.compareAndSet(true, false)) { // we're first, so end the exchange exchange.statusCode = StatusCodes.REQUEST_TIME_OUT exchange.endExchange() } }, requestTimeoutMillis, TimeUnit.MILLISECONDS) exchange.dispatch(SameThreadExecutor.INSTANCE, Runnable { launch { // // request servicing logic // if (timeoutWhenTrue.compareAndSet(true, false)) { response.headers.forEach { exchange.responseHeaders.add(it.key, it.value } exchange.statusCode = response.statusCode response.response?.let { exchange.responseSender.send(response.response) } ?: exchange.endExchange() } }}) } On Sun, Jul 22, 2018 at 2:59 AM Stan Rosenberg wrote: > On Sun, Jul 15, 2018 at 7:45 PM, Stuart Douglas > wrote: > >> >>> Are you using the Servlet API or the HttpServerExchange API? The best >>>> way to approach this is a bit different depending on what you are doing. >>>> >>> >>> HttpServerExchange API >>> ?. Thanks!? >>> >> >> This is a bit harder to do in the general case. With Servlet you could >> just create a thread safe wrapper, where the wrapper basically disconnects >> from the underlying request on timeout. The Undertow native API is not >> designed around wrapping though, so it needs cooperation from the >> application to manage this. >> >> If you know the application is only going to be writing data (and not >> setting headers) then you should be able to make this work via a >> ConduitFactory implementation that handles the locking, although if this is >> not the case then you are going to need some kind of external lock. >> >> > ?Could you please elaborate on the approach using ?ConduitFactory. Do > you mean using 'exchange.addResponseWrapper' to intercept writes? That > would require locking since write can be invoked from a different thread > concurrently with timeout thread. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20180909/a3ee53e2/attachment.html From bdw429s at gmail.com Thu Sep 13 23:02:17 2018 From: bdw429s at gmail.com (Brad Wood) Date: Thu, 13 Sep 2018 22:02:17 -0500 Subject: [undertow-dev] Access control examples In-Reply-To: References:

Message-ID: Hi Stuart, did you see my note about my note about the unmerged pulls, the status(xxx) call and the question about basic auth being part of the predicate language? Thanks! ~Brad *Developer Advocate* *Ortus Solutions, Corp * E-mail: brad at coldbox.org ColdBox Platform: http://www.coldbox.org Blog: http://www.codersrevolution.com On Tue, Aug 21, 2018 at 11:51 AM Brad Wood wrote: > Hi Stuart, did you see my notes about the unmerged pulls, the status(xxx) > call and the question about basic auth being part of the predicate language? > > Thanks! > > ~Brad > > *Developer Advocate* > *Ortus Solutions, Corp * > > E-mail: brad at coldbox.org > ColdBox Platform: http://www.coldbox.org > Blog: http://www.codersrevolution.com > > > > On Thu, Aug 16, 2018 at 1:30 PM Brad Wood wrote: > >> Is the basic auth handler part of the predicate language? I didn't see >> it in the docs so I wanted to see if there was a way to have a textual >> representation of that. >> >> Thanks! >> >> ~Brad >> >> *Developer Advocate* >> *Ortus Solutions, Corp * >> >> E-mail: brad at coldbox.org >> ColdBox Platform: http://www.coldbox.org >> Blog: http://www.codersrevolution.com >> >> >> >> On Thu, Aug 16, 2018 at 1:06 PM Brad Wood wrote: >> >>> Thanks for the additional information Stuart. After a bit of Googling, >>> the most comprehensive version of the documentation for the predicate >>> language appears to be here: >>> >>> >>> https://github.com/undertow-io/undertow-docs/blob/master/src/main/asciidoc/predicates-attributes-handlers.asciidoc >>> >>> I'll note that Google really tends to favor the older, but less complete >>> versions of that page such as this one: >>> >>> >>> http://undertow.io/undertow-docs/undertow-docs-1.2.0/predicates-attributes-handlers.html >>> >>> You may want to look into some SEO tricks to get Google to index the >>> most recent version so it's easier to find. That said, for the life of me, >>> I can't find any docs at all that talk about the *status(404)* bit you >>> showed. Where is that covered? >>> >>> Did you perhaps mean this: *response-code(302)* >>> >>> Also, on the note of your docs, you have a handful of old pull requests >>> for typos and such over here: >>> https://github.com/undertow-io/undertow-docs/pulls >>> I added one to the list. Please review and merge those :) >>> >>> Thanks! >>> >>> ~Brad >>> >>> *Developer Advocate* >>> *Ortus Solutions, Corp * >>> >>> E-mail: brad at coldbox.org >>> ColdBox Platform: http://www.coldbox.org >>> Blog: http://www.codersrevolution.com >>> >>> >>> >>> On Wed, Aug 15, 2018 at 7:05 PM Stuart Douglas >>> wrote: >>> >>>> >>>> >>>> On Sat, Aug 11, 2018 at 1:25 AM Brad Wood wrote: >>>> >>>>> It depenends a bit on what you want to do. >>>>> >>>>> >>>>> Thanks for the reply Stuart. Honestly, I'm just brainstorming a >>>>> little here to see what's possible but I just couldn't find any docs or >>>>> examples to help solidify what was out in there. My primary use for this >>>>> as I explained just now in a separate reply is to be able to add some >>>>> security rules to CommandBox servers to do things such as: >>>>> >>>>> - Block access to CF admins in the root (such as paths starting >>>>> with */CFIDE*) >>>>> - Block access to special files in any directory such as *box.json*, >>>>> *server.json*, or *.cfconfig.json* >>>>> - Block access to hidden files in any directory (starting with a >>>>> period ) >>>>> - Block access to custom folders defined by the user such as >>>>> */tests/* or */workbench* >>>>> >>>>> I'm thinking a bit how the IIS "hidden segments" feature works. In >>>>> addition to using this behind the scenes in CommandBox, I'd like to expose >>>>> it to my users in the *server.json >>>>> * so >>>>> they can configure basic access control. I generally don't expose 100% of >>>>> what Undertow does since CommandBox aims to be a drop-in dead-easy way to >>>>> just fire up a server, but I'm interested in the IP matching since that >>>>> could be a common use case. i.e., "Block access to the administrator >>>>> unless the IP is in this range or localhost" >>>>> >>>>> So basically, yes, I'm interested in all of those things and I don't >>>>> have a super specific solution in mind, but I'm rather just looking for >>>>> some better examples to help me understand what's there and what I can best >>>>> expose in CommandBox. >>>>> >>>>> Basically you just use a predicate to decide what you want to >>>>>> restrict, and then map it to a handler that either rejects the request >>>>>> outright or performs an access control check. >>>>> >>>>> >>>>> This makes sense and I think the predicate part was what I was >>>>> missing, but are there examples of this anywhere? It helps me way more to >>>>> see some code. >>>>> >>>>> >>>> Most of the examples of this are in the test suite, e.g. >>>> PredicatedHandlersTestCase. There is also a text based representation you >>>> can use to configure this. e.g. to reject all box.json files: >>>> path-suffix(/box.json) -> status(404). >>>> >>>> Stuart >>>> >>>> >>>>> Thanks! >>>>> >>>>> ~Brad >>>>> >>>>> *Developer Advocate* >>>>> *Ortus Solutions, Corp * >>>>> >>>>> E-mail: brad at coldbox.org >>>>> ColdBox Platform: http://www.coldbox.org >>>>> Blog: http://www.codersrevolution.com >>>>> >>>>> >>>>> >>>>> On Fri, Aug 10, 2018 at 1:47 AM Stuart Douglas >>>>> wrote: >>>>> >>>>>> It depenends a bit on what you want to do. >>>>>> >>>>>> If you just want to block /CFIDE you can just use a PredicateHandler, >>>>>> with a PathPrefixPredicate, and if it matches use ResponseCodeHandler to >>>>>> return the desired response code. You could combine it >>>>>> with io.undertow.server.handlers.AccessControlListHandler >>>>>> or io.undertow.server.handlers.IPAddressAccessControlHandler if you want to >>>>>> limit the IP range. >>>>>> >>>>>> Basically you just use a predicate to decide what you want to >>>>>> restrict, and then map it to a handler that either rejects the request >>>>>> outright or performs an access control check. >>>>>> >>>>>> Stuart >>>>>> >>>>>> >>>>>> On Fri, Aug 10, 2018 at 3:59 PM Brad Wood wrote: >>>>>> >>>>>>> Anyone? >>>>>>> >>>>>>> Thanks! >>>>>>> >>>>>>> ~Brad >>>>>>> >>>>>>> *Developer Advocate* >>>>>>> *Ortus Solutions, Corp * >>>>>>> >>>>>>> E-mail: brad at coldbox.org >>>>>>> ColdBox Platform: http://www.coldbox.org >>>>>>> Blog: http://www.codersrevolution.com >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Sat, Aug 4, 2018 at 4:48 PM Brad Wood wrote: >>>>>>> >>>>>>>> Hi, I'm looking for some examples of locking down access to certain >>>>>>>> directories, similar to how IIS has "hidden segments". For instance, I'd >>>>>>>> like all URLs starting with /CFIDE to be blocked, or perhaps only access to >>>>>>>> a certain range of IPs >>>>>>>> >>>>>>>> I swear I had looked at some examples of this about a year ago, but >>>>>>>> after quite a lot of Googling today I was coming up empty handed. I found >>>>>>>> some basic information on the access control handlers, but couldn't find a >>>>>>>> single example of using them. >>>>>>>> >>>>>>>> Thanks! >>>>>>>> >>>>>>>> ~Brad >>>>>>>> >>>>>>>> *Developer Advocate* >>>>>>>> *Ortus Solutions, Corp * >>>>>>>> >>>>>>>> E-mail: brad at coldbox.org >>>>>>>> ColdBox Platform: http://www.coldbox.org >>>>>>>> Blog: http://www.codersrevolution.com >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>> undertow-dev mailing list >>>>>>> undertow-dev at lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/undertow-dev >>>>>> >>>>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20180913/aca6fd90/attachment-0001.html From bdw429s at gmail.com Thu Sep 13 23:39:42 2018 From: bdw429s at gmail.com (Brad Wood) Date: Thu, 13 Sep 2018 22:39:42 -0500 Subject: [undertow-dev] Real path default resolution Message-ID: I'm using Undertow for the deployment of Adobe ColdFusion and Lucee Server sites, which for historical reasons and convenience, keeps two separate folders for the WAR/web-inf and the actual web root where content is served from. In your typical J2EE setup, the real path "/" is the parent of "/WEB-INF" but that is not the case for me and we use a custom resource manager with great success to handle the correct resolution of paths in the server. We have one issue however in the event of path resolution for non existent files such as "/WEB-INF/cfform/logs/flex.log" which doesn't exist yet the first time a server comes up. Since it doesn't exist, my custom resource manager (who knows where the real WEB-INF lives) returns null as it should which leaves it up to this line of code: https://github.com/undertow-io/undertow/blob/ff4c9cf37872cb96070ba6a2fcbbaa6df291e390/servlet/src/main/java/io/undertow/servlet/spec/ServletContextImpl.java#L389 to "guess" where the file would exist if it were to be created. Since it roots it in the real path of "/", it guessing incorrectly in my case and the result is I have folders and files created in the wrong directory. This is rather tricky since my custom resource manager would tell the servlet context exactly where "/WEB-INF" is if it were to ask that question, but since it asks for "/", a different answer is given. Interestingly enough, had the example provided in the final comment of this ticket been followed, it would work for me since it progressively attempts to resolve the path while peeling back directories one at a time until it finds one that exists. https://issues.jboss.org/browse/UNDERTOW-373?focusedCommentId=13036336&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-13036336 There's no comment on the ticket as to why that solution wasn't used, but I would presume to avoid additional disk hits. I'm looking for ways that I can still control how /WEB-INF is resolved with my custom resource manager, even for non-existent paths. Save the progressive searching I mentioned in the previous paragraph, the only other solution I can think of is for the servlet contexts' getRealPath() to detect when a non existent path begins with /WEB-INF and asking the resource manager to resolve /WEB-INF in that case instead of / so it can get a more specific answer. Thoughts? Thanks! ~Brad *Developer Advocate* *Ortus Solutions, Corp * E-mail: brad at coldbox.org ColdBox Platform: http://www.coldbox.org Blog: http://www.codersrevolution.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20180913/676a7970/attachment.html From sdouglas at redhat.com Fri Sep 14 01:48:28 2018 From: sdouglas at redhat.com (Stuart Douglas) Date: Fri, 14 Sep 2018 15:48:28 +1000 Subject: [undertow-dev] Real path default resolution In-Reply-To: References: Message-ID: On Fri, Sep 14, 2018 at 3:38 PM Brad Wood wrote: > I'm using Undertow for the deployment of Adobe ColdFusion and Lucee Server > sites, which for historical reasons and convenience, keeps two separate > folders for the WAR/web-inf and the actual web root where content is served > from. > > In your typical J2EE setup, the real path "/" is the parent of "/WEB-INF" > but that is not the case for me and we use a custom resource manager with > great success to handle the correct resolution of paths in the server. > > We have one issue however in the event of path resolution for non existent > files such as "/WEB-INF/cfform/logs/flex.log" which doesn't exist yet the > first time a server comes up. Since it doesn't exist, my custom resource > manager (who knows where the real WEB-INF lives) returns null as it should > which leaves it up to this line of code: > > https://github.com/undertow-io/undertow/blob/ff4c9cf37872cb96070ba6a2fcbbaa6df291e390/servlet/src/main/java/io/undertow/servlet/spec/ServletContextImpl.java#L389 > to "guess" where the file would exist if it were to be created. Since it > roots it in the real path of "/", it guessing incorrectly in my case and > the result is I have folders and files created in the wrong directory. > > This is rather tricky since my custom resource manager would tell the > servlet context exactly where "/WEB-INF" is if it were to ask that > question, but since it asks for "/", a different answer is given. > Interestingly enough, had the example provided in the final comment of this > ticket been followed, it would work for me since it progressively attempts > to resolve the path while peeling back directories one at a time until it > finds one that exists. > > https://issues.jboss.org/browse/UNDERTOW-373?focusedCommentId=13036336&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-13036336 > > There's no comment on the ticket as to why that solution wasn't used, but > I would presume to avoid additional disk hits. I'm looking for ways that I > can still control how /WEB-INF is resolved with my custom resource manager, > even for non-existent paths. Save the progressive searching I mentioned in > the previous paragraph, the only other solution I can think of is for the > servlet contexts' getRealPath() to detect when a non existent path begins > with /WEB-INF and asking the resource manager to resolve /WEB-INF in that > case instead of / so it can get a more specific answer. > > Thoughts? > I am ok with the solution in UNDERTOW-373, the main reason why it was not followed was because it just did not seem necessary, as with the default resource managers the result is basically the same, but if there is a use case for it I am happy to adopt this approach. Stuart > > Thanks! > > ~Brad > > *Developer Advocate* > *Ortus Solutions, Corp * > > E-mail: brad at coldbox.org > ColdBox Platform: http://www.coldbox.org > Blog: http://www.codersrevolution.com > > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20180914/49e433da/attachment.html From bdw429s at gmail.com Fri Sep 14 14:57:14 2018 From: bdw429s at gmail.com (Brad Wood) Date: Fri, 14 Sep 2018 13:57:14 -0500 Subject: [undertow-dev] Real path default resolution In-Reply-To: References: Message-ID: Thanks for the reply Stuart, I'll enter a ticket for it t be looked at. I may be an edge case, but i could certainly benefit from the slightly different approach that allows my custom resource manager to do its thing.. Thanks! ~Brad *Developer Advocate* *Ortus Solutions, Corp * E-mail: brad at coldbox.org ColdBox Platform: http://www.coldbox.org Blog: http://www.codersrevolution.com On Fri, Sep 14, 2018 at 12:48 AM Stuart Douglas wrote: > > > On Fri, Sep 14, 2018 at 3:38 PM Brad Wood wrote: > >> I'm using Undertow for the deployment of Adobe ColdFusion and Lucee >> Server sites, which for historical reasons and convenience, keeps two >> separate folders for the WAR/web-inf and the actual web root where content >> is served from. >> >> In your typical J2EE setup, the real path "/" is the parent of "/WEB-INF" >> but that is not the case for me and we use a custom resource manager with >> great success to handle the correct resolution of paths in the server. >> >> We have one issue however in the event of path resolution for non >> existent files such as "/WEB-INF/cfform/logs/flex.log" which doesn't exist >> yet the first time a server comes up. Since it doesn't exist, my custom >> resource manager (who knows where the real WEB-INF lives) returns null as >> it should which leaves it up to this line of code: >> >> https://github.com/undertow-io/undertow/blob/ff4c9cf37872cb96070ba6a2fcbbaa6df291e390/servlet/src/main/java/io/undertow/servlet/spec/ServletContextImpl.java#L389 >> to "guess" where the file would exist if it were to be created. Since it >> roots it in the real path of "/", it guessing incorrectly in my case and >> the result is I have folders and files created in the wrong directory. >> >> This is rather tricky since my custom resource manager would tell the >> servlet context exactly where "/WEB-INF" is if it were to ask that >> question, but since it asks for "/", a different answer is given. >> Interestingly enough, had the example provided in the final comment of this >> ticket been followed, it would work for me since it progressively attempts >> to resolve the path while peeling back directories one at a time until it >> finds one that exists. >> >> https://issues.jboss.org/browse/UNDERTOW-373?focusedCommentId=13036336&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-13036336 >> >> There's no comment on the ticket as to why that solution wasn't used, but >> I would presume to avoid additional disk hits. I'm looking for ways that I >> can still control how /WEB-INF is resolved with my custom resource manager, >> even for non-existent paths. Save the progressive searching I mentioned in >> the previous paragraph, the only other solution I can think of is for the >> servlet contexts' getRealPath() to detect when a non existent path begins >> with /WEB-INF and asking the resource manager to resolve /WEB-INF in that >> case instead of / so it can get a more specific answer. >> >> Thoughts? >> > > I am ok with the solution in UNDERTOW-373, the main reason why it was not > followed was because it just did not seem necessary, as with the default > resource managers the result is basically the same, but if there is a use > case for it I am happy to adopt this approach. > > Stuart > > >> >> Thanks! >> >> ~Brad >> >> *Developer Advocate* >> *Ortus Solutions, Corp * >> >> E-mail: brad at coldbox.org >> ColdBox Platform: http://www.coldbox.org >> Blog: http://www.codersrevolution.com >> >> _______________________________________________ >> undertow-dev mailing list >> undertow-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/undertow-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20180914/94e1b76d/attachment-0001.html From bdw429s at gmail.com Fri Sep 14 15:13:16 2018 From: bdw429s at gmail.com (Brad Wood) Date: Fri, 14 Sep 2018 14:13:16 -0500 Subject: [undertow-dev] Real path default resolution In-Reply-To: References:

Message-ID: Here's the ticket for consideration: https://issues.jboss.org/browse/UNDERTOW-1413 If you're busy right now and approve the suggestion, I can take a stab at a pull request when I have some time. Thanks! ~Brad *Developer Advocate* *Ortus Solutions, Corp * E-mail: brad at coldbox.org ColdBox Platform: http://www.coldbox.org Blog: http://www.codersrevolution.com On Fri, Sep 14, 2018 at 1:57 PM Brad Wood wrote: > Thanks for the reply Stuart, I'll enter a ticket for it t be looked at. I > may be an edge case, but i could certainly benefit from the slightly > different approach that allows my custom resource manager to do its thing.. > > Thanks! > > ~Brad > > *Developer Advocate* > *Ortus Solutions, Corp * > > E-mail: brad at coldbox.org > ColdBox Platform: http://www.coldbox.org > Blog: http://www.codersrevolution.com > > > > On Fri, Sep 14, 2018 at 12:48 AM Stuart Douglas > wrote: > >> >> >> On Fri, Sep 14, 2018 at 3:38 PM Brad Wood wrote: >> >>> I'm using Undertow for the deployment of Adobe ColdFusion and Lucee >>> Server sites, which for historical reasons and convenience, keeps two >>> separate folders for the WAR/web-inf and the actual web root where content >>> is served from. >>> >>> In your typical J2EE setup, the real path "/" is the parent of >>> "/WEB-INF" but that is not the case for me and we use a custom resource >>> manager with great success to handle the correct resolution of paths in the >>> server. >>> >>> We have one issue however in the event of path resolution for non >>> existent files such as "/WEB-INF/cfform/logs/flex.log" which doesn't exist >>> yet the first time a server comes up. Since it doesn't exist, my custom >>> resource manager (who knows where the real WEB-INF lives) returns null as >>> it should which leaves it up to this line of code: >>> >>> https://github.com/undertow-io/undertow/blob/ff4c9cf37872cb96070ba6a2fcbbaa6df291e390/servlet/src/main/java/io/undertow/servlet/spec/ServletContextImpl.java#L389 >>> to "guess" where the file would exist if it were to be created. Since >>> it roots it in the real path of "/", it guessing incorrectly in my case and >>> the result is I have folders and files created in the wrong directory. >>> >>> This is rather tricky since my custom resource manager would tell the >>> servlet context exactly where "/WEB-INF" is if it were to ask that >>> question, but since it asks for "/", a different answer is given. >>> Interestingly enough, had the example provided in the final comment of this >>> ticket been followed, it would work for me since it progressively attempts >>> to resolve the path while peeling back directories one at a time until it >>> finds one that exists. >>> >>> https://issues.jboss.org/browse/UNDERTOW-373?focusedCommentId=13036336&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-13036336 >>> >>> There's no comment on the ticket as to why that solution wasn't used, >>> but I would presume to avoid additional disk hits. I'm looking for ways >>> that I can still control how /WEB-INF is resolved with my custom resource >>> manager, even for non-existent paths. Save the progressive searching I >>> mentioned in the previous paragraph, the only other solution I can think of >>> is for the servlet contexts' getRealPath() to detect when a non existent >>> path begins with /WEB-INF and asking the resource manager to resolve >>> /WEB-INF in that case instead of / so it can get a more specific answer. >>> >>> Thoughts? >>> >> >> I am ok with the solution in UNDERTOW-373, the main reason why it was not >> followed was because it just did not seem necessary, as with the default >> resource managers the result is basically the same, but if there is a use >> case for it I am happy to adopt this approach. >> >> Stuart >> >> >>> >>> Thanks! >>> >>> ~Brad >>> >>> *Developer Advocate* >>> *Ortus Solutions, Corp * >>> >>> E-mail: brad at coldbox.org >>> ColdBox Platform: http://www.coldbox.org >>> Blog: http://www.codersrevolution.com >>> >>> _______________________________________________ >>> undertow-dev mailing list >>> undertow-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/undertow-dev >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20180914/e42b98b8/attachment.html