tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Konstantin Kolinko <>
Subject Re: transport CONFIDENTIAL based on remote ip/host filter?
Date Mon, 04 Jun 2012 20:35:20 GMT
2012/6/4 Timothy J Schumacher <>:
> On 5/31/2012 1:30 PM, Konstantin Kolinko wrote:
>> 2012/5/31 Timothy J Schumacher<>:
>>> Hi,
>>> We are using Apache Tomcat 6.0.35
>>> with
>>> # java -version
>>> java version "1.6.0_30"
>>> Java(TM) SE Runtime Environment (build 1.6.0_30-b12)
>>> Java HotSpot(TM) Client VM (build 20.5-b03, mixed mode, sharing)
>>> in redhat linux.
>>> I am wondering if there is a way to use transport CONFIDENTIAL for all
>>> hosts
>>> that are not localhost?  I am guessing the servlet spec does not allow
>>> this,
>>> it seems to be all or none in the web.xml config.  Perhaps there is a way
>>> configure transport NONE in web.xml and then manually configure a
>>> valve/filter in context.xml that would enforce CONFIDENTIAL to all remote
>>> hosts but let localhost pass without redirects to port 443?
>>> Any ideas are appreciated!
>> <Connector ... address="" secure="true" />
>> It will
>> 1. Listen on localhost only.
>> 2. Be treated by Tomcat as if it were an HTTPS connection.
> Hi Konstantine, thanks this works!  I have one more question.  I assume that
> setting secure="true" means that the cookie JSESSIONID has "Secure" set.
>  This causes my browser (an old version of FF) to not send the cookie which
> I assume is due to the fact that the communication is over a plain http
> connection.  Since we have not diligently coded encodeURLs everywhere the
> application loses the session on occasion.  Is there a way to tell the
> component that sets the cookie to not set "Secure" only for this particular
> connector?

Why do you want to avoid HTTPS so much?

The recipe that I gave you is usually used in the scenario when Tomcat
is behind a proxy that uses HTTP protocol (instead of AJP one).

That is: a proxy (a.g. Apache HTTPD) does HTTPS, decodes the
connection and forwards request through HTTP.

The "secure" attribute that I mentioned is similar to "proxyHost" and
"proxyPort" connector attributes. It is not there to fool the picture,
but to provide some information to Tomcat that it does not know by

In that scenario the browser will not have any problems with secure
cookies, because from its side it sees the site through HTTPS.

I think that in your case you can turn off cookies support in browser
and to rely on sessionid being encoded in URLs.  URLs are not a
subject to "secure cookies" limitation.

I do not remember any option to turn off "secure" bit in cookies. If
there were one, I think it would be on Context.  If you want to
implement a trick, I think a Valve can affect create session cookie or
"set-cookie" header, clearing the flag.
You can look into the code for more details. If you want to try
running Tomcat with a debugger, there are tips in the FAQ, or ask

Best regards,
Konstantin Kolinko

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message