Erik Wramner created HTTPCORE-766:
-------------------------------------
Summary: Serve same content regardless of http authority
(RequestHandlerRegistry)
Key: HTTPCORE-766
URL: https://issues.apache.org/jira/browse/HTTPCORE-766
Project: HttpComponents HttpCore
Issue Type: Improvement
Components: HttpCore
Affects Versions: 5.3-alpha2, 5.3-alpha1, 5.2.4
Reporter: Erik Wramner
I need to serve the same content on all interfaces and I don't know the IP
addresses and host names in advance. Think of it as a classic HTTP server
without virtual host support: all requests get to the same set of handlers.
Unfortunately, ServerBootstrap installs RequestHandlerRegistry, which uses one
primary LookupRegistry for a canonical host name and localhost and a map with
other registries keyed by name. If a client connects with an unknown name, no
handler is found and the server responds with 421.
There are several possible solutions here:
# Modify RequestHandlerRegistry to use the primary registry if no other
registry is found. As I recall, that was what Apache did by default. Then it is
still possible to register new rules for virtual hosts, but the primary is
fallback when no name matches. This could also be configurable on/off.
# Add new PrimaryOnlyRequestHandlerRegistry that has no support for virtual
hosts and always uses the primary.
# Don't fix this in the code, but make it easier for me to fix by making
getPatternMatcher protected instead of private.
In the two last cases we run into another problem: ServerBootstrap has private
members without getters, final methods that cannot be overridden and creates
RequestHandlerRegistry with new in a long create method. This is the problem
that was solved in HTTPCORE-570 for another class. It makes it hard to extend
the class, it must basically be rewritten.
I would propose opening up ServerBootstrap with getters or by making the fields
protected. I would also like to extract the RequestHandlerRegistry creation to
a protected method that can be overridden. Alternatively, we can add a setter
and allow the calling code to prepare an instance outside of the builder.
I would be happy to make a pull request for these changes on Github. If so,
what direction would you like to take?
I can code around this by copying both classes with my changes, but that feels
really dirty.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
