You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Eddie Ruvinsky <ru...@yahoo.com> on 2002/08/06 21:04:12 UTC

Problem when Apache does SSL with a JK 2 Connector (Tomcat 4.1) backend?

Hi all,

I had a question about the intended behavior for
servlets when a front-end web server proxies Tomcat
traffic while performing SSL processing, as intended
for the JK 2 Connector supplied with Tomcat 4.1.  I'm
wondering if the web server plugin will downgrade the
inbound HTTPS security to HTTP when it reaches Tomcat
on the backend?  If so, this would result in the
getScheme() and isSecure() ServletRequest calls to
return "http" and "false," respectively.  Is this the
intended/proper behavior, or should Tomcat be
"tricked" into stating "https"/"true" for the above
calls instead when the inbound request uses HTTPS? 
Otherwise, can webapps that expect HTTPS requests
break with this kind of configuration?  I'm not sure
if this is a problem.

Thanks,
Eddie

__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: Problem when Apache does SSL with a JK 2 Connector (Tomcat 4.1) backend?

Posted by Bojan Smojver <bo...@rexursive.com>.
On Wed, 2002-08-07 at 09:17, Eddie Ruvinsky wrote:

> What does this mean exactly?  My question is that when
> Apache is configured to process SSL requests along
> with a Tomcat worker, and an HTTPS request for a
> servlet comes in, does it forward the request as HTTP
> (post-SSL work) to the Tomcat worker?

Yes, that's my understanding.

> If so, does it
> also [need to] tell the Tomcat worker that the
> original request used HTTPS so that Tomcat can
> properly set the getScheme() and isSecure()
> ServletRequest methods for that request?

Yes, it does that as well. You can also get certificates and other SSL
information.

Bojan


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: Problem when Apache does SSL with a JK 2 Connector (Tomcat 4.1) backend?

Posted by Eddie Ruvinsky <ru...@yahoo.com>.
Hi Bojan,

Thanks for pointing me to the JK documentation.  I
browsed through it along with the Tomcat Workers
HOW-TO doc, and found one relevant snippet in the
section entitled "ajp13 Workers properties":

"ajpv13 has special treatment for SSL information so
that the container can implement SSL related methods
such as isSecure()."

What does this mean exactly?  My question is that when
Apache is configured to process SSL requests along
with a Tomcat worker, and an HTTPS request for a
servlet comes in, does it forward the request as HTTP
(post-SSL work) to the Tomcat worker?  If so, does it
also [need to] tell the Tomcat worker that the
original request used HTTPS so that Tomcat can
properly set the getScheme() and isSecure()
ServletRequest methods for that request?

Thanks,
Eddie

--- Bojan Smojver <bo...@rexursive.com> wrote:
> Not 100% sure I understand your question, but as far
> as I know mod_jk
> was written to support connections over SSL. Most
> information is in
> mod_jk documentation:
> 
>
http://jakarta.apache.org/tomcat/tomcat-3.3-doc/mod_jk-howto.html
> 
> Bojan
> 
> On Wed, 2002-08-07 at 05:04, Eddie Ruvinsky wrote:
> > Hi all,
> > 
> > I had a question about the intended behavior for
> > servlets when a front-end web server proxies
> Tomcat
> > traffic while performing SSL processing, as
> intended
> > for the JK 2 Connector supplied with Tomcat 4.1. 
> I'm
> > wondering if the web server plugin will downgrade
> the
> > inbound HTTPS security to HTTP when it reaches
> Tomcat
> > on the backend?  If so, this would result in the
> > getScheme() and isSecure() ServletRequest calls to
> > return "http" and "false," respectively.  Is this
> the
> > intended/proper behavior, or should Tomcat be
> > "tricked" into stating "https"/"true" for the
> above
> > calls instead when the inbound request uses HTTPS?
> 
> > Otherwise, can webapps that expect HTTPS requests
> > break with this kind of configuration?  I'm not
> sure
> > if this is a problem.
> > 
> > Thanks,
> > Eddie

__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: Problem when Apache does SSL with a JK 2 Connector (Tomcat 4.1) backend?

Posted by Bojan Smojver <bo...@rexursive.com>.
Not 100% sure I understand your question, but as far as I know mod_jk
was written to support connections over SSL. Most information is in
mod_jk documentation:

http://jakarta.apache.org/tomcat/tomcat-3.3-doc/mod_jk-howto.html

Bojan

On Wed, 2002-08-07 at 05:04, Eddie Ruvinsky wrote:
> Hi all,
> 
> I had a question about the intended behavior for
> servlets when a front-end web server proxies Tomcat
> traffic while performing SSL processing, as intended
> for the JK 2 Connector supplied with Tomcat 4.1.  I'm
> wondering if the web server plugin will downgrade the
> inbound HTTPS security to HTTP when it reaches Tomcat
> on the backend?  If so, this would result in the
> getScheme() and isSecure() ServletRequest calls to
> return "http" and "false," respectively.  Is this the
> intended/proper behavior, or should Tomcat be
> "tricked" into stating "https"/"true" for the above
> calls instead when the inbound request uses HTTPS? 
> Otherwise, can webapps that expect HTTPS requests
> break with this kind of configuration?  I'm not sure
> if this is a problem.
> 
> Thanks,
> Eddie
> 
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Health - Feel better, live better
> http://health.yahoo.com
> 
> --
> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
> 



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>