From shanloid at gmail.com Wed Apr 1 01:25:56 2015 From: shanloid at gmail.com (Shannon Lloyd) Date: Wed, 1 Apr 2015 15:25:56 +1000 Subject: [undertow-dev] Proxy handler clobbering X-Forwarded-Proto header Message-ID: We have a setup which looks like this: AWS ELB --> Undertow Service A with ProxyHandler --> Undertow Service B Traffic comes in to the ELB on HTTPS, the SSL gets terminated, and HTTP traffic flows through to service A with the X-Forwarded-Proto header set to https. We then proxy HTTP traffic through to service B, which is responsible for (amongst other things) generating links. In order to generate these links it needs to know the scheme/protocol on which to make requests from the internet to the ELB. Sadly, it looks like the Undertow proxy handler is clobbering this information by naively assuming that the request scheme used to hit this Undertow service should be the forwarded proto (ProxyHandler lines 434-436): // Set the protocol header and attachment final String proto = exchange.getRequestScheme().equals("https") ? "https" : "http"; request.getRequestHeaders().put(Headers.X_FORWARDED_PROTO, proto); This does not check to see if there is a pre-existing proto header already set. In our case there is one, and it is set to https, but once it passes through this block, it has been rewritten to http, which is incorrect. I noticed that higher up in the ProxyHandler logic where it handled X-Forwarded-For it actually employs some logic (configurable) to not clobber any existing value. I get why this is - because it can be a list of addresses - but is there some reason why we wouldn't want a similar check for the original protocol? Our workaround for this is to copy the proto header into a custom header via a HttpHandler, ensuring that it gets copied from the incoming exchange to the outgoing exchange without being touched by Undertow, but this is a bit of a hack. Ideally we'd prefer any pre-existing proto header to be preserved, and to only use the request scheme as the fallback when no header exists. Cheers, Shannon -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20150401/93c3a68f/attachment.html From sdouglas at redhat.com Wed Apr 1 03:48:39 2015 From: sdouglas at redhat.com (Stuart Douglas) Date: Wed, 1 Apr 2015 03:48:39 -0400 (EDT) Subject: [undertow-dev] Proxy handler clobbering X-Forwarded-Proto header In-Reply-To: References: Message-ID: <300591867.10182771.1427874519525.JavaMail.zimbra@redhat.com> This was basically an oversight. I have pushed up a fix (hopefully) to master and the 1.1 branch. Stuart ----- Original Message ----- > From: "Shannon Lloyd" > To: undertow-dev at lists.jboss.org > Sent: Wednesday, 1 April, 2015 4:25:56 PM > Subject: [undertow-dev] Proxy handler clobbering X-Forwarded-Proto header > > We have a setup which looks like this: > > AWS ELB --> Undertow Service A with ProxyHandler --> Undertow Service B > > Traffic comes in to the ELB on HTTPS, the SSL gets terminated, and HTTP > traffic flows through to service A with the X-Forwarded-Proto header set to > https. We then proxy HTTP traffic through to service B, which is responsible > for (amongst other things) generating links. In order to generate these > links it needs to know the scheme/protocol on which to make requests from > the internet to the ELB. > > Sadly, it looks like the Undertow proxy handler is clobbering this > information by naively assuming that the request scheme used to hit this > Undertow service should be the forwarded proto (ProxyHandler lines 434-436): > > // Set the protocol header and attachment > final String proto = exchange.getRequestScheme().equals("https") ? "https" : > "http"; > request.getRequestHeaders().put(Headers.X_FORWARDED_PROTO, proto); > > This does not check to see if there is a pre-existing proto header already > set. In our case there is one, and it is set to https, but once it passes > through this block, it has been rewritten to http, which is incorrect. > > I noticed that higher up in the ProxyHandler logic where it handled > X-Forwarded-For it actually employs some logic (configurable) to not clobber > any existing value. I get why this is - because it can be a list of > addresses - but is there some reason why we wouldn't want a similar check > for the original protocol? > > Our workaround for this is to copy the proto header into a custom header via > a HttpHandler, ensuring that it gets copied from the incoming exchange to > the outgoing exchange without being touched by Undertow, but this is a bit > of a hack. Ideally we'd prefer any pre-existing proto header to be > preserved, and to only use the request scheme as the fallback when no header > exists. > > Cheers, > Shannon > > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev From sdouglas at redhat.com Tue Apr 7 18:12:31 2015 From: sdouglas at redhat.com (Stuart Douglas) Date: Tue, 7 Apr 2015 18:12:31 -0400 (EDT) Subject: [undertow-dev] Using JavaScript with Undertow In-Reply-To: <630478949.14122365.1428444566346.JavaMail.zimbra@redhat.com> Message-ID: <1041706352.14122714.1428444751893.JavaMail.zimbra@redhat.com> Hi all, There has been some discussion about supporting JavaScript in Wildfly/Undertow for a while now, and as a result I have come up with a simple proof of concept of the form I think this support could take. The form that this is taking is undertow.js, which is a jar file that you can include in your apps and allows you to register JavaScript based handlers. These handlers can be mapped to URL's, and inject container resources such as CDI beans and JNDI data sources. It also provide some simple JavaScript wrappers to make some EE objects easier to use from scripts. Injection support is pluggable, and this can be used programatically from embedded Undertow. At the moment handlers are mainly useful as REST endpoints, although if there is interest I am planning on adding template engine support as well. When using Wildfly upstream's new external resources feature this allows for changes in your script files to be immediately visible, without even needing to copy to an exploded deployment. I envisage the main use of this will not be creating node.js like apps that are pure javascript, but rather to allow simpler parts of the of a mostly Java app to be written in JavaScript, providing a hybrid approach and this avoiding the compile+redeploy cycle for the javascript parts. Full details are here: https://github.com/undertow-io/undertow.js I have an example of the Kitchen Sink Wildfly quickstart that has been re-done to use this here: https://github.com/wildfly/quickstart/compare/master...stuartwdouglas:js#diff-598449fd216b3768c251e297895211deR1 At this stage I am really not sure how this will evolve, or if it will go anywhere, I am just putting it out there to get some feedback. Stuart From bill at dartalley.com Wed Apr 8 00:30:53 2015 From: bill at dartalley.com (Bill O'Neil) Date: Wed, 8 Apr 2015 00:30:53 -0400 Subject: [undertow-dev] Using JavaScript with Undertow In-Reply-To: <1041706352.14122714.1428444751893.JavaMail.zimbra@redhat.com> References: <630478949.14122365.1428444566346.JavaMail.zimbra@redhat.com> <1041706352.14122714.1428444751893.JavaMail.zimbra@redhat.com> Message-ID: Could this potentially be used to server side render react.js components inside of undertow to create an isomorphic app? I was considering investigating a way to do that. Thanks, Bill On Tue, Apr 7, 2015 at 6:12 PM, Stuart Douglas wrote: > Hi all, > > There has been some discussion about supporting JavaScript in > Wildfly/Undertow for a while now, and as a result I have come up with a > simple proof of concept of the form I think this support could take. > > The form that this is taking is undertow.js, which is a jar file that you > can include in your apps and allows you to register JavaScript based > handlers. These handlers can be mapped to URL's, and inject container > resources such as CDI beans and JNDI data sources. It also provide some > simple JavaScript wrappers to make some EE objects easier to use from > scripts. > > Injection support is pluggable, and this can be used programatically from > embedded Undertow. > > At the moment handlers are mainly useful as REST endpoints, although if > there is interest I am planning on adding template engine support as well. > > When using Wildfly upstream's new external resources feature this allows > for changes in your script files to be immediately visible, without even > needing to copy to an exploded deployment. > > I envisage the main use of this will not be creating node.js like apps > that are pure javascript, but rather to allow simpler parts of the of a > mostly Java app to be written in JavaScript, providing a hybrid approach > and this avoiding the compile+redeploy cycle for the javascript parts. > > Full details are here: https://github.com/undertow-io/undertow.js > > I have an example of the Kitchen Sink Wildfly quickstart that has been > re-done to use this here: > > > https://github.com/wildfly/quickstart/compare/master...stuartwdouglas:js#diff-598449fd216b3768c251e297895211deR1 > > At this stage I am really not sure how this will evolve, or if it will go > anywhere, I am just putting it out there to get some feedback. > > Stuart > _______________________________________________ > 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/20150408/6339117c/attachment.html From sdouglas at redhat.com Wed Apr 8 00:37:28 2015 From: sdouglas at redhat.com (Stuart Douglas) Date: Wed, 8 Apr 2015 00:37:28 -0400 (EDT) Subject: [undertow-dev] Using JavaScript with Undertow In-Reply-To: References: <630478949.14122365.1428444566346.JavaMail.zimbra@redhat.com> <1041706352.14122714.1428444751893.JavaMail.zimbra@redhat.com> Message-ID: <888979200.14228204.1428467848352.JavaMail.zimbra@redhat.com> I think so, although I have not really tried it. The server side react example that I looked at seemed like it would work fine with this (as it just renders to a string which is then sent to a client). I think the biggest potential issue could be react.js and compatibility with Nashorn. Stuart ----- Original Message ----- > From: "Bill O'Neil" > To: "Stuart Douglas" > Cc: "undertow-dev" > Sent: Wednesday, 8 April, 2015 2:30:53 PM > Subject: Re: [undertow-dev] Using JavaScript with Undertow > > Could this potentially be used to server side render react.js components > inside of undertow to create an isomorphic app? I was considering > investigating a way to do that. > > Thanks, > Bill > > On Tue, Apr 7, 2015 at 6:12 PM, Stuart Douglas wrote: > > > Hi all, > > > > There has been some discussion about supporting JavaScript in > > Wildfly/Undertow for a while now, and as a result I have come up with a > > simple proof of concept of the form I think this support could take. > > > > The form that this is taking is undertow.js, which is a jar file that you > > can include in your apps and allows you to register JavaScript based > > handlers. These handlers can be mapped to URL's, and inject container > > resources such as CDI beans and JNDI data sources. It also provide some > > simple JavaScript wrappers to make some EE objects easier to use from > > scripts. > > > > Injection support is pluggable, and this can be used programatically from > > embedded Undertow. > > > > At the moment handlers are mainly useful as REST endpoints, although if > > there is interest I am planning on adding template engine support as well. > > > > When using Wildfly upstream's new external resources feature this allows > > for changes in your script files to be immediately visible, without even > > needing to copy to an exploded deployment. > > > > I envisage the main use of this will not be creating node.js like apps > > that are pure javascript, but rather to allow simpler parts of the of a > > mostly Java app to be written in JavaScript, providing a hybrid approach > > and this avoiding the compile+redeploy cycle for the javascript parts. > > > > Full details are here: https://github.com/undertow-io/undertow.js > > > > I have an example of the Kitchen Sink Wildfly quickstart that has been > > re-done to use this here: > > > > > > https://github.com/wildfly/quickstart/compare/master...stuartwdouglas:js#diff-598449fd216b3768c251e297895211deR1 > > > > At this stage I am really not sure how this will evolve, or if it will go > > anywhere, I am just putting it out there to get some feedback. > > > > Stuart > > _______________________________________________ > > undertow-dev mailing list > > undertow-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/undertow-dev > > > From michael.hixson at gmail.com Wed Apr 8 01:12:59 2015 From: michael.hixson at gmail.com (Michael Hixson) Date: Tue, 7 Apr 2015 22:12:59 -0700 Subject: [undertow-dev] Jersey on Undertow, without servlets? Message-ID: Hello, Has anyone run a Jersey application on Undertow, *without* using servlets? By "using servlets" I mean wrapping an org.glassfish.jersey.server.ResourceConfig in an org.glassfish.jersey.servlet.ServletContainer and deploying that with undertow-servlets. That's pretty easy to do; I don't have any complaints about it. My question comes mostly from curiosity. In my application, ServletContainer is the only connection to the servlet API. My naive view is that the application could be simpler (in terms of the number of hidden gears turning to process requests) and more efficient by avoiding the servlet API completely, and by only using undertow-core. Maybe I'm wrong, or maybe there is so much work involved that no one in their right mind would try it. -Michael From sdouglas at redhat.com Wed Apr 8 02:21:21 2015 From: sdouglas at redhat.com (Stuart Douglas) Date: Wed, 8 Apr 2015 02:21:21 -0400 (EDT) Subject: [undertow-dev] Jersey on Undertow, without servlets? In-Reply-To: References: Message-ID: <692779395.14305341.1428474081599.JavaMail.zimbra@redhat.com> I think you would need to implement your own container. Looking at https://github.com/jersey/jersey/tree/master/containers there are a few existing container implementation that don't use servlet, you could probably just base it off one of these. Stuart ----- Original Message ----- > From: "Michael Hixson" > To: undertow-dev at lists.jboss.org > Sent: Wednesday, 8 April, 2015 3:12:59 PM > Subject: [undertow-dev] Jersey on Undertow, without servlets? > > Hello, > > Has anyone run a Jersey application on Undertow, *without* using servlets? > > By "using servlets" I mean wrapping an > org.glassfish.jersey.server.ResourceConfig in an > org.glassfish.jersey.servlet.ServletContainer and deploying that with > undertow-servlets. That's pretty easy to do; I don't have any > complaints about it. My question comes mostly from curiosity. > > In my application, ServletContainer is the only connection to the > servlet API. My naive view is that the application could be simpler > (in terms of the number of hidden gears turning to process requests) > and more efficient by avoiding the servlet API completely, and by only > using undertow-core. Maybe I'm wrong, or maybe there is so much work > involved that no one in their right mind would try it. > > -Michael > _______________________________________________ > 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 Apr 10 16:51:08 2015 From: michael.hixson at gmail.com (Michael Hixson) Date: Fri, 10 Apr 2015 13:51:08 -0700 Subject: [undertow-dev] Jersey on Undertow, without servlets? In-Reply-To: <692779395.14305341.1428474081599.JavaMail.zimbra@redhat.com> References: <692779395.14305341.1428474081599.JavaMail.zimbra@redhat.com> Message-ID: Thanks Stuart. If grizzly2-http is any indication, this should be possible with 500-1000 lines of code. That's not as bad as I thought it would be. -Michael On Tue, Apr 7, 2015 at 11:21 PM, Stuart Douglas wrote: > I think you would need to implement your own container. Looking at https://github.com/jersey/jersey/tree/master/containers there are a few existing container implementation that don't use servlet, you could probably just base it off one of these. > > Stuart > > ----- Original Message ----- >> From: "Michael Hixson" >> To: undertow-dev at lists.jboss.org >> Sent: Wednesday, 8 April, 2015 3:12:59 PM >> Subject: [undertow-dev] Jersey on Undertow, without servlets? >> >> Hello, >> >> Has anyone run a Jersey application on Undertow, *without* using servlets? >> >> By "using servlets" I mean wrapping an >> org.glassfish.jersey.server.ResourceConfig in an >> org.glassfish.jersey.servlet.ServletContainer and deploying that with >> undertow-servlets. That's pretty easy to do; I don't have any >> complaints about it. My question comes mostly from curiosity. >> >> In my application, ServletContainer is the only connection to the >> servlet API. My naive view is that the application could be simpler >> (in terms of the number of hidden gears turning to process requests) >> and more efficient by avoiding the servlet API completely, and by only >> using undertow-core. Maybe I'm wrong, or maybe there is so much work >> involved that no one in their right mind would try it. >> >> -Michael >> _______________________________________________ >> undertow-dev mailing list >> undertow-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/undertow-dev >> From mbarton at itrsgroup.com Tue Apr 14 12:17:32 2015 From: mbarton at itrsgroup.com (Michael Barton) Date: Tue, 14 Apr 2015 17:17:32 +0100 Subject: [undertow-dev] HTTP 2 and TLS Message-ID: Hi all, Undertow only supports HTTP2 over a secure connection at the moment. Any plans to relax this, given that the standard won't mandate it? (https://http2.github.io/faq/#does-http2-require-encryption) No worries if not, just wanted to check. Thanks, Michael ______________________________________________________________________ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com ______________________________________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20150414/fd55fe5c/attachment-0001.html From jason.greene at redhat.com Tue Apr 14 12:20:43 2015 From: jason.greene at redhat.com (Jason Greene) Date: Tue, 14 Apr 2015 11:20:43 -0500 Subject: [undertow-dev] HTTP 2 and TLS In-Reply-To: References: Message-ID: <7E25079C-2DA1-4B2B-9D30-0523F6884EC6@redhat.com> > On Apr 14, 2015, at 11:17 AM, Michael Barton wrote: > > Hi all, > > Undertow only supports HTTP2 over a secure connection at the moment. Any plans to relax this, given that the standard won?t mandate it? (https://http2.github.io/faq/#does-http2-require-encryption ) > > No worries if not, just wanted to check.= We support plaintext as well (via PRI or HTTP Upgrade), and have no intention of ever dropping that. I tested with an IE snapshot awhile back (the only browser that existed which supports it), and it worked as expected. -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20150414/75f2e8c9/attachment.html From mbarton at itrsgroup.com Tue Apr 14 12:27:11 2015 From: mbarton at itrsgroup.com (Michael Barton) Date: Tue, 14 Apr 2015 17:27:11 +0100 Subject: [undertow-dev] HTTP 2 and TLS In-Reply-To: <7E25079C-2DA1-4B2B-9D30-0523F6884EC6@redhat.com> References: <7E25079C-2DA1-4B2B-9D30-0523F6884EC6@redhat.com> Message-ID: Ah I managed to miss the Http2ClearClientProvider the first time round. My mistake, thanks for the reply. Michael From: Jason Greene [mailto:jason.greene at redhat.com] Sent: 14 April 2015 17:21 To: Michael Barton Cc: undertow-dev at lists.jboss.org Subject: Re: [undertow-dev] HTTP 2 and TLS On Apr 14, 2015, at 11:17 AM, Michael Barton > wrote: Hi all, Undertow only supports HTTP2 over a secure connection at the moment. Any plans to relax this, given that the standard won?t mandate it? (https://http2.github.io/faq/#does-http2-require-encryption) No worries if not, just wanted to check.= We support plaintext as well (via PRI or HTTP Upgrade), and have no intention of ever dropping that. I tested with an IE snapshot awhile back (the only browser that existed which supports it), and it worked as expected. -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat ______________________________________________________________________ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com ______________________________________________________________________ ______________________________________________________________________ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com ______________________________________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20150414/a9ce06cf/attachment.html From pbetkier at gmail.com Wed Apr 15 17:03:13 2015 From: pbetkier at gmail.com (Piotr Betkier) Date: Wed, 15 Apr 2015 21:03:13 +0000 Subject: [undertow-dev] HttpServletRequestImpl.getCookies() fails when a single cookie is invalid Message-ID: Hello, I have a suggestion on improving the mechanism for providing cookies in io.undertow.servlet.spec.HttpServletRequestImpl using getCookies() method. Often not all of the cookies sent by the user are under the control of the application accessing them. It may happen that one of the cookies is not a valid cookie as being validated in javax.servlet.http.Cookie constructor. Currently, in case of an invalid cookie among the cookies received in a request, getCookies() method would propagate the IllegalArgumentException thrown from Cookie constructor when instantiating a cookie with invalid name, preventing the user from accessing the rest of the cookies which were valid. My proposition is to ignore invalid cookies in getCookies() method, just logging such incident, instead of failing on them and returning all the valid cookies to the method caller. What do you think about this? If you agree then I'll be happy to provide a pull-request for that. Cheers, Piotr Betkier -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20150415/2c108851/attachment.html From sdouglas at redhat.com Thu Apr 16 19:08:28 2015 From: sdouglas at redhat.com (Stuart Douglas) Date: Thu, 16 Apr 2015 19:08:28 -0400 (EDT) Subject: [undertow-dev] HttpServletRequestImpl.getCookies() fails when a single cookie is invalid In-Reply-To: References: Message-ID: <2124873652.1756556.1429225708895.JavaMail.zimbra@redhat.com> This should already be fixed in the 1.2 branch: https://github.com/undertow-io/undertow/commit/2919457 Stuart ----- Original Message ----- > From: "Piotr Betkier" > To: undertow-dev at lists.jboss.org > Sent: Thursday, 16 April, 2015 7:03:13 AM > Subject: [undertow-dev] HttpServletRequestImpl.getCookies() fails when a single cookie is invalid > > Hello, > > I have a suggestion on improving the mechanism for providing cookies in > io.undertow.servlet.spec.HttpServletRequestImpl using getCookies() method. > > Often not all of the cookies sent by the user are under the control of the > application accessing them. It may happen that one of the cookies is not a > valid cookie as being validated in javax.servlet.http.Cookie constructor. > Currently, in case of an invalid cookie among the cookies received in a > request, getCookies() method would propagate the IllegalArgumentException > thrown from Cookie constructor when instantiating a cookie with invalid > name, preventing the user from accessing the rest of the cookies which were > valid. > > My proposition is to ignore invalid cookies in getCookies() method, just > logging such incident, instead of failing on them and returning all the > valid cookies to the method caller. > > What do you think about this? If you agree then I'll be happy to provide a > pull-request for that. > > Cheers, > Piotr Betkier > > > > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev From bill at dartalley.com Sat Apr 18 12:22:53 2015 From: bill at dartalley.com (Bill O'Neil) Date: Sat, 18 Apr 2015 12:22:53 -0400 Subject: [undertow-dev] Binding handlers to ports Message-ID: Is it possible to bind different HttpHandlers to different Listeners or should I just run two Undertow servers in the same process? Thanks, Bill -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20150418/98a38002/attachment.html From ecki at zusammenkunft.net Sat Apr 18 14:48:01 2015 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Sat, 18 Apr 2015 20:48:01 +0200 Subject: [undertow-dev] Binding handlers to ports In-Reply-To: References: Message-ID: <20150418204801.00006924.ecki@zusammenkunft.net> Am Sat, 18 Apr 2015 12:22:53 -0400 schrieb "Bill O'Neil" : > Is it possible to bind different HttpHandlers to different Listeners > or should I just run two Undertow servers in the same process? Bill, Just recently the new addHttpListener(int, String, HttpHandler) builder method was added: https://github.com/undertow-io/undertow/commit/040662f6694c1ea5e55a9764d2e752e1e94526c3 Gruss Bernd From bill at dartalley.com Sat Apr 18 17:14:22 2015 From: bill at dartalley.com (Bill O'Neil) Date: Sat, 18 Apr 2015 17:14:22 -0400 Subject: [undertow-dev] Binding handlers to ports In-Reply-To: <20150418204801.00006924.ecki@zusammenkunft.net> References: <20150418204801.00006924.ecki@zusammenkunft.net> Message-ID: perfect On Sat, Apr 18, 2015 at 2:48 PM, Bernd Eckenfels wrote: > Am Sat, 18 Apr 2015 12:22:53 -0400 > schrieb "Bill O'Neil" : > > > Is it possible to bind different HttpHandlers to different Listeners > > or should I just run two Undertow servers in the same process? > > Bill, Just recently the new addHttpListener(int, String, HttpHandler) > builder method was added: > > > https://github.com/undertow-io/undertow/commit/040662f6694c1ea5e55a9764d2e752e1e94526c3 > > Gruss > Bernd > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20150418/2e923563/attachment.html From adrian.mitev at gmail.com Wed Apr 22 14:12:31 2015 From: adrian.mitev at gmail.com (Adrian Mitev) Date: Wed, 22 Apr 2015 21:12:31 +0300 Subject: [undertow-dev] Rewrite response headers in ProxyHandler Message-ID: Hi all! I have a ProxyHandler that proxies specific path. However I need to overwrite the response headers returned by the remote path. Is it possible to do that? I explored the PredicatesHandler but couldn't find a way with it. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20150422/e4ab8da0/attachment.html From sdouglas at redhat.com Wed Apr 22 19:48:14 2015 From: sdouglas at redhat.com (Stuart Douglas) Date: Wed, 22 Apr 2015 19:48:14 -0400 (EDT) Subject: [undertow-dev] Rewrite response headers in ProxyHandler In-Reply-To: References: Message-ID: <491870037.7377316.1429746494104.JavaMail.zimbra@redhat.com> You can use io.undertow.server.HttpServerExchange#addResponseCommitListener to modify the response before it is sent to the client. Install a handler before the proxy handler that adds one of these to the exchange. Stuart ----- Original Message ----- > From: "Adrian Mitev" > To: undertow-dev at lists.jboss.org > Sent: Thursday, 23 April, 2015 2:12:31 AM > Subject: [undertow-dev] Rewrite response headers in ProxyHandler > > Hi all! I have a ProxyHandler that proxies specific path. However I need to > overwrite the response headers returned by the remote path. Is it possible > to do that? I explored the PredicatesHandler but couldn't find a way with > it. > > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev From adrian.mitev at gmail.com Thu Apr 23 00:23:44 2015 From: adrian.mitev at gmail.com (Adrian Mitev) Date: Thu, 23 Apr 2015 07:23:44 +0300 Subject: [undertow-dev] Rewrite response headers in ProxyHandler In-Reply-To: <491870037.7377316.1429746494104.JavaMail.zimbra@redhat.com> References: <491870037.7377316.1429746494104.JavaMail.zimbra@redhat.com> Message-ID: That worked. Thank you very much for the help! On Thu, Apr 23, 2015 at 2:48 AM, Stuart Douglas wrote: > You can use > io.undertow.server.HttpServerExchange#addResponseCommitListener to modify > the response before it is sent to the client. Install a handler before the > proxy handler that adds one of these to the exchange. > > Stuart > > ----- Original Message ----- > > From: "Adrian Mitev" > > To: undertow-dev at lists.jboss.org > > Sent: Thursday, 23 April, 2015 2:12:31 AM > > Subject: [undertow-dev] Rewrite response headers in ProxyHandler > > > > Hi all! I have a ProxyHandler that proxies specific path. However I need > to > > overwrite the response headers returned by the remote path. Is it > possible > > to do that? I explored the PredicatesHandler but couldn't find a way with > > it. > > > > _______________________________________________ > > 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/20150423/a5752862/attachment.html From chris.back at gmail.com Tue Apr 28 10:08:09 2015 From: chris.back at gmail.com (Chris Back) Date: Tue, 28 Apr 2015 14:08:09 +0000 Subject: [undertow-dev] Mostly IO, non-blocking workload best practice Message-ID: I am writing a server that will need to respond to lots of small web requests. Most of the requests will come with a small POST payload. Based on the contents of the payload, the server will either a) respond immediately, or b) forward the request as is to one of a pool of backend servers, waiting for a response and forwarding the response back to the client. It looks like given the existing undertow code, I have good examples of how to forward requests to the backend. What isn't as clear is how to handle the getting the POST data. Is there a way of doing that without blocking? Ideally, my handler flow would be: 1. Non-blocking request handler that makes sure all POST data is in. 2. A non-blocking handler that decisions based on content of POST data to 3a. Immediately return a response to the client (non-blocking). or 3b. Dispatch to the worker pool to forward request to backend server and await response. 90% of my requests will go through path 3a, and I'd like that to be as quick as possible. When the server decides a request should go through 3b, only then should it go to the blocking worker pool. Am I viewing this correctly? What are my options? Based on this thread http://lists.jboss.org/pipermail/undertow-dev/2015-January/001082.html it seems like an option could be to get the request channel in step 1 above? Its not clear to me how that would work. Thanks, Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20150428/0b249179/attachment.html From sdouglas at redhat.com Wed Apr 29 00:16:10 2015 From: sdouglas at redhat.com (Stuart Douglas) Date: Wed, 29 Apr 2015 00:16:10 -0400 (EDT) Subject: [undertow-dev] Mostly IO, non-blocking workload best practice In-Reply-To: References: Message-ID: <734220414.11551921.1430280970564.JavaMail.zimbra@redhat.com> The non blocking API for reading data is actually something we are looking at improving in the next version of Undertow. For now you need to use the XNIO request channel. For an example of how to use this look at io.undertow.util.StringReadChannelListener (you can actually just subclass this class). Basically the most efficient way to use the API is: - Get a pooled buffer from the connections buffer pool - keep calling StreamSinkChannel.read() to read the data - If read returns 0 register a read listener and then call resumeReads() and return. Your listener will be notified when more data is available. - When read returns -1 you are done Stuart ----- Original Message ----- > From: "Chris Back" > To: undertow-dev at lists.jboss.org > Sent: Wednesday, 29 April, 2015 12:08:09 AM > Subject: [undertow-dev] Mostly IO, non-blocking workload best practice > > I am writing a server that will need to respond to lots of small web > requests. Most of the requests will come with a small POST payload. Based on > the contents of the payload, the server will either a) respond immediately, > or b) forward the request as is to one of a pool of backend servers, waiting > for a response and forwarding the response back to the client. > > It looks like given the existing undertow code, I have good examples of how > to forward requests to the backend. What isn't as clear is how to handle the > getting the POST data. Is there a way of doing that without blocking? > > Ideally, my handler flow would be: > > 1. Non-blocking request handler that makes sure all POST data is in. > 2. A non-blocking handler that decisions based on content of POST data to > 3a. Immediately return a response to the client (non-blocking). > or > 3b. Dispatch to the worker pool to forward request to backend server and > await response. > > 90% of my requests will go through path 3a, and I'd like that to be as quick > as possible. When the server decides a request should go through 3b, only > then should it go to the blocking worker pool. > > Am I viewing this correctly? What are my options? Based on this thread > http://lists.jboss.org/pipermail/undertow-dev/2015-January/001082.html > it seems like an option could be to get the request channel in step 1 above? > Its not clear to me how that would work. > > Thanks, > Chris > > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev