On Fri, Apr 17, 2020 at 11:51 AM Michael Osipov <micha...@apache.org> wrote:
> Am 2020-04-15 um 23:05 schrieb r...@apache.org: > > This is an automated email from the ASF dual-hosted git repository. > > > > remm pushed a commit to branch master > > in repository https://gitbox.apache.org/repos/asf/tomcat.git > > > > > > The following commit(s) were added to refs/heads/master by this push: > > new 92923fe Proposed Connector API and XML refactoring > > 92923fe is described below > > > > commit 92923febadb5d7901747530272302dc3da6311c2 > > Author: remm <r...@apache.org> > > AuthorDate: Wed Apr 15 23:04:47 2020 +0200 > > > > Proposed Connector API and XML refactoring > > > > See > https://cwiki.apache.org/confluence/display/TOMCAT/Connector+API+refactoring > > To add some fuel to the fire: This looks like a start. > > I always liked the approach HTTPd took, addd a Listen <IP>:<Port> + > VirtualHost <IP>:<Port>. > > Even in the new proposal you have redundancies: scheme, secure, > SSLEnabled. Why can't the endpoint or rather a class using this endpoint > There's actually no duplication with these attributes. SSLEnabled: actually use TLS on the connector secure: Tomcat considers the data received from the client has been kept secure end to end scheme: the protocol scheme to be used on the URL (http or https basically) > decide what protocol it speaks when TLS config is nested? > What I never understood with Tomcat why Host configs applies to *all* > connectors. I cannot freely apply hosts to IP/port combos and selecting > on a host level what type of protocol I want to have. > The refactoring reflects the object structure, because that's how the digester works. There's a slight change to the Connector lifecycle. That's it for this one, the object structure is actually unchanged. I made progress and I think the old XML can be supported. For embedded, old code can be mostly supported too. It would break if trying to manipulate too directly the protocol handler, but normally embedded code uses new Connector(protocol) and sets properties there, so it would work. It would mean keeping the messy code in 10.0, actually adding new code in parallel, but a large cleanup could then occur in 10.1. > > My understanding is: > > * An endpoint impl is a pure socket which can run any protocol > * A protocol is uses an endpoint > * A Host declares to use a specific endpoint/protocol > * Either proto or host declare TLS > Which such decoupling one could even introduce AJPS. > > But a guess this is a lot of work to do. > Indeed that's not what we do. I guess everyone involved with Catalina was skeptical and considered the current nested container structure was flexible enough. Rémy > > M >
