Am 2020-04-17 um 14:02 schrieb Rémy Maucherat:
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
Isn't that obvious a soon as I provide
sslImplementationName/<SSLHostConfig />?
secure: Tomcat considers the data received from the client has been kept
secure end to end
Is that so? How can I guarantee -- as a client -- that a middle box
(forwarding proxy) enforces secure comminication?
Docs say this:
Set this attribute to true if you wish to have calls to request.isSecure() to
return true for requests received by this Connector.
scheme: the protocol scheme to be used on the URL (http or https basically)
This is determined/implied by the protocol handler you use. Saying:
<Connector scheme="https"
and
<UpgradeProtocol className="org.apache.coyote.http2.Http2Protocol" />
looks just wrong because with ALPN it won't be https, but h2. No TLS is
used, you still can try h2c directly if you know upfront.
From an admin point of view, this is messy and confusing. Always
consider that admins aren't devs. Our admins keeps asking me things
about Tomcat config options because they are beyond his understanding as
an admin.
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.
Having said that, I don't think it is flexible enough. It is flexible at
places not strictly requiring it while in others limited.
M
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
