[PJUG Javamail] Need some advice from a Tomcat expert

Tue Jun 12 00:54:07 UTC 2007

Hi Rob,

If I have read this right, when the user enters http://... you want to
redirect the user to https://...  

Perhaps doing the redirect on the server is not the only or even the
best approach.  I believe it's possible for the server to respond by
sending a redirect to the browser and have the browser respond by
redirecting to a new url.  In your case, the redirect url would be to
your https protected site. Try searching Google for the redirect meta
tag.  

Regards,
Steve Hall
Tektronix

________________________________

	From: javamail-bounces at pjug.org
[mailto:javamail-bounces at pjug.org] On Behalf Of Ken Paulsen
	Sent: Monday, June 11, 2007 5:07 PM
	To: Rob Tanner
	Cc: pjug
	Subject: Re: [PJUG Javamail] Need some advice from a Tomcat
expert

	Hi Rob,

	I don't know where it's coming from.  Probably part of tomcat's
standard response for a redirect.  I don't think the Dec 1969 expires
header is the problem.  I think that is just ensuring it won't be cached
by the browser.

	Do you see the problem when you send a single request to the
server?  Or only when you have a frameset which sends multiple requests?

	Ken

	Rob Tanner wrote: 

		Ken,

		Better than that, I have WireShark (aka ethereal) and so
I took a look.  It's almost as if the browser is arguing with the
server.  Just for grins, I tried a telnet to port 80 on the server and
also to another server we have running that does the redirect in a more
timely fashion to give myself something to compare against.  Both
servers respond immediately with the redirect but my server also
includes an Expires: header dated in the past (31 December 1969 to be
exact -- "The Epoch" in PST):

			[rtanner at beowulf ~]$ telnet tomcat-socrates 80
			Trying 10.171.255.103...
			Connected to tomcat-socrates.linfield.edu
(10.171.255.103).
			Escape character is '^]'.
			GET /mailtools/aliases/groupAliasManager
HTTP/1.0

			HTTP/1.1 302 Moved Temporarily
			Server: Apache-Coyote/1.1
			Pragma: No-cache
			Cache-Control: no-cache
			Expires: Wed, 31 Dec 1969 16:00:00 PST
			Location:
https://tomcat-socrates.linfield.edu/mailtools/aliases/groupAliasManager
			Content-Length: 0
			Date: Mon, 11 Jun 2007 22:23:33 GMT
			Connection: close

			Connection closed by foreign host.

		I talked to our webmaster since he's the closest thing
we have to a browser expert, and he suggests that the expires header
could be the problem.  But I have no idea where it's coming from and so
I have no idea how to turn it off.

		If you have a clue, please share the wealth.

		Thanks,
		Rob

		Ken Paulsen said the following on 06/11/2007 11:24 AM: 

			Rob Tanner wrote: 

				Ken,

				I'm looking into possible
locking/synchronization issues.  Thanks for the suggestion.

				On the other issue, the extreme length
of time (30 seconds or more) for the https redirect to work still
baffles me, and I don't think it's at all related to any possible
locking or synchronization issue.

			I was guessing that the 30 seconds was related
to browser timeout before it re-sends the request.  I was guessing that
the server never returned a response to the original request.  You could
write a simple Java program that simulates your browser opening URL
connections to test this.

				The portion of web.xml specifying the
security-constraint is correct as far as I can tell (see below), and
I've used the same constraint before. 

				  <security-constraint>
				    <web-resource-collection>
				      <web-resource-name>Group Aliases
Manager</web-resource-name>
				      <url-pattern>/*</url-pattern>
				    </web-resource-collection>
				    <user-data-constraint>
				      <description>Constrain Group Alias
Manager to use HTTPS</description>

<transport-guarantee>CONFIDENTIAL</transport-guarantee>
				    </user-data-constraint>
				  </security-constraint>

				What I'm wondering is:  This instance of
Tomcat is using a virtual address (i.e.; one of the three secondary
addresses defined on eth0) and so both the port 80 and port 443
connectors have an "address=" parameter specified in the connector
definition.  If the browser attempts to connect to the port 443
connector (using the https scheme) I get an immediate response.  It is
only when the browser initially goes to port 80 (http scheme) and the
constraint forces a redirect to 443 that I see this monstrously long
delay.  I've included below both connector definitions.  Could there be
something in the definitions that is creating the long delay on
redirect?

				    <Connector port="80"
address="10.171.255.103" 
				        maxHttpHeaderSize="8192"
enableLookups="false" tcpNoDelay="true"
				        maxThreads="150"
minSpareThreads="25" maxSpareThreads="75"
				        acceptCount="100"
connectionTimeout="20000" disableUploadTimeout="true" 
				        scheme="http" redirectPort="443"
/> 

				    <Connector port="443"
address="10.171.255.103" 
				        maxHttpHeaderSize="8192"
enableLookups="false" tcpNoDelay="true"
				        maxThreads="150"
minSpareThreads="25" maxSpareThreads="75"
				        acceptCount="100"
connectionTimeout="20000" disableUploadTimeout="true" 

keystoreFile="/usr/java/keystore" keystorePass="secret"
				        scheme="https" secure="true"
clientAuth="false" sslProtocol="TLS" />

			I don't know. :)  You might find the same
problems in GlassFish... if so, Jan Luehe or Jeanfrancois will be able
to tell you answer to your problem.  They're usually very fast in their
responses (usually same day).  A question to dev at glassfish.dev.java.net
will get their attention... or file a bug against GF.

			Good luck!

			Ken

				Thanks,
				Rob

				Ken Paulsen said the following on
06/08/2007 01:46 PM: 

				Hi Rob,

				Unfortunately I don't have the answer
for you... although due to the nature of framesets making concurrent
requests, I suspect it has something to do with a locking /
synchronization issue where it doesn't get freed up and times out.  Or
something along those lines.  Just a guess.

				Your post did remind me of a recent blog
that I found via TSS
(http://www.theserverside.com/news/thread.tss?thread_id=45222), here's
the direct link:

http://weblogs.java.net/blog/sdo/archive/2007/05/how_to_test_con.html

				Good read (w/ the code for the utility)
for performance testing.

				Ken

________________________________

_______________________________________________
				Web Site - http://www.pjug.org/
				Javamail mailing list
				Javamail at pjug.org

http://www.pjug.org/mailman/listinfo/javamail

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://javac.com/pipermail/javamail/attachments/20070611/57e7174f/attachment-0002.html>