[
https://issues.apache.org/jira/browse/HTTPCORE-766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17847251#comment-17847251
]
Oleg Kalnichevski commented on HTTPCORE-766:
--------------------------------------------
[~erik.wramner] One way to solve the problem once and for all is to drop or
rewrite the authority on all incoming requests
{code:java}
public class ClassicServerBootstrapTest {
private static final Timeout TIMEOUT = Timeout.ofMinutes(1);
@RegisterExtension
final HttpServerResource serverResource;
@RegisterExtension
final HttpRequesterResource clientResource;
public ClassicServerBootstrapTest() {
serverResource = new HttpServerResource(URIScheme.HTTP, bootstrap ->
bootstrap
.setSocketConfig(SocketConfig.custom()
.setSoTimeout(TIMEOUT)
.build())
.setHttpProcessor(HttpProcessors.customServer("test-server")
.add((HttpRequestInterceptor) (request, entity,
context) -> {
request.setAuthority(null);
})
.build()
)
.register("*", new EchoHandler()));
clientResource = new HttpRequesterResource(bootstrap -> bootstrap
.setSocketConfig(SocketConfig.custom()
.setSoTimeout(TIMEOUT)
.build()));
}
@Test
public void testStuff() throws Exception {
final HttpServer server = serverResource.start();
final HttpRequester requester = clientResource.start();
server.start();
final HttpHost target = new HttpHost("http", "localhost",
server.getLocalPort());
final HttpCoreContext context = HttpCoreContext.create();
final ClassicHttpRequest request =
ClassicRequestBuilder.get("http://somewhere.in.pampa/";)
.build();
try (final ClassicHttpResponse response = requester.execute(target,
request, TIMEOUT, context)) {
assertThat(response.getCode(),
CoreMatchers.equalTo(HttpStatus.SC_OK));
}
}
}
{code}
I will see if there is a reasonable way of plugging a custom replacement for
`RequestHandlerRegistry` but generally I do not thin that opening up
`ServerBootstrap` is a good idea.
Oleg
> 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.2.4, 5.3-alpha1, 5.3-alpha2
> Reporter: Erik Wramner
> Priority: Minor
> Labels: easyfix
> Original Estimate: 4h
> Remaining Estimate: 4h
>
> 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: [email protected]
For additional commands, e-mail: [email protected]
