Mostly IO, non-blocking workload best practice
by Chris Back
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
5 years, 7 months
Rewrite response headers in ProxyHandler
by Adrian Mitev
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.
6 years
Binding handlers to ports
by 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?
Thanks,
Bill
6 years
HttpServletRequestImpl.getCookies() fails when a single cookie is invalid
by Piotr Betkier
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
6 years
HTTP 2 and TLS
by Michael Barton
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
______________________________________________________________________
6 years
Jersey on Undertow, without servlets?
by Michael Hixson
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
6 years
Using JavaScript with Undertow
by Stuart Douglas
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#...
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
6 years
Proxy handler clobbering X-Forwarded-Proto header
by Shannon Lloyd
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
6 years
