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
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).
3b. Dispatch to the worker pool to forward request to backend server and
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
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.
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
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
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.
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.
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
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.
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.
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:
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.
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"
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