[ 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: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org