Re: [TC4] multiple certificates

2000-11-21 Thread Aaron Knauf

I believe that the different port idea is correct (for any web server - not just tomcat). 

Another point to consider is that if tomcat is used in conjunction with a web server (such as apache or IIS), the web server does all of the SSL stuff for the communication with the browser, so you are stuck with web server limitations that are out of tomcat's control.




Aaron Knauf
Systems Integrator
Genie Systems Ltd
Auckland, New Zealand
Ph. +64-9-573 3310 x812
email: [EMAIL PROTECTED]
http://www.geniesystems.com







Warner Onstine [EMAIL PROTECTED]
22/11/2000 18:36
Please respond to tomcat-dev


To:[EMAIL PROTECTED]
cc:
Subject:Re: [TC4] multiple certificates



- Original Message -
From: Craig R. McClanahan [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, November 21, 2000 7:43 PM
Subject: Re: [TC4] multiple certificates


 Warner Onstine wrote:

  Hi all,
  It's been a while since I looked at the SSL stuff and I just received a
  request which I'm not sure how it would be handled in TC4. Would it be
  possible to handle multiple certificates for SSL per servlet? If this
needs
  further clarification let me know.
 

 I guess I don't quite get what you are after.

 Are you talking about a certificate chain that authenticates an individual
 user? If so, that is already supported -- the request attribute that you
get is
 an array of certificate objects, with the first one being the certificate
of the
 client principal, and the subsequent ones being the certificates of the
 certificate authorities vouching for the previous certificate in the
chain.

Sure, what we're working with is possibly using different server
certificates for different servlets, is this at all possible? From what I
can tell right now, no.

Basically what I see right now is if we turn on ssl support it uses the
certificate that you specify for each connection from the
SSLServerSocketFactory. The only way I can see doing this is to specify a
different port for different certificates, correct?

 If that's not what you are after, could you please explain further?


 Craig

Thanks,
-warner




Re: F....

2000-12-21 Thread Aaron Knauf

I have been following this insane tomcat 4 vs tomcat 3 debate with increasing amazement. I cannot understand why this has become such a big issue. Attempting to tell an open source developer what to write is pretty much counter to ESR's cited prime motivation for open source development - scratching a personal itch! If Costin (bless his soul) wants to make TC3 a better product, then he has my own profound thanks!

As a user of tomcat (I use tomcat every day as part of my job) am very keen to see tomcat 3.x development continue as long as tomcat 4 falls short of release quality. Until IIS integration and SSL client certificate support are considered release quality in tomcat 4, I am keen to see them developed on tomcat 3.

In fact, I believe that the time to abandon tomcat 3 development will come at around the point that new features are able to reach release quality as fast on tomcat 4 as on tomcat 3. The technology used in tomcat 3 is perfectly current. Forcing people into participating in development of a bleeding edge product in order to add features to tomcat seems pretty mercurial.

Tomcat 3 is just becoming a premium quality product. There are two or three features still to be added to completely satisfy my own requirements of a servlet container. If we abandon development now in favour tomcat 4, tomcat will remain a bleeding edge product and may never reach the mainstream release quality that I for one would like to see.

What I suggest is this:

Whoever wants to develop on tomcat 4 does so.

Whoever wants to develop on tomcat 3 does so.

Versions are managed in a similar manner to the linux development/stable trees, with code from TC4 merged back into TC3 whenever the TC3 guys feels that this enhances the product. (And no complaining about the tomcat 3 guys 'copying' the TC4 guys - that is kind of the point of open source!)

Cheers and Merry Christmas!

---
Aaron Knauf
Implementation Consultant
Genie Systems Ltd
Auckland, New Zealand
Ph. +64-9-573 3310 x812, email: [EMAIL PROTECTED]
http://www.geniesystems.com







Jon Stevens [EMAIL PROTECTED]
22/12/2000 11:26
Please respond to tomcat-dev


To:[EMAIL PROTECTED]
cc:
Subject:Re: F


on 12/21/2000 2:18 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:

 Tomcat3.2 is a big step forward versus Tomcat3.1 - but it still have many
 issues - take a look at the ContextManager in 3.3, compare it with 3.2 -
 there are still many undefined behaviors, even code from 3.0.

Tomcat 3.2 has *only* happened because Tomcat 4.0 wasn't ready.

Remember the history of Tomcat 4.0 and the fact that if Sun didn't donate a
bunch of cruft software, we would have spent the time working on JServ 2.0
which is now what Tomcat 4.0 is. The fact of the matter is that because we
had to deal with 3.x and support improving it that delayed the development
of 4.0 to not being ready until now.

It is this duplication of effort that needs to stop. We need to quit sitting
back and trying to support something that should have been dead long ago.

-jon




Re: An important question

2000-12-27 Thread Aaron Knauf

Please don't start that again.

---
Aaron Knauf
Implementation Consultant
Genie Systems Ltd
Auckland, New Zealand
Ph. +64-9-573 3310 x812, email: [EMAIL PROTECTED]
http://www.geniesystems.com







Jon Stevens [EMAIL PROTECTED]
28/12/2000 08:27
Please respond to tomcat-dev


To:[EMAIL PROTECTED]
cc:
Subject:Re: An important question


on 12/27/2000 11:20 AM, David Lavigne [EMAIL PROTECTED] wrote:

 How can the future of Tomcat be 4.0 while it does not have connectors to
 the web servers that 3.x have? I believe that it will be the future as
 soon as these exist, otherwise there is no point in making Tomcat a
 separate product from Apache httpd when that is the only webserver Catalina
 supports.

Maybe if we hadn't been focusing so hard on 3.x, then 4.0 would have had
those features. *That* is the point.

-jon




IIS/ISAPI connection to tomcat

2001-02-06 Thread Aaron Knauf

I have a little problem with the isapi_redirect.dll connector to Tomcat. There seems to be a buffering problem with sending the response back to the browser.

My symptoms are as follows:
I access a JSP file running in Tomcat via the IIS and isapi_redirect.dll and I receive a page back that has random fragments of HTML repeated several times.

I am happy with tracking down the problem and fixing it myself, if necessary, but before I do that I would like to ensure that I am not wasting my time.

I am using tomcat 3.1-FINAL and a version of isapi_redirect.dll of about the same vintage. I cannot upgrade this server to Tomcat 3.2, as the case sensitivity breaks existing code (not written by me - bloody IIS).

Has anyone seen/fixed this problem before?
I see that there have been some changes to the source files since then. Should I be using a later version of the redirector, or is the new code specific to a later tomcat version? (I don't want to be fixing old code.)

Thanks in advance for any help/advice that you can offer.

---
Aaron Knauf
Implementation Consultant
Genie Systems Ltd
Auckland, New Zealand
Ph. +64-9-573 3310 x812, email: [EMAIL PROTECTED]
http://www.geniesystems.com


Re: [ANNOUNCEMENT] Tomcat 4.0-beta-7 Released

2001-09-11 Thread Aaron Knauf

I am submitting a bug report here, as jakarta.apache.org is reporting 
connection refused.

A bug in Tomcat 4.0-beta-7:

DTD URL for the webapp 2.3 dtd is now incorrect. 
http://java.sun.com/j2ee/dtds/web-app_2_3.dtd;  is a file containing the 
following message:
---
The file named http://java.sun.com/j2ee/dtds/web-app_2_3.dtd
has been renamed to http://java.sun.com/dtd/web-app_2_3.dtd
in the most current version of the specification.
Please update your application to use the new name.
---


One more note:  Now that the XML parser used to parse the web.xml and tld 
files is (correctly) strict about element order, it would be handy if the 
filename were displayed along with the parser error messages.  (So I can 
find all the error in my incorrectly ordered deployment descriptors and 
tld files!)

Cheers

---
Aaron Knauf
Software Developer
Genie Systems Ltd
Auckland, New Zealand
Ph. +64-9-573 3310 x812, email: [EMAIL PROTECTED]
http://www.geniesystems.com





Pier P. Fumagalli [EMAIL PROTECTED]
11/08/2001 16:01

 
To: [EMAIL PROTECTED], [EMAIL PROTECTED], 
[EMAIL PROTECTED], [EMAIL PROTECTED]
cc: 
Subject:Re: [ANNOUNCEMENT] Tomcat 4.0-beta-7 Released


Pier P. Fumagalli at [EMAIL PROTECTED] wrote:

 Craig R. McClanahan at [EMAIL PROTECTED] wrote:

 [...]
 In addition, as with the previous version, an installer-based version 
of
 Tomcat 4.0-beta-7 is available for Windows users, as well as native 
code
 versions of the mod_webapp connector for Apache.

 Binary distributions for the WebApp connector are available at:

 http://jakarta.apache.org/builds/jakarta-tomcat-4.0/release/v4.0-b7/bin

Also for Win32 (since MANY people asked!). Those CAN NOT be built from the
same sources distribution as the build process for windows was added AFTER
4.0b7 was released, but are built on top of the same sources.

To build the WebApp module on your own, check out the CVS version.

Pier