RE: X509 client certificate
Hi Alexandre.
I'm not sure I fully understand your question but let me see if I can
help you at all.
The addSecureEndpoint method of EmbededTomcat used to be just like the
one you described below. I added the addSecureEndpoint(int port,
InetAddress addr, String hostname, String keyfile, String keypass,
boolean clientAuth) to be able to force the client to show a certificate
for logging in.
I want to answer you in a few steps, so please bear with me.
1.
Now, first of all I think you're going a little bit too long of a way
using the addSecureEndpoint. Wouldn't it be easier for you to call the
method I described above (the addSecureEndpoint(int, InetAddress,
String, String, String, boolean)) instead of calling the original one
(the addSecureEndpoint(int, InetAddress, String, String, String)) and
changing the code in that? The modifications to the original
addSecureEndpoint were for backwards compatability. In other words, the
original method, addSecureEndpoint added an endpoint with no client
authentication. I added a method that provides means for getting client
authentication by the means of client certificates, and modified the
original call to call my method with client authentication == false.
Hence, maintaining backwards compatability. I would say you should much
rather change the code in tomcat to what it was before and call
addSecureEndpoint(int, InetAddress, String, String, String, boolean) in
EmbededTomcat directly instead. That way you won't have to recompile
Tomcat every time you change your mind about requiring a client
certificate in your application.
2.
Now for your problem at hand ;o). I don't know exactly how the
getUserPrincipal method in HttpServletRequest class is supposed to work
but what I got from JavaDoc was:
Returns a java.security.Principal object containing the name of the
current authenticated user. If the user has not been authenticated, the
method returns null.
And from the JavaDoc for java.security.Principal, I got:
This interface represents the abstract notion of a principal, which can
be used to represent any entity, such as an individual, a corporation,
and a login id.
Now. You would think that Tomcat should serve up the DN of the client
certificate when a user calls request.getUserPrincipal but according to
you, it doesn't. I don't know if there are any reasons for that
although I doubt it. I would think this is an oversight and should
prefferably be fixed. That shouldn't be too much trouble. The
ServletAPI Specs are not all that clear about this issue. I would think
that getUserPrincipal works for other types of authentication (the
username, password type). I'll file in a bug report on this matter
after I finish this ;o)
Now for your solution. What you can do is call the method
request.getAttribute( "javax.servlet.request.X509Certificate" ). This
will return a java.security.cert.X509Certificate with all the
information you could possibly want (well... almost) on your client.
This include the distinguished name of the client by using
java.security.cert.X509Certificate.getSubjectDN().
I hope this helps!
Regards, Stefan.
-Original Message-
From: Alexandre A. Drummond Barroso
[mailto:[EMAIL PROTECTED]]
Sent: 3. desember 2000 00:16
To: [EMAIL PROTECTED]
Subject: X509 client certificate
I tried to make Tomcat
changing the following parameter of addSecureEndpoint in
src/share/org/apache/tomcat/startup/EmbededTomcat.java:
public void addSecureEndpoint( int port, InetAddress addr, String
hostname,
String keyFile, String keyPass )
{
addSecureEndpoint(port, addr, hostname, keyFile, keyPass,
false);
^
to true, but when I called request.getUserPrincipal() it just returned
null. Is there any problem with addSecureEndpoint
implementation or in some method it calls?
Regards,
Alexandre
Cannot set up certs for trusted CAs; JCE and tomcat
hi
i am facing a problem when calling JCE
functionality from a servlet inside the tomcat webserver. Can u help me? thanks
in advance. The problem is followed--
--
in the code :
Cipher.getInstance("DES/ECB/PKCS5Padding");
java.lang.ExceptionInInitializerError:
java.lang.SecurityException: Cannot set up certs for trusted
CAs
at
javax.crypto.b.([DashoPro-V1.2-120198])
at
javax.crypto.Cipher.getInstance([DashoPro-V1.2-120198])
and etc. etc.
--
Ranjan DasSoftware
ProfessionalUshacommunications TechnologyThe Legacy Building25 A,
Shakespeare SaraniCalcuttaPIN - 700017INDIAPhone:+91-33-2812805
Extn:705
RPM for jakarta/xml apaches projects
Hi, I just want to launch a poll to all tomcat commiters and latter extends to jakarta.apache.org and xml.apache.org projects commiters. As you may know I allready release RPM for the majority of the new Apache Projects. May be it will be time to 'Institutionalize the RPM Creation Process' as say Craig : 1) To help many of the RPM users (Redhat, Suze, Mandrake) to start easily with these tools. It will also reduce the number of mail in the list with : 'Where could I find mod_jk.so for Redhat ?' 'How can I build tomcat with SSL ?' 2) RPM is not Redhat Linux restricted and is really a very powerfull tool. It give you the total control from source to installation. With it's ability to check for dependencies, exclusions and pre/post install/desinstall scripts, it allow the developper to be sure where and how the software is installed. For the user point of vue, it's a real plus when installing the same configuration on many servers. --- * I propose to publish to jakarta (and xml) site all apache related RPMs present today at : ftp://ftp.falsehope.com/home/gomez/ * Another proposal is to include a rpm.tar.gz in project containing the .spec file, the init, logrotate and eventual patches. bref all the files needed to rebuild the RPM. * It will be nice to find RPM developpers with alpha, mips, ppc and sparc systems to regenerate arch dependant stuff (tomcat-mod == mod_jserv mod_jk) to these platforms. Regards "Pour la plupart des hommes, se corriger consiste à changer de défauts." -- Voltaire
RE: BugRat Report #516 has been filed.
woops... this bug should not have that severity or priority... I didn't notice any place where I should have set that now that I think of it... hmmm... weird... maybe it's a bug in the bug-tracking system? -Original Message- From: BugRat Mail System [mailto:[EMAIL PROTECTED]] Sent: 4. desember 2000 15:12 To: [EMAIL PROTECTED] Subject: BugRat Report #516 has been filed. Bug report #516 has just been filed. You can view the report at the following URL: http://znutar.cortexity.com/BugRatViewer/ShowReport/516 REPORT #516 Details. Project: Tomcat Category: Bug Report SubCategory: New Bug Report Class: swbug State: received Priority: high Severity: critical Confidence: public Environment: Release: 3.2 JVM Release: 1.3 Operating System: Windows 2000 OS Release: 5.00.2195 w/SP1 Platform: Intel x86 Synopsis: request.getUserPrincipal() doesn't work when user is authenticated with a X509 client certificate. Description: Shouldn't this method return the subject DN of the clients X509 certificate?
BugRat Report #516 has been filed.
Bug report #516 has just been filed. You can view the report at the following URL: http://znutar.cortexity.com/BugRatViewer/ShowReport/516 REPORT #516 Details. Project: Tomcat Category: Bug Report SubCategory: New Bug Report Class: swbug State: received Priority: high Severity: critical Confidence: public Environment: Release: 3.2 JVM Release: 1.3 Operating System: Windows 2000 OS Release: 5.00.2195 w/SP1 Platform: Intel x86 Synopsis: request.getUserPrincipal() doesn't work when user is authenticated with a X509 client certificate. Description: Shouldn't this method return the subject DN of the clients X509 certificate? Title: BugRat Report # 516 BugRat Report # 516 Project: Tomcat Release: 3.2 Category: Bug Report SubCategory: New Bug Report Class: swbug State: received Priority: high Severity: critical Confidence: public Submitter: Stefan Freyr Stefansson ([EMAIL PROTECTED]) Date Submitted: Dec 4 2000, 09:11:55 CST Responsible: Z_Tomcat Alias ([EMAIL PROTECTED]) Synopsis: request.getUserPrincipal() doesn't work when user is authenticated with a X509 client certificate. Environment: (jvm, os, osrel, platform) 1.3, Windows 2000, 5.00.2195 w/SP1, Intel x86 Additional Environment Description: Report Description: Shouldn't this method return the subject DN of the clients X509 certificate? How To Reproduce: null Workaround: null View this report online...
migration from JServ to Jakarta-Tomcat
Hello in ApacheModuleJServ: ApJServAction .jsp /servlets/oracle.jsp.JspServlet How it will be present in httpd.conf with mod_jk? Alexey Salnikov ICQ: 14293059
RE: RPM for jakarta/xml apaches projects
As a Linux user I would be more than happy to see this happen. RPM is a great tool that makes installing and maintaining a linux box very easy. That's the goal ... My +1 on that, my only wish/concern is related with the locations of the files ( I have a very strong preference to /opt - it allows multiple versions of the same program, etc ) /opt is reserved ReadOnly on many systems. Debian boys told me that packages should go to /var/x and java stuff /usr/share/java . Java software on Linux is not really standard now. * Another proposal is to include a rpm.tar.gz in project containing the .spec file, the init, logrotate and eventual patches. bref all the files needed to rebuild the RPM. What is the .tar.gz and where do you plan to include it ? ( in tomcat3 there are already .spec files in jakarta-tomcat/src/build ( and also .pkginfo ) ) The .spec file included is a little outdated (date from TC 3.1 I think) The others stuff is logrotate and init stuff. Usefull things when in productions ;-)
Re: RPM for jakarta/xml apaches projects
Hi Henri, on a similar note, I am currently beginning the long road into the Debian project. I have already stated that I wish to take over the packaging for Cocoon, and am currently debating whether to try to do Tomcat as well. I would be interested in hearing from folks here whether they percieve a need for Debian packaging, or whether they prefer to "roll their own"? cheers -Thom On Mon, Dec 04, 2000 at 03:19:55 +0100, GOMEZ Henri said: Hi, I just want to launch a poll to all tomcat commiters and latter=20 extends to jakarta.apache.org and xml.apache.org projects commiters. As you may know I allready release RPM for the majority of the new Apache Projects. May be it will be time to 'Institutionalize the RPM Creation Process' = as say Craig : 1) To help many of the RPM users (Redhat, Suze, Mandrake) to start = easily with these tools. It will also reduce the number of mail in the list = with : 'Where could I find mod_jk.so for Redhat ?' 'How can I build tomcat with SSL ?' 2) RPM is not Redhat Linux restricted and is really a very powerfull = tool. It give you the total control from source to installation. With it's ability to check for dependencies, exclusions and pre/post install/desinstall scripts, it allow the developper to be sure where and how the software is installed.=20 For the user point of vue, it's a real plus when installing the same configuration on many servers. --- * I propose to publish to jakarta (and xml) site all apache related = RPMs present=20 today at : ftp://ftp.falsehope.com/home/gomez/ * Another proposal is to include a rpm.tar.gz in project containing the .spec file, the init, logrotate and eventual patches. bref all the files needed to rebuild the RPM. * It will be nice to find RPM developpers with alpha, mips, ppc and = sparc systems to regenerate arch dependant stuff (tomcat-mod =3D=3D mod_jserv mod_jk) to these platforms. =20 Regards "Pour la plupart des hommes, se corriger consiste =E0 changer de = d=E9fauts." -- Voltaire=20
Re: RPM for jakarta/xml apaches projects
On Mon, 4 Dec 2000, Thom May wrote: I would be interested in hearing from folks here whether they percieve a need for Debian packaging, or whether they prefer to "roll their own"? I'd love to see up-to-date Debian packaging, but I think it would be a challenge to keep it quite as up-to-date as CVS. Perhaps a regular "stable" release for Debian unstable and a nightly build for those of us who like pain? Andrew. - Web Consultant | Email: a.savory at uea.ac.uk Library and Learning Resources | URL: http://www.uea.ac.uk/ University of East Anglia | All views are my own - Norwich, NR4 7TJ, UK |who else would want them? -
BugRat Report #517 has been filed.
Bug report #517 has just been filed. You can view the report at the following URL: http://znutar.cortexity.com/BugRatViewer/ShowReport/517 REPORT #517 Details. Project: Tomcat Category: Bug Report SubCategory: New Bug Report Class: swbug State: received Priority: high Severity: serious Confidence: public Environment: Release: Tomcat 3.2b8 JVM Release: IBM Java2 1.1.3 Operating System: Linux RH OS Release: 6.2 Platform: Intel Synopsis: If nothing is mounted to "/" and a request is made that doesn't get mapped to any of the mounted contextes, then Tomcat doesn't give any reply and eats up all the CPU time it can Description: Title: BugRat Report # 517 BugRat Report # 517 Project: Tomcat Release: Tomcat 3.2b8 Category: Bug Report SubCategory: New Bug Report Class: swbug State: received Priority: high Severity: serious Confidence: public Submitter: Tagunov Anthony ([EMAIL PROTECTED]) Date Submitted: Dec 4 2000, 11:28:15 CST Responsible: Z_Tomcat Alias ([EMAIL PROTECTED]) Synopsis: If nothing is mounted to "/" and a request is made that doesn't get mapped to any of the mounted contextes, then Tomcat doesn't give any reply and eats up all the CPU time it can Environment: (jvm, os, osrel, platform) IBM Java2 1.1.3, Linux RH, 6.2, Intel Additional Environment Description: Report Description: View this report online...
Re: RPM for jakarta/xml apaches projects
On Mon, Dec 04, 2000 at 05:24:01 +, Andrew Savory said: On Mon, 4 Dec 2000, Thom May wrote: I would be interested in hearing from folks here whether they percieve a need for Debian packaging, or whether they prefer to "roll their own"? I'd love to see up-to-date Debian packaging, but I think it would be a challenge to keep it quite as up-to-date as CVS. Perhaps a regular "stable" release for Debian unstable and a nightly build for those of us who like pain? That was kindof how I was thinking, but also in terms of contributing the debian packaging code back, so that a nightly build would still produce a debian package, if you wished. Andrew. Thom - Web Conslutant | Email: a.savory at uea.ac.uk Library and Learning Resources | URL: http://www.uea.ac.uk/ University of East Anglia | All views are my own - Norwich, NR4 7TJ, UK |who else would want them? -
Servlet Reloading Problems
Hi All.. Can anybody tell me why it takes my installation of Tomcat anything up to 10 minutes to reload servlets?? The servlets load fine when you restart Apache. OS - Sun Microsystems Inc. SunOS 5.7 Tomcat - 3.2 Any help would be great __ Do You Yahoo!? Yahoo! Shopping - Thousands of Stores. Millions of Products. http://shopping.yahoo.com/
Tomcat 3.2 - Default web.xml not being read
We have been running tomcat 3.1 for a while, and just downloaded 3.2 final to our test Unix server. We have our servlets defined in the home + "/conf/web.xml" file. This has not changed. 3.1 still works fine. 3.2 does not load the servlets in the default context, and does not load the default web.xml file. I turned debugging to level "30". I added one to the servlets to the home + "/webapps/examples/web.xml", and the servlet now loads (it shows in the displays + I can access) , but only under the "examples" container (or directory). Is there something different I need to do to have the default web.xml file to be read/processed? Thanks, Helge Osmundsen
Re: BugRat Report #516 has been filed.
Stefán F. Stefánsson wrote: woops... this bug should not have that severity or priority... I didn't notice any place where I should have set that now that I think of it... hmmm... weird... maybe it's a bug in the bug-tracking system? Yah, it is ... In response to the issue raised however, I should point out that Tomcat 3.2 does not currently support the CLIENT-CERT mechanism for populating request.getUserPrincipal(), and also for tying in to security constraints. (Tomcat 4.0 does this.) Craig McClanahan -Original Message- From: BugRat Mail System [mailto:[EMAIL PROTECTED]] Sent: 4. desember 2000 15:12 To: [EMAIL PROTECTED] Subject: BugRat Report #516 has been filed. Bug report #516 has just been filed. You can view the report at the following URL: http://znutar.cortexity.com/BugRatViewer/ShowReport/516 REPORT #516 Details. Project: Tomcat Category: Bug Report SubCategory: New Bug Report Class: swbug State: received Priority: high Severity: critical Confidence: public Environment: Release: 3.2 JVM Release: 1.3 Operating System: Windows 2000 OS Release: 5.00.2195 w/SP1 Platform: Intel x86 Synopsis: request.getUserPrincipal() doesn't work when user is authenticated with a X509 client certificate. Description: Shouldn't this method return the subject DN of the clients X509 certificate?
Re: Tomcat 3.2 - Default web.xml not being read
"Osmundsen, Helge" wrote: We have been running tomcat 3.1 for a while, and just downloaded 3.2 final to our test Unix server. We have our servlets defined in the home + "/conf/web.xml" file. This has not changed. 3.1 still works fine. 3.2 does not load the servlets in the default context, and does not load the default web.xml file. I turned debugging to level "30". I added one to the servlets to the home + "/webapps/examples/web.xml", and the servlet now loads (it shows in the displays + I can access) , but only under the "examples" container (or directory). Is there something different I need to do to have the default web.xml file to be read/processed? For Tomcat 3.2, you would have to modify the code. I didn't catch the change early enough in the release cycle, and I judged it too risky to change this back in 3.2 final, because I did not know what other changes might have also been made that depended on this. Note: Tomcat 4.0 restores the usage of the global configuration file "conf/web.xml", operating the way that 3.1 did. Thanks, Helge Osmundsen Craig McClanahan
Client Certificate Auth
(Sorry if this is a bit off topic) I am using Tomcat 3.1 with Apache - Stronghold. I am new to SSL / Digital certificates, and was wondering if any one can point me to any example code / url or even a book title which has an example of how to read a client digital certificate and grant access to users based on that. Firstly is this supported in Tomcat 3.1 with Apache as the web server ? Also is there any way that I can dispense certificates off my web server rather than ask the users to get a certificate from a CA. Thanks Shahed.
RE: RPM for jakarta/xml apaches projects
I would like to see a debian package of Tomcat. However, I'd also like to see a debian 1.2+ JDK *laugh* Amy! -Original Message- From: Thom May [mailto:[EMAIL PROTECTED]] Sent: Monday, December 04, 2000 12:20 PM To: [EMAIL PROTECTED] Subject: Re: RPM for jakarta/xml apaches projects Hi Henri, on a similar note, I am currently beginning the long road into the Debian project. I have already stated that I wish to take over the packaging for Cocoon, and am currently debating whether to try to do Tomcat as well. I would be interested in hearing from folks here whether they percieve a need for Debian packaging, or whether they prefer to "roll their own"? cheers -Thom On Mon, Dec 04, 2000 at 03:19:55 +0100, GOMEZ Henri said: Hi, I just want to launch a poll to all tomcat commiters and latter=20 extends to jakarta.apache.org and xml.apache.org projects commiters. As you may know I allready release RPM for the majority of the new Apache Projects. May be it will be time to 'Institutionalize the RPM Creation Process' = as say Craig : 1) To help many of the RPM users (Redhat, Suze, Mandrake) to start = easily with these tools. It will also reduce the number of mail in the list = with : 'Where could I find mod_jk.so for Redhat ?' 'How can I build tomcat with SSL ?' 2) RPM is not Redhat Linux restricted and is really a very powerfull = tool. It give you the total control from source to installation. With it's ability to check for dependencies, exclusions and pre/post install/desinstall scripts, it allow the developper to be sure where and how the software is installed.=20 For the user point of vue, it's a real plus when installing the same configuration on many servers. --- * I propose to publish to jakarta (and xml) site all apache related = RPMs present=20 today at : ftp://ftp.falsehope.com/home/gomez/ * Another proposal is to include a rpm.tar.gz in project containing the .spec file, the init, logrotate and eventual patches. bref all the files needed to rebuild the RPM. * It will be nice to find RPM developpers with alpha, mips, ppc and = sparc systems to regenerate arch dependant stuff (tomcat-mod =3D=3D mod_jserv mod_jk) to these platforms. =20 Regards "Pour la plupart des hommes, se corriger consiste =E0 changer de = d=E9fauts." -- Voltaire=20
Cannot compile mod_jk under Solaris 8 Intel
Hi, I am having a problem compiling mod_jk on Solaris 8 (Intel) for Tomcat 3.2. I have tried with both jdk1.2.1 and jdk1.2.2 for the include files since I know that Tomcat 3.1 had a problem with 1.2.2 Anyway, if I dont give the -lposix4 flag, I get the fdatasync symbol not found error. If I do give the -lposix4 flag, I get a message saying that cannot start server. BTW, I am using StrongHold (Apache 1.3.14) and the apxs etc are from stronghold. Thanks Shahed
Re: RPM for jakarta/xml apaches projects
I would be interested in hearing from folks here whether they percieve a need for Debian packaging, or whether they prefer to "roll their own"? I'd love to see up-to-date Debian packaging, but I think it would be a challenge to keep it quite as up-to-date as CVS. Perhaps a regular "stable" release for Debian unstable and a nightly build for those of us who like pain? The nightly build is back - including nightly run of watchdog !! ( last night we catched the first problem, it is fixed no - a new nightly should be available in few hours). Regarding .deb - it will also be nice to see a .pkg :-) Costin
Re: RPM for jakarta/xml apaches projects
[EMAIL PROTECTED] wrote: I would be interested in hearing from folks here whether they percieve a need for Debian packaging, or whether they prefer to "roll their own"? I'd love to see up-to-date Debian packaging, but I think it would be a challenge to keep it quite as up-to-date as CVS. Perhaps a regular "stable" release for Debian unstable and a nightly build for those of us who like pain? The nightly build is back - including nightly run of watchdog !! ( last night we catched the first problem, it is fixed no - a new nightly should be available in few hours). Costin, could you please move your upload directory for these nightly builds to someplace else? The problem is that you're confusing the people who wonder why the nightly builds have nothing to do with the current (3.2) code release. In their place, I can turn on the publishing of the 3.2 nightly builds that I'm creating but just not uploading. Regarding .deb - it will also be nice to see a .pkg :-) Costin Craig
Re: RPM for jakarta/xml apaches projects
Costin, could you please move your upload directory for these nightly builds to someplace else? The problem is that you're confusing the people who wonder why the nightly builds have nothing to do with the current (3.2) code release. I can move them to tomcat-3.3 - I wanted to avoid confusing people and use the old directory. I don't see why anyone would expect 3.2 to be in the nightly builds - the nightly builds are used the same way as before, for the current _development_ release ( same thing happened after tomcat3.1 was tagged, and the nightly builds started to be used for 3.2, etc). In their place, I can turn on the publishing of the 3.2 nightly builds that I'm creating but just not uploading. What is the reason of doing nightly builds of the previous release ? 3.2 is not in "development" mode, i.e no no features, etc - the nightly builds make sense for the development release where things change and you need this tool to make sure you don't get regressions or broken builds. My understanding is that 3.2 is released, and an eventual 3.2.1 will have only minor bug fixes, no new features or other "developments". If I remember corectly, this is the rule we agreed upon - as soon as a version is "feature freeze" ( that happened 3-4 months ago for 3.2), the development continues on the main branch, bug fixes that goes into the branch are merged into the development tree, etc. Costin
RE: RPM for jakarta/xml apaches projects
What about spliting the package - /opt/tomcat for the JARs, /var/log/tomcat for tomcat logs, /home/httpd/webapps for webapps ? Up to redhat 6.2, /home/httpd was the serverroot. Config goes to /etc/httpd/conf and misc logs in /var/log/httpd. It would be nice to have a standard - what are the options ( i.e. what rules does RedHat/Debian/etc follow ? ) In our case we should also look at how Apache is installed, since we have to integrate with it - the webapps should sit close to the static pages ( is it /home/httpd or /var/httpd ? ). But with Redhat 7.0 ServerRoot goes now in /var/www. Redhat decided to follow the normal way since /home is reserved for Real Users use. Not an easy task you have, Henri :-) May be easier than writing a servlet engine core ;-} The .spec file included is a little outdated (date from TC 3.1 I think) The others stuff is logrotate and init stuff. Usefull things when in productions ;-) Yes, I know. Can you update them / check the new stuff in ? Sure, I'll do in tomcat_32 and tomcat_33 May be also in tomcat_4. I'll ask now to Redhat users and expert of Linux FHS to send their advices.
Tomcat 3.2 on Solaris 8 with Sun JDK 1.1.2
I have faced this problem earlier with Tomcat 3.1. It just does not seem to work with JDK 1.2.2. When I access a jsp, the .java file under the work directory get stuck at out.write(html\r\n!--\r\n Copyright (c) 1999 The Apache Software Foundation. All rights \r\n reserved.\r\n--\r\n\r\n); It works fine if I set JAVA_HOME to jdk1.2.1 Is this bug fixed in later versions ? Thanks Shahed
Re: RPM for jakarta/xml apaches projects
[EMAIL PROTECTED] wrote: Costin, could you please move your upload directory for these nightly builds to someplace else? The problem is that you're confusing the people who wonder why the nightly builds have nothing to do with the current (3.2) code release. I can move them to tomcat-3.3 - I wanted to avoid confusing people and use the old directory. I don't see why anyone would expect 3.2 to be in the nightly builds - the nightly builds are used the same way as before, for the current _development_ release ( same thing happened after tomcat3.1 was tagged, and the nightly builds started to be used for 3.2, etc). In their place, I can turn on the publishing of the 3.2 nightly builds that I'm creating but just not uploading. What is the reason of doing nightly builds of the previous release ? 3.2 is not in "development" mode, i.e no no features, etc - the nightly builds make sense for the development release where things change and you need this tool to make sure you don't get regressions or broken builds. My understanding is that 3.2 is released, and an eventual 3.2.1 will have only minor bug fixes, no new features or other "developments". Yes it's for bug fixes, but people (especially non-CVS users) want to be able to test them without going through the pain of having to cut betas all the time. If I remember corectly, this is the rule we agreed upon - as soon as a version is "feature freeze" ( that happened 3-4 months ago for 3.2), the development continues on the main branch, bug fixes that goes into the branch are merged into the development tree, etc. Costin Craig
Draft of ajp13 Documentation
Attached is a first draft of a document specifying how the Ajp13 protocol works. I wrote it based on what I found in both the C and Java sides of the implementation (in tomcat-3.3). There are a few things I want to add to it, but I hope it's pretty useful as is. If anyone has any feedback on this, please feel free to get in touch with me. I'd be happy to hear about any details I may have gotten wrong, and also any suggestions for improving the doc itself (layout, etc). Also, if anyone can help explain *why* certain choices were made, that would be excellent. Enjoy, -Dan -- Dan Milstein // [EMAIL PROTECTED] Title: Apache JServ Protocol version 1.3 Apache JServ Protocol version 1.3 Dan Milstein, [EMAIL PROTECTED], December 2000. This describes the Apache JServ Protocol version 1.3 (hereafter ajp13). There is, apparently, no current documentation of how the protocol works. This document is an attempt to remedy that, in order to make life easier for maintainers of mod_jk, and for anyone who wants to port the protocol somewhere (into jakarta 4.x, for example). Who Am I? I am not one of the designers of this protocol -- I believe that Gal Shachor was the original designer. Everything in this document is derived from the actual implementation I found in the tomcat 3.x code. I hope it is useful, but I can't make any grand claims to perfect accuracy. I also don't know why certain design decisions were made. Where I was able, I've offered some possible justifications for certain choices, but those are only my guesses. In general, the C code which Shachor wrote is very clean and comprehensible (if almost totally undocumented). The Java code is pretty much a mess. Design Goals According to email from Gal Shachor to the jakarta-dev mailing list, the original goals of mod_jk (and thus ajp13) were to extend mod_jserv and ajp12 by (I am only including the goals which relate to communication between the web server and the servlet container): Increasing performance (speed, specifically). Adding support for SSL, so that isSecure() and geScheme() will function correctly within the servlet container. The client certificates and cipher suite will be available to servlets as request attributes. Overview The ajp13 protocol is packet-oriented. A binary format was presumably chosen over the more readable plain text for reasons of performance. The web server communicates with the servlet container over TCP connections. To cut down on the expensive process of socket creation, the web server will attempt to maintain persistent TCP connections to the servlet container, and to reuse a connection for multiple request/response cycles. Once a connection is assigned to a particular request, it will not be used for any others until the request-handling cycle has terminated. In other words, requests are not multiplexed over connections. This makes for much simpler code at either end of the connection, although it does cause more connections to be open at once. Once the web server has opened a connection to the servlet container, the connection can be in one of the following states: Idle No request is being handled over this connection. Assigned The connecton is handling a specific request. Once a connection is assigned to handle a particular request, the basic request informaton (e.g. HTTP headers, etc) is sent over the connection in a highly condensed form (e.g. common strings are encoded as integers). Details of that format are below in Request Packet Structure. If there is a body to the request (content-length > 0), that is sent in a separate packet immediately after. At this point, the servlet container is presumably ready to start processing the request. As it does so, it can send the following messages back to the web server: SEND_HEADERS Send a set of headers back to the browser. SEND_BODY_CHUNK Send a chunk of body data back to the browser. GET_BODY_CHUNK Get further data from the request if it hasn't all been transferred yet. This is necessary because the packets have a fixed maximum size and arbitrary amounts of data can be included the body of a request (for uploaded files, for example). (Note: this is unrelated to HTTP chunked tranfer). END_RESPONSE Finish the request-handling cycle. Each message is accompanied by a differently formatted packet of data. See Response Packet Structures below for details. Basic Packet Structure There is a bit of an XDR heritage to this protocol, but it differs in lots of ways (no 4 byte alignment, for example). Byte order: I am not clear about the endian-ness of the individual bytes. I'm guessing the bytes are little-endian, because that's what XDR specifies, and I'm guessing that sys/socket library is magically making that so (on the C side). If anyone with a better knowledge of socket calls can step in, that would be great. There are four data types in the
Re: RPM for jakarta/xml apaches projects
I'd love to see up-to-date Debian packaging, but I think it would be a challenge to keep it quite as up-to-date as CVS. Perhaps a regular "stable" release for Debian unstable and a nightly build for those of us who like pain? I didn't know much about debian packaging but there is a tool, alien, which convert from RPM to dpkg. I could be an issue. Regards
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/modules/config RelativePathFix.java
costin 00/12/04 13:11:56
Added: src/share/org/apache/tomcat/modules/config
RelativePathFix.java
Log:
Added a new module, based on refactoring part of DefaultCMSetter.
This module will "fix" any relative path used in tomcat's configs,
using the same rules as before. The main difference is that all the "fixing" is
grouped in a single replaceable module - that should make the code
easier to read and fix.
The module will replace DefaultCMSetter after some more testing. It needs more
documentation of the rules ( based on what we think is the right way to
do that, not what happened to happen before )
Revision ChangesPath
1.1
jakarta-tomcat/src/share/org/apache/tomcat/modules/config/RelativePathFix.java
Index: RelativePathFix.java
===
/*
*
*
* The Apache Software License, Version 1.1
*
* Copyright (c) 1999 The Apache Software Foundation. All rights
* reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
*
* 1. Redistributions of source code must retain the above copyright
*notice, this list of conditions and the following disclaimer.
*
* 2. Redistributions in binary form must reproduce the above copyright
*notice, this list of conditions and the following disclaimer in
*the documentation and/or other materials provided with the
*distribution.
*
* 3. The end-user documentation included with the redistribution, if
*any, must include the following acknowlegement:
* "This product includes software developed by the
*Apache Software Foundation (http://www.apache.org/)."
*Alternately, this acknowlegement may appear in the software itself,
*if and wherever such third-party acknowlegements normally appear.
*
* 4. The names "The Jakarta Project", "Tomcat", and "Apache Software
*Foundation" must not be used to endorse or promote products derived
*from this software without prior written permission. For written
*permission, please contact [EMAIL PROTECTED]
*
* 5. Products derived from this software may not be called "Apache"
*nor may "Apache" appear in their names without prior written
*permission of the Apache Group.
*
* THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
* WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
* OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
* DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR
* ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
* SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
* LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
* USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
* ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
* OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
* OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*
*
* This software consists of voluntary contributions made by many
* individuals on behalf of the Apache Software Foundation. For more
* information on the Apache Software Foundation, please see
* http://www.apache.org/.
*
* [Additional notices, if required by prior licensing conditions]
*
*/
package org.apache.tomcat.modules.config;
import org.apache.tomcat.core.*;
import org.apache.tomcat.request.*;
import org.apache.tomcat.util.*;
import java.io.*;
import java.net.*;
import java.util.*;
import java.security.*;
import org.apache.tomcat.util.log.*;
// based on DefaultCMSetter
/**
* Fix all paths in ContextManager and loaded Contexts. That includes:
* - ContextManager: home, installDir, loggers
* - Context: base dir, loggers
*
* If a path is absolute, do nothing.
* If a path is relative, make it absolute based on a set of rules:
* - the Context absolute path is based on CM.home
* -
*
* @author [EMAIL PROTECTED]
*/
public final class RelativePathFix extends BaseInterceptor {
public RelativePathFix() {
}
/** Adjust context manager paths
*/
public void engineInit( ContextManager cm )
throws TomcatException
{
initHome(cm);
initWorkDir(cm);
initLoggers(cm);
}
/** Adjust paths
*/
public void addContext( ContextManager cm, Context ctx)
throws TomcatException
{
initAbsolutePath( ctx );
initContextLoggers( ctx );
}
RE: Tomcat 3.2 - Default web.xml not being read
We had all our URL's (except our login form) stored in the web.xml file as input parameters to out servlets, so I created a new context,altered the URL's to include the context name, and started the tomcat server. It now appears to be working fine under the new context. I noticed that the defaultServlet, etc. were being loaded prior to my new context, and I am able to run with the new context only defining my servlets. Are the default servlets, and mime-types, etc being loaded through an XML file, or by some other means? Thanks, Helge Osmundsen -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Monday, December 04, 2000 2:19 PM To: [EMAIL PROTECTED] Subject: Re: Tomcat 3.2 - Default web.xml not being read We have been running tomcat 3.1 for a while, and just downloaded 3.2 final to our test Unix server. We have our servlets defined in the home + "/conf/web.xml" file. This has not changed. 3.1 still works fine. 3.2 does not load the servlets in the default context, and does not load the default web.xml file. I turned debugging to level "30". I added one to the servlets to the home + "/webapps/examples/web.xml", and the servlet now loads (it shows in the displays + I can access) , but only under the "examples" container (or directory). Is there something different I need to do to have the default web.xml file to be read/processed? web.xml is no longer used/supported in 3.2. The main reason - the code that merged the "default" web.xml with the application web.xml was very bad, slow and hard to maintain. It was commented out until someone wants to fix it. A second reason - probably more important from a user perspective - is that it direct user to un-portable web applications. If you want your application to be portable ( i.e. to be able to take it and deploy it on a different container ) you need to have all the mappings, etc in your application web.xml file. As long as you use the "default" web.xml your application can't be portable. In addition, there was no rule about the interaction between setting in the application web.xml and the server web.xml - it just happen based on hacks in the code. A third reason is the fact that tomcat already has a configuration file - server.xml, and it's confusing to use 2 different styles, and server.xml has far more options on setting the server. To add another argument here, one idea in tomcat is that the server shouldn't depend on any particular cofiguration file format - it should be possible to embed tomcat in an application using JNDI or windows registry for configuration, and tomcat shouldn't require any special configuration file. Web.xml was a big obstacle for this. ( if you look at EmbededTomcat, it is possible to start tomcat without any configuration file at all, using only API calls. If we would use web.xml then this will become much harder or impossible ) Costin
My patches for Tomcat 3.2 wrt mutlibyte characters
Hi, Try to visit http://www.javaclue.org/tomcat/patch32/dopatch.html I hope that those would be adopted in TC 3.2.1. Thanks, Kim
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/modules/config WebAppsConfig.java
costin 00/12/04 13:18:45
Added: src/share/org/apache/tomcat/modules/config
WebAppsConfig.java
Log:
Added a new module that should replace AutoConfig.
The new module is aware of virtual hosts ( 3.2 supports auto-loading
of apps from tomcat/webapps - but only in the "default" host )
It also supports contexts mapped to "deep" paths ( 3.2 supports only
one level - i.e apps mapped to top level URIs).
It will replace AutoConfig after more testing and after I'll add the code to
supprot old /webapps dir.
Revision ChangesPath
1.1
jakarta-tomcat/src/share/org/apache/tomcat/modules/config/WebAppsConfig.java
Index: WebAppsConfig.java
===
/*
*
*
* The Apache Software License, Version 1.1
*
* Copyright (c) 1999 The Apache Software Foundation. All rights
* reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
*
* 1. Redistributions of source code must retain the above copyright
*notice, this list of conditions and the following disclaimer.
*
* 2. Redistributions in binary form must reproduce the above copyright
*notice, this list of conditions and the following disclaimer in
*the documentation and/or other materials provided with the
*distribution.
*
* 3. The end-user documentation included with the redistribution, if
*any, must include the following acknowlegement:
* "This product includes software developed by the
*Apache Software Foundation (http://www.apache.org/)."
*Alternately, this acknowlegement may appear in the software itself,
*if and wherever such third-party acknowlegements normally appear.
*
* 4. The names "The Jakarta Project", "Tomcat", and "Apache Software
*Foundation" must not be used to endorse or promote products derived
*from this software without prior written permission. For written
*permission, please contact [EMAIL PROTECTED]
*
* 5. Products derived from this software may not be called "Apache"
*nor may "Apache" appear in their names without prior written
*permission of the Apache Group.
*
* THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
* WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
* OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
* DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR
* ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
* SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
* LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
* USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
* ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
* OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
* OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*
*
* This software consists of voluntary contributions made by many
* individuals on behalf of the Apache Software Foundation. For more
* information on the Apache Software Foundation, please see
* http://www.apache.org/.
*
* [Additional notices, if required by prior licensing conditions]
*
*/
package org.apache.tomcat.modules.config;
import org.apache.tomcat.core.*;
import org.apache.tomcat.util.*;
import java.io.*;
import java.net.*;
import java.util.*;
import org.apache.tomcat.util.xml.*;
import org.apache.tomcat.helper.*;
import org.apache.tomcat.task.Expand;
/**
*
* @author [EMAIL PROTECTED]
*/
public class WebAppsConfig extends BaseInterceptor {
int debug=0;
Hashtable hosts=new Hashtable();
String hostsD="hosts";
public WebAppsConfig() {
}
// Config
/** Use this directory for auto configuration
*/
public void setDir( String d ) {
hostsD=d;
}
/** Use this directory for auto configuration
*/
public void setHostXmlDir( String d ) {
hostsD=d;
}
// Implementation
/**
*/
public void engineInit(ContextManager cm) throws TomcatException {
Enumeration loadedCtx=cm.getContexts();
while( loadedCtx.hasMoreElements() ) {
addExistingCtx( (Context)loadedCtx.nextElement());
}
String home=cm.getHome();
File webappD;
if( hostsD.startsWith( "/" ) )
webappD=new File(hostsD);
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/modules/config WorkDirSetup.java
costin 00/12/04 13:22:50
Added: src/share/org/apache/tomcat/modules/config WorkDirSetup.java
Log:
Added a connector ( based on refactoring of DefaultCMSetter, etc) to set
and manage the workdir.
New options to use a private directory inside WEB-INF ( according to the spec
a container is allowed to use it's own internal representation of a web
application ) - that would simplify the configuration of security
options and ( if the workdir is used to store persistent data like
compiled jsp files ) simplify the migration of webapplications
in a pool of containers.
This also allow people to completely replace the current behavior more easily,
by keeping all that's related with workdir in a single module.
Revision ChangesPath
1.1
jakarta-tomcat/src/share/org/apache/tomcat/modules/config/WorkDirSetup.java
Index: WorkDirSetup.java
===
/*
*
*
* The Apache Software License, Version 1.1
*
* Copyright (c) 1999 The Apache Software Foundation. All rights
* reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
*
* 1. Redistributions of source code must retain the above copyright
*notice, this list of conditions and the following disclaimer.
*
* 2. Redistributions in binary form must reproduce the above copyright
*notice, this list of conditions and the following disclaimer in
*the documentation and/or other materials provided with the
*distribution.
*
* 3. The end-user documentation included with the redistribution, if
*any, must include the following acknowlegement:
* "This product includes software developed by the
*Apache Software Foundation (http://www.apache.org/)."
*Alternately, this acknowlegement may appear in the software itself,
*if and wherever such third-party acknowlegements normally appear.
*
* 4. The names "The Jakarta Project", "Tomcat", and "Apache Software
*Foundation" must not be used to endorse or promote products derived
*from this software without prior written permission. For written
*permission, please contact [EMAIL PROTECTED]
*
* 5. Products derived from this software may not be called "Apache"
*nor may "Apache" appear in their names without prior written
*permission of the Apache Group.
*
* THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
* WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
* OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
* DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR
* ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
* SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
* LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
* USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
* ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
* OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
* OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*
*
* This software consists of voluntary contributions made by many
* individuals on behalf of the Apache Software Foundation. For more
* information on the Apache Software Foundation, please see
* http://www.apache.org/.
*
* [Additional notices, if required by prior licensing conditions]
*
*/
package org.apache.tomcat.modules.config;
import org.apache.tomcat.core.*;
import org.apache.tomcat.util.*;
import java.io.*;
import java.net.*;
import java.util.*;
/**
* Handles work dir setup/removal.
*
* @author [EMAIL PROTECTED]
*/
public class WorkDirSetup extends BaseInterceptor {
/** Default work dir, relative to home
*/
public static final String DEFAULT_WORK_DIR="work";
boolean cleanWorkDir=false;
String workdirBase=null;
boolean useWebInf=false;
public WorkDirSetup() {
}
// Properties
/**
* Auto-remove the work dir when tomcat is (grecefully) stoped
* and when tomcat starts.
*
* IMHO this shouldn't be used - if true, we'll loose
* all jsp compiled files. The workdir is the only directory
* where the servlet is allowed to write anyway ( if policy
* is used ).
*/
public void setCleanWorkDir( boolean b ) {
cleanWorkDir=b;
}
/** Allow the user to customize the base directory for
workdirs (
BugRat Report #518 has been filed.
Bug report #518 has just been filed.
You can view the report at the following URL:
http://znutar.cortexity.com/BugRatViewer/ShowReport/518
REPORT #518 Details.
Project: Tomcat
Category: Bug Report
SubCategory: New Bug Report
Class: swbug
State: received
Priority: medium
Severity: serious
Confidence: public
Environment:
Release: 3.2
JVM Release: 1.3
Operating System: Win2000 Advanced
OS Release: Win2000
Platform: 2-CPU Pentium
Synopsis:
JNI problem: bufferedreader.read fails in Tomcat/IIS/JNI set-up
Description:
There seems to be a bug that interferes with servlet-to-servlet communication, when
Tomcat is running under IIS (Win 2000 Advanced), using JNI.
I'm attaching source for a pair of simple servlets that demonstrate the bug. The
first servlet (BadClient.java) opens a URLConnection to the second servlet
(BadServer.java). BadClient uses the URLConnection to open an output stream, then
uses the output stream to print some text, which will be read by BadServer.
The BadServer servlet then calls request.getReader to get a reader object, to read the
text that was sent by BadClient.
This all works fine under Tomcat 3.2, when Tomcat is running stand-alone. But if
Tomcat 3.2 is running inside IIS, using the JNI connector, there's a problem.
BadServer is never able to read any of the text sent by BadClient. The whole process
just seems to hang for exactly 1 minute... apparently, something times out after 1
minute, and BadClient stops trying to read the text. Under JNI, the read call returns
-1.
(Other servlets work fine under JNI.)
The two servlets go on and perform other tasks after that, with BadServer reading a
local .GIF file, then sending it back to BadClient, which send the image back to the
browser. That part works; it's the first part that fails, as described above.
I've tried various configurations of Tomcat -- using the JVM.DLL for classic, or
hotspot, or server (Java 1.3). No difference. I've looked in the various log files
for exceptions, and I don't see any.
Here's the source for both servlets (around 100 lines each). If the formatting is
messed up too badly, please let me know and I'll email a copy to anyone who wants to
investigate the problem.
// Here is all of BadClient.java (118 lines):
// BadClient.java -- demonstrates behavior that works fine in Tomcat 3.2
// but does not work when Tomcat runs under IIS using JNI
// Used in conjunction with BadServer.java
import javax.servlet.*;
import javax.servlet.http.*;
import java.io.*;
import java.util.*;
import java.net.URLConnection;
import java.net.URL;
public class BadClient extends HttpServlet {
// TODO: Either modify the following string literal to represent
// the URL of the BadServer servlet, or specify that URL
// using an init parameter.
String m_url = "http://localhost:8100/test/servlet/BadServer";
public void init(ServletConfig config) throws ServletException {
super.init(config);
try {
String str = getInitParameter("url"); //URL to 2nd
servlet
if (str != null) {
m_url = str;
}
}
catch (Exception e) {
e.printStackTrace();
}
}
public void service(HttpServletRequest request, HttpServletResponse res)
throws ServletException, IOException
{
// Open an URLConnection to the BadServer servlet.
URL url = new URL(m_url);
URLConnection urlConnection = url.openConnection();
urlConnection.setDoOutput(true);
urlConnection.setUseCaches(false);
urlConnection.setRequestProperty("Connection", "close");
OutputStream os = null;
try {
os = urlConnection.getOutputStream();
// Only use one of the following two statements:
//PrintWriter pw = new PrintWriter(os);
OutputStreamWriter pw = new OutputStreamWriter(os);
System.out.println("BadClient: About to print text. Time:" +
new Date());
// Send some text to the second servlet. This is the part that
// seems to fail when running on Tomcat 3.2 under IIS using
JNI.
// If using a PrintWriter, use the println method...
/*
if (pw.checkError()) {
System.out.println("BadClient: will do println;
checkError is true.");
}
pw.println("This is some text sent from BadClient to
BadServer.");
if (pw.checkError()) {
System.out.println("BadClient: just did
RE: Tomcat 3.2 - Default web.xml not being read
We had all our URL's (except our login form) stored in the web.xml file as input parameters to out servlets, so I created a new context,altered the URL's to include the context name, and started the tomcat server. It now appears to be working fine under the new context. If you used the "default" web.xml all you need to do is to move the config information in your webapp's web.xml. It should work fine - and your app will be portable to any other container ( without requiring any change in the server config ) I noticed that the defaultServlet, etc. were being loaded prior to my new context, and I am able to run with the new context only defining my servlets. Are the default servlets, and mime-types, etc being loaded through an XML file, or by some other means? The "defaultServet" no longer exists - static files are handled by the StaticInterceptor, a tomcat module that is much faster. You can still define a "defaultServlet" in your application - and again do it in a portable way. Same is true for mime-types - all configuration that is needed by a web application should be in that application's web.xml. If you want to alter tomcat's functionality ( for example use a different module to handle static files ) you'll use server.xml. The reasons for using a module instead of going to a servlet layer - the code is much faster ( it cuts one layer, has access to all tomcat internals ), and (IMHO) much more flexible and consistent with the tomcat structure. It is very easy to configure tomcat to use a servlet for static files, but it'll be slower. Costin
Re: Include Directive 3.1 Vs 3.2
This issue was the topic of quite a lot of discussion on the expert group for the servlet 2.3 and JSP 1.2 specs. Tomcat 3.2 implements the result of what the expert group decided was the intended behavior. Craig McClanahan Shahed Ali wrote: I noticed that if I have an include directive within another include directive,in Tomcat 3.1, the 2nd include has a path relative to the jsp doument. But in 3.2 its relative to the 1st include document. i.eA.jsp --- includes 1.inc - includes 2.inc Both 1.inc and 2.inc are under the ./include directory In 3.1A.jsp would have @ include file = "include/1.inc"and 1.inc would have @ include file = "include/2.inc" In 3.2A.jsp would have @ include file = "include/1.inc"and 1.inc would have @ include file = "2.inc" Is this a change in the jsp spec or something specfic to tomcat ? ThanksShahed
cvs commit: jakarta-tomcat/src/share/org/apache/jasper Constants.java
costin 00/12/04 15:40:48
Modified:src/share/org/apache/jasper Constants.java
Log:
Fixing another nasty bug related with JDK1.1 - MessageFormat in 1.1
throw NPE if any argument is null ( JDK1.2+ fixes this problem ).
( this bug was found by nightly runs of watchdog with JDK1.1 )
Revision ChangesPath
1.15 +16 -0 jakarta-tomcat/src/share/org/apache/jasper/Constants.java
Index: Constants.java
===
RCS file: /home/cvs/jakarta-tomcat/src/share/org/apache/jasper/Constants.java,v
retrieving revision 1.14
retrieving revision 1.15
diff -u -r1.14 -r1.15
--- Constants.java2000/09/29 06:59:59 1.14
+++ Constants.java2000/12/04 23:40:46 1.15
@@ -207,7 +207,23 @@
String msg = resources.getString(key);
if (args == null)
return msg;
+ if( msg==null ) {
+ //System.out.println("Can't find resource for " + key );
+ return key;
+ }
MessageFormat form = new MessageFormat(msg);
+ // JDK1.1 will throw NullPointer if args[0] == null
+ // JDK1.2+ will work fine.
+
+ //System.out.println(" XXX " + msg + " "+key + " " +args.length );
+ if( args.length 0 ) {
+ for( int i=0; i args.length; i++ ) {
+ if( args[i]==null ) {
+ //System.out.println("Null argument " +msg + " " + key);
+ return msg;
+ }
+ }
+ }
return form.format(args);
} catch (MissingResourceException ignore) {
throw new Error("Fatal Error: missing resource:
"+ignore.getClassName());
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector HttpResponseBase.java
remm00/12/04 20:44:14
Modified:catalina/src/share/org/apache/catalina/connector
HttpResponseBase.java
Log:
- Content length needs to be sent even if it's 0. It's necessary for kepp alive.
Revision ChangesPath
1.19 +5 -5
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/HttpResponseBase.java
Index: HttpResponseBase.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/HttpResponseBase.java,v
retrieving revision 1.18
retrieving revision 1.19
diff -u -r1.18 -r1.19
--- HttpResponseBase.java 2000/12/01 02:11:20 1.18
+++ HttpResponseBase.java 2000/12/05 04:44:14 1.19
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/HttpResponseBase.java,v
1.18 2000/12/01 02:11:20 craigmcc Exp $
- * $Revision: 1.18 $
- * $Date: 2000/12/01 02:11:20 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/HttpResponseBase.java,v
1.19 2000/12/05 04:44:14 remm Exp $
+ * $Revision: 1.19 $
+ * $Date: 2000/12/05 04:44:14 $
*
*
*
@@ -96,7 +96,7 @@
* methods need to be implemented.
*
* @author Craig R. McClanahan
- * @version $Revision: 1.18 $ $Date: 2000/12/01 02:11:20 $
+ * @version $Revision: 1.19 $ $Date: 2000/12/05 04:44:14 $
*/
public class HttpResponseBase
@@ -491,7 +491,7 @@
outputWriter.print("Content-Type: " + getContentType() + "\r\n");
//System.out.println(" Content-Type: " + getContentType());
}
- if (getContentLength() 0) {
+ if (getContentLength() = 0) {
outputWriter.print("Content-Length: " + getContentLength() +
"\r\n");
//System.out.println(" Content-Length: " +
getContentLength());
[PATCH] Code Cleanup/Reorg for Ajp13 Class
I've just completed a major cleanup/reorganization of:
org.apache.tomcat.modules.server.Ajp13
In the jakarta-tomcat branch, which I'm attaching as a patch against the current
version. I have done MINIMAL testing, since I am very new to working on Tomcat, and I
don't know what a standard set of tests might be (or if one exists). I have verified
that Tomcat can still talk to Apache, and that basic request info is being transfered.
That's about all I've been able to do.
The main goal of the rewrite was to clarify what is going on. To that end, I added a
lot of comments, and moved some code around to clarify what it was doing. I also:
- Fixed a minor bug in headerNameToSc -- response headers of type "WWW-Authenticate"
were not being encoded as integers, because of a typo in the Java code. Note that the
old behavior was less efficient (it would send the entire "WWW-Authenticate" string),
but not incorrect.
- Cleaned up all the import statements
- Stripped some unused code out of the internal Ajp13Packet class.
- Moved a lot of functionality out of tomcat.util.BuffTool into Ajp13Packet (where it
seemed much more natural). I believe that BuffTool can now be safely deleted (I just
deleted it and built Tomcat with no problems).
Enjoy,
-Dan
--
Dan Milstein // [EMAIL PROTECTED]
Index: Ajp13.java
===
RCS file:
/home/cvspublic/jakarta-tomcat/src/share/org/apache/tomcat/modules/server/Ajp13.java,v
retrieving revision 1.5
diff -u -r1.5 Ajp13.java
--- Ajp13.java 2000/11/30 04:58:45 1.5
+++ Ajp13.java 2000/12/05 04:25:53
@@ -59,27 +59,51 @@
package org.apache.tomcat.modules.server;
-import java.io.*;
-import java.net.*;
-import java.util.*;
-import org.apache.tomcat.core.*;
-import org.apache.tomcat.util.*;
-
+import java.io.IOException;
+import java.io.UnsupportedEncodingException;
+import java.io.InputStream;
+import java.io.OutputStream;
+import java.net.Socket;
+import java.util.Enumeration;
+
+import org.apache.tomcat.core.Request;
+import org.apache.tomcat.util.MimeHeaders;
+import org.apache.tomcat.util.MessageBytes;
+
+/**
+ * Represents a single, persistent connection between the web server and
+ * the servlet container. Uses the Apache JServ Protocol version 1.3 for
+ * communication. Because this protocal does not multiplex requests, this
+ * connection can only be associated with a single request-handling cycle
+ * at a time.P
+ *
+ * This class contains knowledge about how an individual packet is laid out
+ * (via the internal CODEAjp13Packet/CODE class), and also about the
+ * stages of communicaton between the server and the servlet container. It
+ * translates from Tomcat's internal servlet support methods
+ * (e.g. doWrite) to the correct packets to send to the web server.
+ *
+ * @see Ajp13Interceptor
+ */
public class Ajp13
{
public static final int MAX_PACKET_SIZE=8192;
-public static final int H_SIZE=4;
+public static final int H_SIZE=4; // Size of basic packet header
public static final int MAX_READ_SIZE = MAX_PACKET_SIZE - H_SIZE - 2;
public static final int MAX_SEND_SIZE = MAX_PACKET_SIZE - H_SIZE - 4;
+// Prefix codes for message types from server to container
public static final byte JK_AJP13_FORWARD_REQUEST = 2;
public static final byte JK_AJP13_SHUTDOWN = 7;
+// Prefix codes for message types from container to server
public static final byte JK_AJP13_SEND_BODY_CHUNK = 3;
public static final byte JK_AJP13_SEND_HEADERS = 4;
public static final byte JK_AJP13_END_RESPONSE = 5;
+public static final byte JK_AJP13_GET_BODY_CHUNK= 6;
+// Integer codes for common response header strings
public static final int SC_RESP_CONTENT_TYPE= 0xA001;
public static final int SC_RESP_CONTENT_LANGUAGE= 0xA002;
public static final int SC_RESP_CONTENT_LENGTH = 0xA003;
@@ -91,11 +115,10 @@
public static final int SC_RESP_SERVLET_ENGINE = 0xA009;
public static final int SC_RESP_STATUS = 0xA00A;
public static final int SC_RESP_WWW_AUTHENTICATE= 0xA00B;
-
-public static final byte JK_AJP13_GET_BODY_CHUNK = 6;
-public static final byte SC_A_CONTEXT = 1;
-public static final byte SC_A_SERVLET_PATH = 2;
+// Integer codes for common (optional) request attribute names
+public static final byte SC_A_CONTEXT = 1; // XXX Unused
+public static final byte SC_A_SERVLET_PATH = 2; // XXX Unused
public static final byte SC_A_REMOTE_USER = 3;
public static final byte SC_A_AUTH_TYPE = 4;
public static final byte SC_A_QUERY_STRING = 5;
@@ -103,9 +126,14 @@
public static final byte SC_A_SSL_CERT = 7;
public static final byte SC_A_SSL_CIPHER= 8;
public static final byte SC_A_SSL_SESSION = 9;
-public static final byte SC_A_REQ_ATTRIBUTE = 10;
+
Tomcat, JNI and hp-ux 10.20
I am using Tomcat on hp-ux 10.20 with Java version
("HP-UX Java C.01.18.03 05/12/2000 16:31:36 hkhd02") I am attempting to
use a servlet that instantiates a class that contains JNImethods and I
keep getting java.lang.UnsatisfiedLinkError exceptions when these native methods
are accessed. The JNImethods execute fine from the command line, and
I know that the servlet is loading the shared library. I noticed that
java.math.BigInteger uses native support and I can instantiate this class and
call its native methodswith no problem from the servlet. Given that,
I am confident that Tomcat can support this native functionality but I am
bewildered as to why my JNI methods do not work. Your comments would be
greatly appreciated.
Thanks,
Eric.
Benchmarks / Performance Tuning
What are some methods people use to measure the performance of Tomcat? I'm looking to do some tuning of the Ajp13 code, and I'd like to build up an understanding of where the bottlenecks might be. Any ideas? Thanks, -Dan -- Dan Milstein // [EMAIL PROTECTED]
Re: tomcat for Debian [RPM for jakarta/xml apaches projects]
I didn't know much about debian packaging but there is a tool, alien, which convert from RPM to dpkg. Alien isn't complete. Because policies are different between Redhat and Debian. Stefan is prepareing tomcat package for Debian. Check here. http://master.debian.org/~sgybas/tomcat/ -- Takashi Okamoto
Re: Benchmarks / Performance Tuning
What are some methods people use to measure the performance of Tomcat? I'm looking to do some tuning of the Ajp13 code, and I'd like to build up an understanding of where the bottlenecks might be. My recomendation is to start with simple tools - and "ab" is a perfect one if you use it with the right servlets and the right instrumentation on the server side. For Ajp13 you'll need to measure and tune the communication overhead - for the invocation/response part you can use the simple HelloWorld servlet, and you can create other simple servlets to tune other parts of the protocol. Even if the number you'll get will have no meaning for real apps ( other than the maximum speed tomcat can get for the simplest application ) - it does help a lot to improve this maximum speed and it shows where the problems are in the servlet container ( what you are tuning ). To see what happens inside the VM you can use -hprof, turn on verbose garbage collection ( very, very interesting ), and maybe try OptimizeIt ( it works on Linux ). It is very important to use "ab -c 20 " ( or more ) to get real information about how the server works under load - "ab -c 1 " is of no real use. Of course, there are better methods and tools - that's what I found to work better for me... Costin
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/core ContextManager.java
costin 00/12/04 22:24:46
Modified:src/share/org/apache/tomcat/core ContextManager.java
Log:
Again, more documentation and reviewing of ContextManager specification.
Removed the "STOP" state, documented the transitions from
new - init - start - stop ( with possible restart ) - shutdown.
Revision ChangesPath
1.155 +39 -19
jakarta-tomcat/src/share/org/apache/tomcat/core/ContextManager.java
Index: ContextManager.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/core/ContextManager.java,v
retrieving revision 1.154
retrieving revision 1.155
diff -u -r1.154 -r1.155
--- ContextManager.java 2000/12/03 08:19:03 1.154
+++ ContextManager.java 2000/12/05 06:24:45 1.155
@@ -160,9 +160,8 @@
h2Stopping the server/h2
- 1. stop(). The server will exit the START state and enter STOP,any request
- will get a "Server unavailable" error. All contextShutdown() and
- will be called. ( STOP==INIT ? )
+ 1. stop(). The server will exit the START state and enter INIT.
+ All contextShutdown() and will be called.
2. shutdown(). All removeContext() callbacks will be called and the server
will enter PRE_INIT state. The contexts will not be removed from
@@ -188,30 +187,43 @@
public static final String TOMCAT_VERSION = "3.3 dev";
public static final String TOMCAT_NAME = "Tomcat Web Server";
-/** System property used to set the base directory ( tomcat home )
+/** System property used to set the base directory ( tomcat home ).
+ * use -DTOMCAT_HOME= in java command line or System.setProperty.
+ *
+ * XXX This is a particular implementation detail of the interceptor
+ * that sets the "default" home - it shouldn't be required or
+ * specified in the core
*/
-public static final String TOMCAT_HOME=
- "tomcat.home";
+public static final String TOMCAT_HOME="tomcat.home";
// State
-/** Server is not initialized
+/** Server is not initialized. You can add interceptors and contexts,
+ * but no hook will be called, tomcat will just store the information.
+ * The connectors are not activated.
+ *
+ * Tomcat will be in this state when started and after shutdown()
+ * is called. Shutdown will also call the engineShutdown() hooks.
*/
public static final int STATE_PRE_INIT=0;
-/** Server was initialized, engineInit() was called.
- addContext() can be called.
+
+/** Server is initialized, engineInit() was called.
+ *
+ * On this state, the addContext hook can be called on all contexts added.
+ * ( but the context will be initialized only when tomcat starts )
+ *
+ * The context will be in this state after init() is called or
+ * after stop() is called ( after it was in START state )
+ *
*/
public static final int STATE_INIT=1;
-/** Engine is running. All configured contexts are
- initialized ( contextInit()), and requests can be served.
+/** Engine is running.
+ * The contextInit() hook can be called for all added contexts,
+ * and requests will be processed normally.
*/
public static final int STATE_START=2;
-/** Engine has stoped
- */
-public static final int STATE_STOP=3;
-
// local variables
private int state=STATE_PRE_INIT;
@@ -222,8 +234,6 @@
private int debug=0;
-// Global properties for this tomcat instance:
-
/** Private workspace for this server
*/
private String workDir;
@@ -244,7 +254,7 @@
// the embedding application loader. @see getParentLoader
private ClassLoader parentLoader;
-// Store Loggers before initializing them
+// Store Loggers that are used in this server
private Hashtable loggers;
/**
@@ -321,6 +331,8 @@
// Other properties
+/** Return the current state of the tomcat server.
+ */
public final int getState() {
return state;
}
@@ -370,6 +382,9 @@
defaultContainer = newDefaultContainer;
}
+/** Add a global interceptor. It's hooks will be called for
+ * all requests.
+ */
public final void addInterceptor( BaseInterceptor ri ) {
// The interceptors are handled per/container ( thanks to Nacho
// for this contribution ).
@@ -498,7 +513,12 @@
// Contexts
-/** Return the list of contexts managed by this server
+/** Return the list of contexts managed by this server.
+ * Tomcat can handle
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/util BuffTool.java
costin 00/12/04 22:30:16
Modified:src/share/org/apache/tomcat/modules/server Ajp13.java
Removed: src/share/org/apache/tomcat/util BuffTool.java
Log:
Check in the excelent patch submited by Dan Milstein.
Remove the BufTool - it's no longer needed, all the encoding that was
specific to ajp13 is now part of Ajp13Packet.
( the general purpose byte parsing will show up in a different tool, to be used
by all components that are working on the byte[] - I have it almost
done as a rewrite of MessageBytes )
Submitted by: Dan Milstein [EMAIL PROTECTED]
Revision ChangesPath
1.6 +400 -187
jakarta-tomcat/src/share/org/apache/tomcat/modules/server/Ajp13.java
Index: Ajp13.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/modules/server/Ajp13.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- Ajp13.java2000/11/30 04:58:45 1.5
+++ Ajp13.java2000/12/05 06:30:15 1.6
@@ -59,27 +59,51 @@
package org.apache.tomcat.modules.server;
-import java.io.*;
-import java.net.*;
-import java.util.*;
-import org.apache.tomcat.core.*;
-import org.apache.tomcat.util.*;
-
+import java.io.IOException;
+import java.io.UnsupportedEncodingException;
+import java.io.InputStream;
+import java.io.OutputStream;
+import java.net.Socket;
+import java.util.Enumeration;
+
+import org.apache.tomcat.core.Request;
+import org.apache.tomcat.util.MimeHeaders;
+import org.apache.tomcat.util.MessageBytes;
+
+/**
+ * Represents a single, persistent connection between the web server and
+ * the servlet container. Uses the Apache JServ Protocol version 1.3 for
+ * communication. Because this protocal does not multiplex requests, this
+ * connection can only be associated with a single request-handling cycle
+ * at a time.P
+ *
+ * This class contains knowledge about how an individual packet is laid out
+ * (via the internal CODEAjp13Packet/CODE class), and also about the
+ * stages of communicaton between the server and the servlet container. It
+ * translates from Tomcat's internal servlet support methods
+ * (e.g. doWrite) to the correct packets to send to the web server.
+ *
+ * @see Ajp13Interceptor
+ */
public class Ajp13
{
public static final int MAX_PACKET_SIZE=8192;
-public static final int H_SIZE=4;
+public static final int H_SIZE=4; // Size of basic packet header
public static final int MAX_READ_SIZE = MAX_PACKET_SIZE - H_SIZE - 2;
public static final int MAX_SEND_SIZE = MAX_PACKET_SIZE - H_SIZE - 4;
+// Prefix codes for message types from server to container
public static final byte JK_AJP13_FORWARD_REQUEST = 2;
public static final byte JK_AJP13_SHUTDOWN = 7;
+// Prefix codes for message types from container to server
public static final byte JK_AJP13_SEND_BODY_CHUNK = 3;
public static final byte JK_AJP13_SEND_HEADERS = 4;
public static final byte JK_AJP13_END_RESPONSE = 5;
+public static final byte JK_AJP13_GET_BODY_CHUNK= 6;
+// Integer codes for common response header strings
public static final int SC_RESP_CONTENT_TYPE= 0xA001;
public static final int SC_RESP_CONTENT_LANGUAGE= 0xA002;
public static final int SC_RESP_CONTENT_LENGTH = 0xA003;
@@ -91,11 +115,10 @@
public static final int SC_RESP_SERVLET_ENGINE = 0xA009;
public static final int SC_RESP_STATUS = 0xA00A;
public static final int SC_RESP_WWW_AUTHENTICATE= 0xA00B;
-
-public static final byte JK_AJP13_GET_BODY_CHUNK = 6;
-public static final byte SC_A_CONTEXT = 1;
-public static final byte SC_A_SERVLET_PATH = 2;
+// Integer codes for common (optional) request attribute names
+public static final byte SC_A_CONTEXT = 1; // XXX Unused
+public static final byte SC_A_SERVLET_PATH = 2; // XXX Unused
public static final byte SC_A_REMOTE_USER = 3;
public static final byte SC_A_AUTH_TYPE = 4;
public static final byte SC_A_QUERY_STRING = 5;
@@ -103,9 +126,14 @@
public static final byte SC_A_SSL_CERT = 7;
public static final byte SC_A_SSL_CIPHER= 8;
public static final byte SC_A_SSL_SESSION = 9;
-public static final byte SC_A_REQ_ATTRIBUTE = 10;
+
+// Used for attributes which are not in the list above
+public static final byte SC_A_REQ_ATTRIBUTE = 10;
+
+// Terminates list of attributes
public static final byte SC_A_ARE_DONE = (byte)0xFF;
+// Translates integer codes to names of HTTP methods
public static final String []methodTransArray = {
"OPTIONS",
"GET",
@@
cvs commit: jakarta-tomcat/src/doc AJPv13.html
costin 00/12/04 22:32:13 Added: src/doc AJPv13.html Log: Added the initial version of the AJP13 doc submited by Dan Milstein. I'll keep it in sync ( by commiting any change Dan is doing ), at least until Dan becomes a commiter himself :-) Submitted by: Dan Milstein [EMAIL PROTECTED] Revision ChangesPath 1.1 jakarta-tomcat/src/doc/AJPv13.html Index: AJPv13.html === HTML HEAD TITLEApache JServ Protocol version 1.3/TITLE /HEAD BODY BGCOLOR="#FF" H1 ALIGN=CENTERApache JServ Protocol version 1.3/H1 P DIV ALIGN=CENTER Dan Milstein, A HREF="mailto:[EMAIL PROTECTED]"[EMAIL PROTECTED]/A, December 2000. /DIV P This describes the Apache JServ Protocol version 1.3 (hereafter Bajp13/B). There is, apparently, no current documentation of how the protocol works. This document is an attempt to remedy that, in order to make life easier for maintainers of mod_jk, and for anyone who wants to port the protocol somewhere (into jakarta 4.x, for example). PBWho Am I?/B BRI am not one of the designers of this protocol -- I believe that Gal Shachor was the original designer. Everything in this document is derived from the actual implementation I found in the tomcat 3.x code. I hope it is useful, but I can't make any grand claims to perfect accuracy. I also don't know why certain design decisions were made. Where I was able, I've offered some possible justifications for certain choices, but those are only my guesses. In general, the C code which Shachor wrote is very clean and comprehensible (if almost totally undocumented). The Java code is pretty much a mess. P BDesign Goals/B BR According to email from Gal Shachor to the jakarta-dev mailing list, the original goals of Bmod_jk/B (and thus Bajp13/B) were to extend Bmod_jserv/B and Bajp12/B by (I am only including the goals which relate to communication between the web server and the servlet container): OL LI Increasing performance (speed, specifically).P LI Adding support for SSL, so that CODEisSecure()/CODE and CODEgeScheme()/CODE will function correctly within the servlet container. The client certificates and cipher suite will be available to servlets as request attributes.P /OL P BOverview/B BR The Bajp13/B protocol is packet-oriented. A binary format was presumably chosen over the more readable plain text for reasons of performance. The web server communicates with the servlet container over TCP connections. To cut down on the expensive process of socket creation, the web server will attempt to maintain persistent TCP connections to the servlet container, and to reuse a connection for multiple request/response cycles. P Once a connection is assigned to a particular request, it will not be used for any others until the request-handling cycle has terminated. In other words, requests are not multiplexed over connections. This makes for much simpler code at either end of the connection, although it does cause more connections to be open at once. P Once the web server has opened a connection to the servlet container, the connection can be in one of the following states: UL LI Idle BR No request is being handled over this connection. P LI Assigned BR The connecton is handling a specific request. /UL P Once a connection is assigned to handle a particular request, the basic request informaton (e.g. HTTP headers, etc) is sent over the connection in a highly condensed form (e.g. common strings are encoded as integers). Details of that format are below in Request Packet Structure. If there is a body to the request (content-length 0), that is sent in a separate packet immediately after. P At this point, the servlet container is presumably ready to start processing the request. As it does so, it can send the following messages back to the web server: UL LISEND_HEADERS BRSend a set of headers back to the browser.P LISEND_BODY_CHUNK BRSend a chunk of body data back to the browser.P LIGET_BODY_CHUNK BRGet further data from the request if it hasn't all been transferred yet. This is necessary because the packets have a fixed maximum size and arbitrary amounts of data can be included the body of a request (for uploaded files, for example). (Note: this is unrelated to HTTP chunked tranfer).P LIEND_RESPONSE BR Finish the request-handling cycle. /UL Each message is accompanied by a differently formatted packet of data. See Response Packet Structures below for details. BR BR HR BR H2Basic Packet Structure/H2 PThere is a bit of an XDR heritage to this protocol, but it differs in lots of ways (no 4 byte alignment, for example). PByte order: I am not clear
