Hi, I'm looking for some examples of locking down access to certain
directories, similar to how IIS has "hidden segments". For instance, I'd
like all URLs starting with /CFIDE to be blocked, or perhaps only access to
a certain range of IPs
I swear I had looked at some examples of this about a year ago, but after
quite a lot of Googling today I was coming up empty handed. I found some
basic information on the access control handlers, but couldn't find a
single example of using them.
*Ortus Solutions, Corp *
ColdBox Platform: http://www.coldbox.org
A project we're working on has recently ran into a need to access the HTTP
request headers in order they were received. This does not seem currently
possible as HeaderMap is just a hash table.
One way I see to get this functionality would be to make HeaderMap
non-final and provide a mechanism for configuring the class used for
request headers, but I don't particularly like this as the HeaderMap API is
fairly wide and some of the methods are semantically tricky for this
Obviously we'd prefer a solution where the modifications to Undertow itself
are acceptable for upstreaming so we don't have to maintain a custom fork
of it. Any suggestions would be appreciated.
I'm experiencing an Undertow performance issue I fail to understand. I
am able to reproduce the issue with the code linked bellow. The problem
is that on Red Hat (and not Windows) I'm unable to concurrently process
more than 4 overlapping requests even with 8 configured IO Threads.
For example, if I run the following program (1 file, 55 lines):
... on Red Hat and then send requests to the server using Apache
> ab -n 1000 -c 8 localhost:8080/
I see the following output from the Undertow process:
Server started on port 8080
I believe this demonstrates that only 4 requests are ever processed in
parallel. I would expect 8. In fact, when I run the same experiment on
Windows I see the expected output of
Server started on port 8080
Any thoughts as to what might explain this behavior?
Are commas allowed as a separator of multiple cookies in a cookie header?
I am running an application in wildfly-11.0.0.Final and another application is making a request with two cookies, JSESSIONID and JSESSIONIDSSO. It is sending these as
which then seems to be parsed into a single cookie
which of course does not work for the authentication so the request fails. This seems to be a failure in parsing the original cookie string. There is a bit of confusion in this area in the RFCs as the earlier ones allowed comma as a separator but the most recent, RFC-6265, does not. Undertow should probably allow a comma separator for backward compatibility with older implementations.
The full dump from the undertow request dumper is
18:33:29,249 INFO [io.undertow.request.dump] (Unknown)
cookie=JSESSIONIDSSO=null; domain=null; path=/
header=Cache-Control=no-cache, no-store, must-revalidate
header=Set-Cookie=JSESSIONIDSSO=""; path=/; Max-Age=0; Expires=Thu, 01-Jan-1970 00:00:00 GMT
header=Date=Fri, 03 Aug 2018 08:33:29 GMT
header=WWW-Authenticate=Basic realm="REST API authentication module"