From paroczizs at gmail.com Mon Sep 5 10:32:42 2016 From: paroczizs at gmail.com (paroczizs .) Date: Mon, 5 Sep 2016 16:32:42 +0200 Subject: [undertow-dev] Accessing to the http response content Message-ID: Hi, I found the following post on the mailing list: http://lists.jboss.org/pipermail/undertow-dev/2014-September/000974.html We are facing exactly the same problem. Is it possible to share an example how we accessto the full response content through a custom handler class? Thank you forward, Zsolt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20160905/8db79fd1/attachment.html From oliver at analyticspot.com Tue Sep 6 21:41:29 2016 From: oliver at analyticspot.com (Oliver Dain) Date: Wed, 07 Sep 2016 01:41:29 +0000 Subject: [undertow-dev] Docs for templates Message-ID: Hey all, I haven't seen any documentation on the format of a template accepted by a PathTemplateHandler. I know the basics: "/foo", "/foo/{userId}", etc. but are wildcards allowed? Is there a way to specify a handler for anything with a certain prefix? If two handlers would match how is the tie broken, etc. Thanks, Oliver -- CTO, Analytic Spot 44 West Broadway #222 Eugene, OR 97401 analyticspot.com ? 425-296-6556 www.linkedin.com/in/oliverdain -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20160907/7ae557ab/attachment.html From greg.hellings at gmail.com Wed Sep 7 08:08:39 2016 From: greg.hellings at gmail.com (Greg Hellings) Date: Wed, 7 Sep 2016 08:08:39 -0400 Subject: [undertow-dev] Docs for templates In-Reply-To: References: Message-ID: Oliver, I found it very difficult to work with the PathTemplateHandler and its set of matching operations seemed very minimal to me. I also found no efficient way to mix-and-match between full Paths and PathTemplate entries. So I created my own handler class that gave the ability to match based on both HTTP Verb and various path components. https://github.com/greg-hellings/gully/blob/master/src/main/java/com/thehellings/gully/Router.java https://github.com/greg-hellings/gully/blob/master/src/main/java/com/thehellings/gully/PlainRouter.java I haven't used it extensively, but in my own local testing it seems to work exactly the way I wanted - it's still just an HttpHandler underneath, so it can be placed anywhere in a handler chain. And it operates on the result of getRelativePath, so you can nest them within each other, or place them within other components in a handler chain and the class should operate properly. The whole set of handler and its dependent classes should be available as a Maven artifact if you want to play with it. If this sort of functionality exists somewhere in core Undertow, I've been entirely unable to decipher it and locate its functioning. --Greg On Tue, Sep 6, 2016 at 9:41 PM, Oliver Dain wrote: > Hey all, > > I haven't seen any documentation on the format of a template accepted by a > PathTemplateHandler. I know the basics: "/foo", "/foo/{userId}", etc. but > are wildcards allowed? Is there a way to specify a handler for anything with > a certain prefix? If two handlers would match how is the tie broken, etc. > > Thanks, > Oliver > -- > CTO, Analytic Spot > 44 West Broadway #222 > Eugene, OR 97401 > analyticspot.com ? 425-296-6556 > www.linkedin.com/in/oliverdain > > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev From bill at dartalley.com Wed Sep 7 09:20:19 2016 From: bill at dartalley.com (Bill O'Neil) Date: Wed, 7 Sep 2016 09:20:19 -0400 Subject: [undertow-dev] Docs for templates In-Reply-To: References: Message-ID: I did something similar to Greg by delegating to a RoutingHandler which has a PathHandler fallback. https://gist.github.com/billoneil/08b1648a3b2a849e02c57e133bd6d45c This allows me to add prefix routes but still not flexible enough for all uses cases. The main drawback with this approach is the prefix handler doesn't route based on Verb but it has worked for all of my use cases so far. I would also like to know if there is a way the RoutingHandler can be extended to have wildcard functionality. On Wed, Sep 7, 2016 at 8:08 AM, Greg Hellings wrote: > Oliver, > > I found it very difficult to work with the PathTemplateHandler and its > set of matching operations seemed very minimal to me. I also found no > efficient way to mix-and-match between full Paths and PathTemplate > entries. So I created my own handler class that gave the ability to > match based on both HTTP Verb and various path components. > > https://github.com/greg-hellings/gully/blob/master/ > src/main/java/com/thehellings/gully/Router.java > https://github.com/greg-hellings/gully/blob/master/ > src/main/java/com/thehellings/gully/PlainRouter.java > > I haven't used it extensively, but in my own local testing it seems to > work exactly the way I wanted - it's still just an HttpHandler > underneath, so it can be placed anywhere in a handler chain. And it > operates on the result of getRelativePath, so you can nest them within > each other, or place them within other components in a handler chain > and the class should operate properly. > > The whole set of handler and its dependent classes should be available > as a Maven artifact if you want to play with it. If this sort of > functionality exists somewhere in core Undertow, I've been entirely > unable to decipher it and locate its functioning. > > --Greg > > On Tue, Sep 6, 2016 at 9:41 PM, Oliver Dain > wrote: > > Hey all, > > > > I haven't seen any documentation on the format of a template accepted by > a > > PathTemplateHandler. I know the basics: "/foo", "/foo/{userId}", etc. but > > are wildcards allowed? Is there a way to specify a handler for anything > with > > a certain prefix? If two handlers would match how is the tie broken, etc. > > > > Thanks, > > Oliver > > -- > > CTO, Analytic Spot > > 44 West Broadway #222 > > Eugene, OR 97401 > > analyticspot.com ? 425-296-6556 > > www.linkedin.com/in/oliverdain > > > > _______________________________________________ > > undertow-dev mailing list > > undertow-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/undertow-dev > > _______________________________________________ > 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/20160907/ce13aa22/attachment.html From oliver at analyticspot.com Wed Sep 7 14:35:08 2016 From: oliver at analyticspot.com (Oliver Dain) Date: Wed, 07 Sep 2016 18:35:08 +0000 Subject: [undertow-dev] Docs for templates In-Reply-To: References: Message-ID: Thanks Greg and Bill! On Wed, Sep 7, 2016 at 6:20 AM Bill O'Neil wrote: > I did something similar to Greg by delegating to a RoutingHandler which > has a PathHandler fallback. > > https://gist.github.com/billoneil/08b1648a3b2a849e02c57e133bd6d45c > > This allows me to add prefix routes but still not flexible enough for all > uses cases. The main drawback with this approach is the prefix handler > doesn't route based on Verb but it has worked for all of my use cases so > far. > > I would also like to know if there is a way the RoutingHandler can be > extended to have wildcard functionality. > > On Wed, Sep 7, 2016 at 8:08 AM, Greg Hellings > wrote: > >> Oliver, >> >> I found it very difficult to work with the PathTemplateHandler and its >> set of matching operations seemed very minimal to me. I also found no >> efficient way to mix-and-match between full Paths and PathTemplate >> entries. So I created my own handler class that gave the ability to >> match based on both HTTP Verb and various path components. >> >> >> https://github.com/greg-hellings/gully/blob/master/src/main/java/com/thehellings/gully/Router.java >> >> https://github.com/greg-hellings/gully/blob/master/src/main/java/com/thehellings/gully/PlainRouter.java >> >> I haven't used it extensively, but in my own local testing it seems to >> work exactly the way I wanted - it's still just an HttpHandler >> underneath, so it can be placed anywhere in a handler chain. And it >> operates on the result of getRelativePath, so you can nest them within >> each other, or place them within other components in a handler chain >> and the class should operate properly. >> >> The whole set of handler and its dependent classes should be available >> as a Maven artifact if you want to play with it. If this sort of >> functionality exists somewhere in core Undertow, I've been entirely >> unable to decipher it and locate its functioning. >> >> --Greg >> >> On Tue, Sep 6, 2016 at 9:41 PM, Oliver Dain >> wrote: >> > Hey all, >> > >> > I haven't seen any documentation on the format of a template accepted >> by a >> > PathTemplateHandler. I know the basics: "/foo", "/foo/{userId}", etc. >> but >> > are wildcards allowed? Is there a way to specify a handler for anything >> with >> > a certain prefix? If two handlers would match how is the tie broken, >> etc. >> > >> > Thanks, >> > Oliver >> > -- >> > CTO, Analytic Spot >> > 44 West Broadway #222 >> > Eugene, OR 97401 >> > analyticspot.com ? 425-296-6556 >> > www.linkedin.com/in/oliverdain >> > >> > _______________________________________________ >> > undertow-dev mailing list >> > undertow-dev at lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/undertow-dev >> >> _______________________________________________ >> undertow-dev mailing list >> undertow-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/undertow-dev > > > -- CTO, Analytic Spot 44 West Broadway #222 Eugene, OR 97401 analyticspot.com ? 425-296-6556 www.linkedin.com/in/oliverdain -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20160907/c342fe32/attachment-0001.html From oliver at analyticspot.com Wed Sep 7 20:58:37 2016 From: oliver at analyticspot.com (Oliver Dain) Date: Thu, 08 Sep 2016 00:58:37 +0000 Subject: [undertow-dev] Docs for templates In-Reply-To: References: Message-ID: Hey all, I added my own router handler that does everything I need it to do. It's pretty well documented and very well tested. I'd be willing to submit a pull request to have this added to Undertow if that'd be valuable to anyone. Here's a taste of the code (the core stuff is in PathTrie): package com.analyticspot.uservices.server.router; import com.analyticspot.httputils.HttpVerb; import com.analyticspot.httputils.ResponseCodes; import com.memoizrlabs.retrooptional.Optional; import io.undertow.server.HttpHandler; import io.undertow.server.HttpServerExchange; import io.undertow.util.AttachmentKey; import java.util.Map; import java.util.TreeMap; /** * An HttpHandler that routes requests to other handlers based on paths and path templates. It is thread safe to * search this class concurrently (match paths) but adding paths is not thread safe. Thus the expected use-case is * that all paths are set up before the handler is added as an Undertow listener. * *

The rules for path matching are: *

    *
  • All paths must begin with a "/"
    • *
  • Wildcard matches are allowed by adding "{X}" to the path. Then {@code X} and what matched it are attached * to the request in a {@code Map} from {@code X} to the value that matched. For example, if the added path was * "/foo/{name}/stuff/{age}" and the observed path was "/foo/bar/stuff/22" then the attachment would have a map * like "{name: bar, age: 22}.
    • *
  • Prefix paths are allowed. Such paths will match anything that begins with the provided prefix.
    • *
  • Exact matches and/or longer matches take precedence over both prefix and wildcard matches. Thus, given the * wildcard path "/foo/{name}", the prefix path "/foo/baz", and the exact path "/foo/bar", we would expect the * following matches: * * * * * * *
    Observed PathMatched Path
    /foo/bar/foo/bar
    /foo/baz/foo/baz
    /foo/baz/bump/foo/baz
    /foo/gourdy/foo/{name}
    *
    • *
  • This is not a "backtracking" matcher. Thus, given a prefix path of "/foo/bar" and an exact path * "/foo/bar/baz", the observed path "/foo/bar/baz/bizzle" would have no match because "/foo/bar/baz" * doesn't match and we do not backtrack to the shorter "/foo/bar" prefix to see if it matches.
    • *
  • If both a prefix and a wildcard match, the wildcard takes precendence. Thus given prefix path "/foo" and * wildcard path "/foo/{name}", the match for obeserved path "/foo/bar" would be the wildcard path.
    • *
* *

We added our own router due to limitations in the Undertow PathTemplateHandler and RoutingHandler. See * http://lists.jboss.org/pipermail/undertow-dev/2016-September/001685.html for details. */ public class PathRoutingHandler implements HttpHandler { public static AttachmentKey PATH_MATCH_KEY = AttachmentKey.create(PathMatch.class); // Map from HTTP verb to the PathTrie for the handlers for that route. private final Map verbToPathTrie = new TreeMap<>(); // If present and none of the paths match this handler will be called. Optional fallbackHandler; public PathRoutingHandler() { fallbackHandler = Optional.empty(); } /** * Provides a fallback handler which will handle the request if nothing in the trie matches. */ public PathRoutingHandler(HttpHandler fallbackHandler) { this.fallbackHandler = Optional.of(fallbackHandler); } /** * Adds a handler for the given URL/verb combination. The path can be a template as per the class comment. */ public void addHandler(HttpVerb verb, String path, HttpHandler handler) { PathTrie trie = getTrie(verb); trie.addPath(path, handler); } /** * Like {@link #addHandler(HttpVerb, String, HttpHandler)}but add a prefix handler. */ public void addPrefixHandler(HttpVerb verb, String path, HttpHandler handler) { PathTrie trie = getTrie(verb); trie.addPrefixPath(path, handler); } private PathTrie getTrie(HttpVerb verb) { if (!verbToPathTrie.containsKey(verb)) { PathTrie trie = new PathTrie(); verbToPathTrie.put(verb, trie); return trie; } else { return verbToPathTrie.get(verb); } } @Override public void handleRequest(HttpServerExchange exchange) throws Exception { HttpVerb verb = HttpVerb.fromString(exchange.getRequestMethod().toString()); PathTrie trie = verbToPathTrie.get(verb); if (trie == null) { handleNoMatch(exchange); } else { Optional optMatch = trie.findMatch(exchange.getRelativePath()); if (optMatch.isPresent()) { exchange.putAttachment(PATH_MATCH_KEY, optMatch.get()); optMatch.get().getHandler().handleRequest(exchange); } else { handleNoMatch(exchange); } } } private void handleNoMatch(HttpServerExchange exchange) throws Exception { if (fallbackHandler.isPresent()) { fallbackHandler.get().handleRequest(exchange); } else { exchange.setStatusCode(ResponseCodes.NOT_FOUND.getCode()); exchange.endExchange(); } } } -- Oliver On Wed, Sep 7, 2016 at 11:35 AM Oliver Dain wrote: > Thanks Greg and Bill! > > On Wed, Sep 7, 2016 at 6:20 AM Bill O'Neil wrote: > >> I did something similar to Greg by delegating to a RoutingHandler which >> has a PathHandler fallback. >> >> https://gist.github.com/billoneil/08b1648a3b2a849e02c57e133bd6d45c >> >> This allows me to add prefix routes but still not flexible enough for all >> uses cases. The main drawback with this approach is the prefix handler >> doesn't route based on Verb but it has worked for all of my use cases so >> far. >> >> I would also like to know if there is a way the RoutingHandler can be >> extended to have wildcard functionality. >> >> On Wed, Sep 7, 2016 at 8:08 AM, Greg Hellings >> wrote: >> >>> Oliver, >>> >>> I found it very difficult to work with the PathTemplateHandler and its >>> set of matching operations seemed very minimal to me. I also found no >>> efficient way to mix-and-match between full Paths and PathTemplate >>> entries. So I created my own handler class that gave the ability to >>> match based on both HTTP Verb and various path components. >>> >>> >>> https://github.com/greg-hellings/gully/blob/master/src/main/java/com/thehellings/gully/Router.java >>> >>> https://github.com/greg-hellings/gully/blob/master/src/main/java/com/thehellings/gully/PlainRouter.java >>> >>> I haven't used it extensively, but in my own local testing it seems to >>> work exactly the way I wanted - it's still just an HttpHandler >>> underneath, so it can be placed anywhere in a handler chain. And it >>> operates on the result of getRelativePath, so you can nest them within >>> each other, or place them within other components in a handler chain >>> and the class should operate properly. >>> >>> The whole set of handler and its dependent classes should be available >>> as a Maven artifact if you want to play with it. If this sort of >>> functionality exists somewhere in core Undertow, I've been entirely >>> unable to decipher it and locate its functioning. >>> >>> --Greg >>> >>> On Tue, Sep 6, 2016 at 9:41 PM, Oliver Dain >>> wrote: >>> > Hey all, >>> > >>> > I haven't seen any documentation on the format of a template accepted >>> by a >>> > PathTemplateHandler. I know the basics: "/foo", "/foo/{userId}", etc. >>> but >>> > are wildcards allowed? Is there a way to specify a handler for >>> anything with >>> > a certain prefix? If two handlers would match how is the tie broken, >>> etc. >>> > >>> > Thanks, >>> > Oliver >>> > -- >>> > CTO, Analytic Spot >>> > 44 West Broadway #222 >>> > Eugene, OR 97401 >>> > analyticspot.com ? 425-296-6556 >>> > www.linkedin.com/in/oliverdain >>> > >>> > _______________________________________________ >>> > undertow-dev mailing list >>> > undertow-dev at lists.jboss.org >>> > https://lists.jboss.org/mailman/listinfo/undertow-dev >>> >>> _______________________________________________ >>> undertow-dev mailing list >>> undertow-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/undertow-dev >> >> >> -- > CTO, Analytic Spot > 44 West Broadway #222 > Eugene, OR 97401 > analyticspot.com ? 425-296-6556 > www.linkedin.com/in/oliverdain > -- CTO, Analytic Spot 44 West Broadway #222 Eugene, OR 97401 analyticspot.com ? 425-296-6556 www.linkedin.com/in/oliverdain -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20160908/8af5ff27/attachment.html From sven at kubiak.me Fri Sep 9 02:10:02 2016 From: sven at kubiak.me (Sven Kubiak) Date: Fri, 9 Sep 2016 06:10:02 +0000 Subject: [undertow-dev] Undertow with contextpath Message-ID: <1473401402694.84682@kubiak.me> ?Hello, is there an option to set a contextpath? Or what is the best practice on this? For e.g., I want to have all request behind a context like "/foo". Cheers, Sven -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20160909/91f6f7ac/attachment-0001.html From sdouglas at redhat.com Sun Sep 11 17:50:03 2016 From: sdouglas at redhat.com (Stuart Douglas) Date: Mon, 12 Sep 2016 07:50:03 +1000 Subject: [undertow-dev] Undertow with contextpath In-Reply-To: <1473401402694.84682@kubiak.me> References: <1473401402694.84682@kubiak.me> Message-ID: You probably just want to use PathHandler and register your handlers under your path. Stuart On Fri, Sep 9, 2016 at 4:10 PM, Sven Kubiak wrote: > Hello, > > > is there an option to set a contextpath? Or what is the best practice on > this? > > > For e.g., I want to have all request behind a context like "/foo". > > > Cheers, > > Sven > > > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev From oliver at analyticspot.com Sun Sep 11 21:38:12 2016 From: oliver at analyticspot.com (Oliver Dain) Date: Mon, 12 Sep 2016 01:38:12 +0000 Subject: [undertow-dev] Debugging HttpServerExchange cannot have both async IO resumed and dispatch Message-ID: I'm getting the following exception when I run an integration test, but only sometimes: HttpServerExchange cannot have both async IO resumed and dispatch() called in the same cycle So clearly I've got some kind of race condition where sometimes I'm doing things in an odd order, but I can't figure out where. Part of the issue is that the above error doesn't include a stack trace so it's hard for me to tell where it is in the code when this happens. Is there a way to get a stack trace? Also, I'm calling "exchange.setResponseCookie" after having called dispatch but before ending the exchange. That should be safe, right? It's the only thing I can think of. As far as I can tell, what happens is the request comes in, a few handlers examine the request, but those are read-only operations for logging and such, then then dispatch to a wrapped handler. Finally get to our inner-most handler which calls dispatch. That then does some async work (a lookup in a database) and, when it's complete it sets a few cookies. After that the response is put on the exchange via "exchange.getResponseSender().send". Finally a few things listen for the exchange to complete so they can log some things but these are again calling read-only properties like "exchange.getStatusCode()", "exchange.getResponseBytesSent()", and "exchange.getResponseCookies().keySet())". Any ideas what might be causing this error? thanks, Oliver -- CTO, Analytic Spot 44 West Broadway #222 Eugene, OR 97401 analyticspot.com ? 425-296-6556 www.linkedin.com/in/oliverdain -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20160912/ef4dd296/attachment.html From espina.edgar at gmail.com Tue Sep 13 11:43:57 2016 From: espina.edgar at gmail.com (Edgar Espina) Date: Tue, 13 Sep 2016 15:43:57 +0000 Subject: [undertow-dev] let's encrypt Message-ID: Hi, I'm playing with https://github.com/shred/acme4j, let's encrypt and undertow. I made some progress but it is hard to test if the certificate works without and real domain. I'm using ngrok but think there is a problem there with HTTPS... not sure. Anyway, I want to know if there is a way to dynamically renew the certificate at runtime (no downtime). Don't think is possible with existing API, is it? Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20160913/9f9b63d3/attachment.html From sdouglas at redhat.com Tue Sep 13 19:07:32 2016 From: sdouglas at redhat.com (Stuart Douglas) Date: Wed, 14 Sep 2016 09:07:32 +1000 Subject: [undertow-dev] let's encrypt In-Reply-To: References: Message-ID: It should be, although it would be a little bit of work. You need to wrap the SSLContext (or rather implement OpenSSLContextSPI) to delegate to a 'real' underlying context. When the certificate changes you just build a new context and then change the one you are delegating too, which means all new connections will use the new context. Stuart On Wed, Sep 14, 2016 at 1:43 AM, Edgar Espina wrote: > Hi, > > I'm playing with https://github.com/shred/acme4j, let's encrypt and > undertow. I made some progress but it is hard to test if the certificate > works without and real domain. I'm using ngrok but think there is a problem > there with HTTPS... not sure. > > Anyway, I want to know if there is a way to dynamically renew the > certificate at runtime (no downtime). > > Don't think is possible with existing API, is it? > > Thanks > > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev From paroczizs at gmail.com Mon Sep 19 10:56:00 2016 From: paroczizs at gmail.com (paroczizs .) Date: Mon, 19 Sep 2016 16:56:00 +0200 Subject: [undertow-dev] ProxyHandler timeout handling Message-ID: Hi, I am using a ProxyHandler with a ProxyClient from a custom handler. ... ProxyClient lbpc = getProxyClient(); ProxyHandler proxyhandler = new ProxyHandler(lbpc, requestTimeout, ResponseCodeHandler.HANDLE_404); ... It handles the timeout correctly however I can see some error after my handler, the timeout logged properly. 16:43:28,566 INFO [stdout] (default I/O-4) LWI COMPLETED 200 status 200 16:43:28,597 ERROR [io.undertow.proxy] (default I/O-4) UT005027: Timing out request to /lwi/cnr/getMsisdn 16:43:28,658 ERROR [org.xnio.listener] (default I/O-4) XNIO001007: A channel event listener threw an exception: java.lang.IllegalStateException: UT000139: Exchange already complete at io.undertow.server.HttpServerExchange.addExchangeCompleteListener(HttpServerExchange.java:916) at io.undertow.server.handlers.proxy.ProxyConnectionPool.connectionReady(ProxyConnectionPool.java:315) at io.undertow.server.handlers.proxy.ProxyConnectionPool.access$900(ProxyConnectionPool.java:58) at io.undertow.server.handlers.proxy.ProxyConnectionPool$1.completed(ProxyConnectionPool.java:278) at io.undertow.server.handlers.proxy.ProxyConnectionPool$1.completed(ProxyConnectionPool.java:265) at io.undertow.client.http.HttpClientProvider.handleConnected(HttpClientProvider.java:156) at io.undertow.client.http.HttpClientProvider.access$000(HttpClientProvider.java:51) at io.undertow.client.http.HttpClientProvider$2.handleEvent(HttpClientProvider.java:127) at io.undertow.client.http.HttpClientProvider$2.handleEvent(HttpClientProvider.java:124) at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) at org.xnio.nio.WorkerThread$ConnectHandle.handleReady(WorkerThread.java:326) at org.xnio.nio.WorkerThread.run(WorkerThread.java:567) Is it the normal behavior and nothing to do with it? Is there a way to catch the timeout error and give some custom response? Regards, Zsolt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20160919/0fb937f9/attachment.html From sdouglas at redhat.com Mon Sep 19 17:25:34 2016 From: sdouglas at redhat.com (Stuart Douglas) Date: Tue, 20 Sep 2016 07:25:34 +1000 Subject: [undertow-dev] ProxyHandler timeout handling In-Reply-To: References: Message-ID: This looks like a bug, can you file a JIRA? It looks like it is still attempting to associate a connection with the request after the request has timed out. This will not affect the functionality, but will result in annoying log messages. Stuart On Tue, Sep 20, 2016 at 12:56 AM, paroczizs . wrote: > Hi, > > I am using a ProxyHandler with a ProxyClient from a custom handler. > > ... > ProxyClient lbpc = getProxyClient(); > ProxyHandler proxyhandler = new ProxyHandler(lbpc, requestTimeout, > ResponseCodeHandler.HANDLE_404); > ... > > It handles the timeout correctly however I can see some error after my > handler, the timeout logged properly. > > 16:43:28,566 INFO [stdout] (default I/O-4) LWI COMPLETED 200 status 200 > > 16:43:28,597 ERROR [io.undertow.proxy] (default I/O-4) UT005027: Timing out > request to /lwi/cnr/getMsisdn > 16:43:28,658 ERROR [org.xnio.listener] (default I/O-4) XNIO001007: A channel > event listener threw an exception: java.lang.IllegalStateException: > UT000139: Exchange already complete > at > io.undertow.server.HttpServerExchange.addExchangeCompleteListener(HttpServerExchange.java:916) > at > io.undertow.server.handlers.proxy.ProxyConnectionPool.connectionReady(ProxyConnectionPool.java:315) > at > io.undertow.server.handlers.proxy.ProxyConnectionPool.access$900(ProxyConnectionPool.java:58) > at > io.undertow.server.handlers.proxy.ProxyConnectionPool$1.completed(ProxyConnectionPool.java:278) > at > io.undertow.server.handlers.proxy.ProxyConnectionPool$1.completed(ProxyConnectionPool.java:265) > at > io.undertow.client.http.HttpClientProvider.handleConnected(HttpClientProvider.java:156) > at > io.undertow.client.http.HttpClientProvider.access$000(HttpClientProvider.java:51) > at > io.undertow.client.http.HttpClientProvider$2.handleEvent(HttpClientProvider.java:127) > at > io.undertow.client.http.HttpClientProvider$2.handleEvent(HttpClientProvider.java:124) > at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) > at > org.xnio.nio.WorkerThread$ConnectHandle.handleReady(WorkerThread.java:326) > at org.xnio.nio.WorkerThread.run(WorkerThread.java:567) > > > > Is it the normal behavior and nothing to do with it? > > Is there a way to catch the timeout error and give some custom response? > > > Regards, Zsolt > > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev From paroczizs at gmail.com Wed Sep 21 04:10:21 2016 From: paroczizs at gmail.com (paroczizs .) Date: Wed, 21 Sep 2016 10:10:21 +0200 Subject: [undertow-dev] UT000005: getRequestChannel() has already been called Message-ID: Hi, we are implementing a proxy solution based on Wildfly/Undertow. There are a couple of custom handler configured in a row. Two of the handlers are deal with the incoming request ? message validator and message log. The message validator use the solution form this class to read the incoming request: core/src/main/java/io/undertow/server/handlers/RequestBufferingHandler.java The message log based on conduits and logs on the exchange complete event. It works almost perfectly however the first request fails with this when the log handler registers the conduit: 2016-09-21 10:05:02,034 INFO [hu.telekom.lwi.plugin.log.LwiLogHandler] (default task-1) [lwiId-lpx1474445101966] LwiLogHandler > start request/response log handling (FULL)... 2016-09-21 10:05:02,039 ERROR [io.undertow.request] (default task-1) UT005071: Undertow request failed HttpServerExchange{ POST /lwi/cnr/getMsisdn request {X-MT-UserId=[pzs], SOAPAction=[""], X-MT-CorrelationId=[123], Accept-Encoding=[gzip,deflate], X-Lwi-RequestId=[lwiId-lpx1474445101966], User-Agent=[Apache-HttpClient/4.1.1 (java 1.5)], X-SSL-Client-CN=[lwitester1], X-MT-RequestId=[12345], Content-Type=[text/xml;charset=UTF-8], Content-Length=[798], Host=[localhost:444]} response {}}: java.lang.IllegalStateException: UT000005: getRequestChannel() has already been called at io.undertow.server.HttpServerExchange.addRequestWrapper(HttpServerExchange.java:1406) at hu.telekom.lwi.plugin.log.LwiConduitWrapper.applyConduits(LwiConduitWrapper.java:50) at hu.telekom.lwi.plugin.log.LwiLogHandler.handleRequest(LwiLogHandler.java:38) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at hu.telekom.lwi.plugin.validation.ValidationHandler.handleRequest(ValidationHandler.java:78) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52) at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202) at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:805) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) After the first call everything work perfectly there is no error, however it is true that the exchange.getRequestChannel() was called in the message validation handler. Is it any work around for this? Regards, Zsolt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20160921/dc9053aa/attachment.html From sdouglas at redhat.com Wed Sep 21 19:42:10 2016 From: sdouglas at redhat.com (Stuart Douglas) Date: Thu, 22 Sep 2016 09:42:10 +1000 Subject: [undertow-dev] UT000005: getRequestChannel() has already been called In-Reply-To: References: Message-ID: Not really, the reason why you are only allowed to call it once is because in general a single handler should 'own' the action of reading from the request (because after the first handler has read from the request channel there will generally be nothing left to read). If you really need two handlers to look at the request you can read the full body in an early handler, and attach it to the exchange, and then have the later handlers just examine the buffered data. Obviously if the requests are large this can cause memory exhaustion issues, so you need to make sure you have some kind of limit in place. Stuart On Wed, Sep 21, 2016 at 6:10 PM, paroczizs . wrote: > Hi, > > > > we are implementing a proxy solution based on Wildfly/Undertow. > > > > There are a couple of custom handler configured in a row. Two of the > handlers are deal with the incoming request ? message validator and message > log. > > > > The message validator use the solution form this class to read the incoming > request: > > > > core/src/main/java/io/undertow/server/handlers/RequestBufferingHandler.java > > > > The message log based on conduits and logs on the exchange complete event. > > > > It works almost perfectly however the first request fails with this when the > log handler registers the conduit: > > > > 2016-09-21 10:05:02,034 INFO [hu.telekom.lwi.plugin.log.LwiLogHandler] > (default task-1) [lwiId-lpx1474445101966] LwiLogHandler > start > request/response log handling (FULL)... > > 2016-09-21 10:05:02,039 ERROR [io.undertow.request] (default task-1) > UT005071: Undertow request failed HttpServerExchange{ POST > /lwi/cnr/getMsisdn request {X-MT-UserId=[pzs], SOAPAction=[""], > X-MT-CorrelationId=[123], Accept-Encoding=[gzip,deflate], > X-Lwi-RequestId=[lwiId-lpx1474445101966], > User-Agent=[Apache-HttpClient/4.1.1 (java 1.5)], > X-SSL-Client-CN=[lwitester1], X-MT-RequestId=[12345], > Content-Type=[text/xml;charset=UTF-8], Content-Length=[798], > Host=[localhost:444]} response {}}: java.lang.IllegalStateException: > UT000005: getRequestChannel() has already been called > > at > io.undertow.server.HttpServerExchange.addRequestWrapper(HttpServerExchange.java:1406) > > at > hu.telekom.lwi.plugin.log.LwiConduitWrapper.applyConduits(LwiConduitWrapper.java:50) > > at > hu.telekom.lwi.plugin.log.LwiLogHandler.handleRequest(LwiLogHandler.java:38) > > at > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > > at > hu.telekom.lwi.plugin.validation.ValidationHandler.handleRequest(ValidationHandler.java:78) > > at > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > > at > io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52) > > at > io.undertow.server.Connectors.executeRootHandler(Connectors.java:202) > > at > io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:805) > > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > > at java.lang.Thread.run(Thread.java:745) > > > > > > After the first call everything work perfectly there is no error, however it > is true that the exchange.getRequestChannel() was called in the message > validation handler. > > > > Is it any work around for this? > > > > Regards, Zsolt > > > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev From michael.hixson at gmail.com Fri Sep 23 00:30:17 2016 From: michael.hixson at gmail.com (Michael Hixson) Date: Thu, 22 Sep 2016 21:30:17 -0700 Subject: [undertow-dev] exchange.dispatch() deprecation - safe to ignore? Message-ID: Hello, I'm using the no-argument version of HttpServerExchange.dispatch(), and I just noticed that it's deprecated. I'm using dispatch() to suspend the exchange, to make sure the exchange isn't completed when the call stack returns. Basically I'm telling it, "Go to sleep. I'll be back later to finish things." Is that an inappropriate use of dispatch()? It's not clear that the suggested alternative of dispatch(Executor,Runnable) is better in this case. What arguments would I provide? dispatch(null, () -> {}) ? -Michael From sdouglas at redhat.com Fri Sep 23 00:33:59 2016 From: sdouglas at redhat.com (Stuart Douglas) Date: Fri, 23 Sep 2016 14:33:59 +1000 Subject: [undertow-dev] exchange.dispatch() deprecation - safe to ignore? In-Reply-To: References: Message-ID: The issue is that in general when using that version of the method there is no way to know if the call stack is still active when you 'come back to finish things'. This can result in two threads being active in the exchange, which can result in hard to diagnose problems. In general you should use: dispatch(SameThreadExecutor.INSTANCE, () -> {startAsyncWork() }); Where whatever is in the Runnable is what kicks off your async work. This means that the call stack will have returned before your async work starts, so there is no chance of a race condition. Stuart On Fri, Sep 23, 2016 at 2:30 PM, Michael Hixson wrote: > Hello, > > I'm using the no-argument version of HttpServerExchange.dispatch(), > and I just noticed that it's deprecated. > > I'm using dispatch() to suspend the exchange, to make sure the > exchange isn't completed when the call stack returns. Basically I'm > telling it, "Go to sleep. I'll be back later to finish things." > > Is that an inappropriate use of dispatch()? > > It's not clear that the suggested alternative of > dispatch(Executor,Runnable) is better in this case. What arguments > would I provide? dispatch(null, () -> {}) ? > > -Michael > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev From matt at syple.com.au Fri Sep 30 00:44:41 2016 From: matt at syple.com.au (Matt Smith) Date: Fri, 30 Sep 2016 14:14:41 +0930 Subject: [undertow-dev] JSESSIONIDSSO cookie not set in response on Wildfly 9 Message-ID: Hi, I am working on several JEE web apps that are deployed on a Wildfly 9.0.2 application server. We have SSO enabled and working, but are having an issue where the SSO cookie is not always returned. Specifically, if we restart the Wildfly instance, two of the several applications deployed on the server stop returning the JSESSIONIDSSO cookie in their responses. If we disable and then re-enable those apps then they work perfectly until the next time Wildfly is restarted. The issue described occurs in both UAT and Production environments. Both environments are set up in clustered mode, with the only real difference being that UAT has more applications deployed on it. The Wildfly instances also sit behind an Apache HTTPd reverse proxy using mod_proxy. If the servers are accessed directly - bypassing the Apache server - the problem does not occur. After much poking around I can only assume that the issue is triggered by the different headers present on the proxied requests. That's a guess though and I would really appreciate any input from people who know Undertow much better. All of our applications are configured the same way with regards to security and the technology stack used. Authentication is provided by the server via a security domain that delegates to a security realm, and is backed by Active Directory. I have attached the relevant configuration files and examples of the requests and responses. In terms of versions, I have reproduced the issue in Wildfly 8.0.2, 9.0.1, 9.0.2, and 10.0.1 (not sure what Undertow versions they correspond to). The Wildfly forum had no answers and directed me here, so I hope someone here can help! (PS I've changed the actual IP addresses, server names, etc in the attached files so I don't expose the real systems - I know the IPs aren't valid, but they are on the real system!) Thanks, Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20160930/b13eba05/attachment-0001.html -------------- next part -------------- ============================================================== 2016-09-06 11:42:07,002 INFO [io.undertow.request.dump] (default task-16) ----------------------------REQUEST--------------------------- URI=/app/login characterEncoding=null contentLength=41 contentType=[application/x-www-form-urlencoded] header=Accept=application/json, text/plain, */* header=Postman-Token=cf48a071-6e88-0353-0738-2337cf89cbed header=Accept-Encoding=gzip, deflate header=X-Forwarded-Server=proxy.domain.local header=Origin=http://localhost:8100 header=User-Agent=Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/49.0.2623.110 Safari/537.36 header=Connection=close header=X-Forwarded-For=10.123.456.789 header=Content-Type=application/x-www-form-urlencoded header=Content-Length=41 header=Referer=http://localhost:8100/ header=Host=proxy header=X-Forwarded-Host=proxy locale=[] method=POST protocol=HTTP/1.1 queryString= remoteAddr=/10.321.654.987:55717 remoteHost=srv.domain.local scheme=http host=proxy serverPort=8080 --------------------------RESPONSE-------------------------- contentLength=23 contentType=application/json cookie=JSESSIONID=jpYr_sVfCkwjVEt9Z2lMqCp7QMxQlR5LF6ivd23B.servername; domain=null; path=/app header=Connection=close header=X-Powered-By=Undertow/1 header=Set-Cookie=JSESSIONID=jpYr_sVfCkwjVEt9Z2lMqCp7QMxQlR5LF6ivd23B.servername; path=/app header=Server=WildFly/9 header=Content-Type=application/json header=Content-Length=23 header=Date=Tue, 06 Sep 2016 01:42:07 GMT status=200 -------------- next part -------------- A non-text attachment was scrubbed... Name: jboss-web.xml Type: text/xml Size: 80 bytes Desc: not available Url : http://lists.jboss.org/pipermail/undertow-dev/attachments/20160930/b13eba05/attachment-0003.xml -------------- next part -------------- A non-text attachment was scrubbed... Name: standalone.xml Type: text/xml Size: 3472 bytes Desc: not available Url : http://lists.jboss.org/pipermail/undertow-dev/attachments/20160930/b13eba05/attachment-0004.xml -------------- next part -------------- A non-text attachment was scrubbed... Name: web.xml Type: text/xml Size: 1829 bytes Desc: not available Url : http://lists.jboss.org/pipermail/undertow-dev/attachments/20160930/b13eba05/attachment-0005.xml -------------- next part -------------- ============================================================== 2016-09-06 11:48:05,934 INFO [io.undertow.request.dump] (default task-56) ----------------------------REQUEST--------------------------- URI=/app/login characterEncoding=null contentLength=41 contentType=[application/x-www-form-urlencoded] header=Accept=application/json, text/plain, */* header=Postman-Token=13ddd2a4-3ec8-3e5b-b322-567f69c6e39d header=Accept-Encoding=gzip, deflate header=X-Forwarded-Server=proxy.domain.local header=Origin=http://localhost:8100 header=User-Agent=Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/49.0.2623.110 Safari/537.36 header=Connection=close header=X-Forwarded-For=10.123.456.789 header=Content-Type=application/x-www-form-urlencoded header=Content-Length=41 header=Referer=http://localhost:8100/ header=Host=proxy header=X-Forwarded-Host=proxy locale=[] method=POST protocol=HTTP/1.1 queryString= remoteAddr=/10.321.654.987:55755 remoteHost=dsrv.domain.local scheme=http host=proxy serverPort=8080 --------------------------RESPONSE-------------------------- contentLength=23 contentType=application/json cookie=JSESSIONID=BmEsI_nY0iwZBxVNq3xepVygfDiVHpi7GcMoFGsm.servername; domain=null; path=/app cookie=JSESSIONIDSSO=pt4XmsDzWWpyE3Gsqp0cA5n1Ourt-WY_X_kntY-8; domain=null; path=/ header=Connection=close header=X-Powered-By=Undertow/1 header=Set-Cookie=JSESSIONID=BmEsI_nY0iwZBxVNq3xepVygfDiVHpi7GcMoFGsm.servername; path=/app header=Set-Cookie=JSESSIONIDSSO=pt4XmsDzWWpyE3Gsqp0cA5n1Ourt-WY_X_kntY-8; path=/ header=Server=WildFly/9 header=Content-Type=application/json header=Content-Length=23 header=Date=Tue, 06 Sep 2016 01:48:05 GMT status=200 From cedric.tranxuan at motwin.com Fri Sep 30 12:05:13 2016 From: cedric.tranxuan at motwin.com (=?UTF-8?Q?C=C3=A9dric_Tran=2DXuan?=) Date: Fri, 30 Sep 2016 18:05:13 +0200 Subject: [undertow-dev] Server-Sent Event: support of retry reconnection time Message-ID: Hello, We are using the Undertow SSE support. In the SSE spec, it is possible to send a "retry: