Filip Hanik - Dev Lists wrote:
Mladen Turk wrote:
Filip Hanik - Dev Lists wrote:
The scenario we are trying to achieve is this:
<Connector port="8443" scheme="https" secure="true"
SSLEnabled="false"/>
How will in that case behave:
Let me see if I can explain
<Connector port="8443" scheme="https" secure="false"
SSLEnabled="false"/>
a) The socket is doing HTTP over TCP, no SSL
b) request.getScheme returns https, so if the webapplication uses this
to create URLs, they will be prefixed with https
c) if there is a transport user constraints, ie the page is only
allowed to be server CONFIDIENTIAL, tomcat will throw a 403 error
<Connector port="8443" scheme="https" secure="true" SSLEnabled="false"/>
a) The socket is doing HTTP over TCP, no SSL
b) request.getScheme returns https, so if the webapplication uses this
to create URLs, they will be prefixed with https
c) Tomcat handles the transport-guarantee scenario correctly and
allows the request into the application
<Connector port="8443" scheme="https" secure="false" SSLEnabled="true"/>
a) The socket is doing HTTPS over TCP, ie HTTP over SSL over TCP
b) request.getScheme returns https, so if the webapplication uses this
to create URLs, they will be prefixed with https
c) if there is a transport user constraints, ie the page is only
allowed to be server CONFIDIENTIAL, tomcat will throw a 403 error
<Connector port="8443" scheme="https" secure="true" SSLEnabled="true"/>
a) The socket is doing HTTPS over TCP, ie HTTP over SSL over TCP
b) request.getScheme returns https, so if the webapplication uses this
to create URLs, they will be prefixed with https
c) Tomcat handles the transport-guarantee scenario correctly and
allows the request into the application
Could you put this somewhere in the documentation?
may we should explain what happends when scheme and/or secure are
missing, or just assume that the default are scheme="http" and
secure="false".
Cheers
Jean-Frederic
What you are trying to do is correlate the two values, and you get
locked into the correlation.
For example
1. the assumption that secure=true -> scheme=https is false, there are
other secure protocol than HTTPS
2. the assumption that scheme=https -> secure=true could be valid, but
again is not guaranteed and therefor false, just because the values
don't correlate, the scheme value is only used to create urls, not to
determine if the transport protocol was secure
3. the assumption that secure=false -> scheme=http is also wrong,
scheme could be FTP for all we know, scheme is only used to create
urls, nothing else
4. the assumption that scheme=http -> secure=false is wrong, because
the value scheme doesn't tell you anything about the actual transport,
it only gives you the value to create urls with, so again, this value
cant determin if a request is secure or not.
So when looking at this config, try to open yourself to the
possibility that "secure" has nothing to do with "scheme" and the
other way around.
so that is what we have done here,made sure that is clear,
SSLEnabled=true/false - determines if the SSL handshake/enc/dec is
done on the connector itself
scheme = what value to send to the web application
secure = what value to send to the web application
if secure=true -> scheme=https -> SSL on the socket, we would never be
able to achieve the use case in my previous email.
Filip
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
