Re: Realm implementations
Craig, Thanks for your comments. Craig R. McClanahan wrote: On Fri, 4 May 2001, Antony Bowesman wrote: Hi, In TC 3.x authenticate() method of a realm is called for every request. (I gather this is changed in 4.x). You are correct. Tomcat 4 caches the user Principal object returned by the authenticate() method in the user's session. If the application calls request.isUserInRole() -- or the container is enforcing security constraints -- you may or may not have to go back to the underlying security realm to look up the role information, depending on how you've implemented things. All the current Realm implementations cache the assigned roles along with the user Principal as well. Will you be adding a cachable JAAS Subject or LoginContext into TC4 at any stage, this would move it a little closer to JAAS? I am assuming the RequestImpl is a per HTTP session object. Is this correct? So, each different HTTP session will get a different RequestImpl? Actually, RequestImpl is per *request*, not per *session*. In Tomcat 4, the caching actually happens in the session implementation object (it's in the internal Tomcat part of the API). If so, when HTTP session times out the authentication for that user is lost. Is it possible to keep the HTTP session alive beyond the configured timeout through some keep alive mechanism? I have a logical session that is container independent and there may have been activity on that session that is not related to the HTTP session and so I want to prevent Tomcat from losing the authenticated context. Keeping the session alive (beyond the normal timeout mechanism) would require tweaking the way that Tomcat does session expiration. If you want to keep something alive beyond the lifetime of a session, it sounds like you might need to store the actual objects elsewhere (perhaps in a collection stored as a session context attribute), and maintain references to them as session attributes. You could use HttpSessionBindingListener events to know when session references to the underlying EJB session objects are added or subtracted. This would also let you share an EJB session across multiple HTTP sessions, if that was appropriate for your requirements. Actually, our session is an 'overlying' session. It is not specific to any container and is available in ORB, EJB, WEB or standalone Java app so I guess we will set session timeout to -1 and allow our session to invalidate the HttpSession when it times out. Rgds Antony -- Antony Bowesman Teamware Group [EMAIL PROTECTED] tel: +358 9 5128 2562 fax: +358 9 5128 2705
Re: Realm implementations
Hi Costin, Thanks for your comments. [EMAIL PROTECTED] wrote: Hi Antony, In TC 3.x authenticate() method of a realm is called for every request. Well, yes and no. The BaseInterceptor.authenticate() callback is called on every request ( as it is on Apache and other servers ). The authenticate method of the realm ( that goes to a database or does expensive operations ) should be called once - and the result cached by the module ( either in session, or in a local cache ). We don't do this for the simple realm - but we should. When you talk about caching it in the session I would understand that I need to call req.getSession(true) to ensure a session is available. With form authentication the session is present as the j_* fields are in it but for BASIC there is no session so I will have to create one. I'd rather not cache in the realm as I then have to start worrying about cleaning out old authentications when the HttpSessio expires. A particular case is the authentication module - I expect tomcat to be integrated in different systems, and I doubly the simple realm will be used for anything but development. So there is no point in optimizing it, Agreed. I would rather spend time on specialized modules that can be used in production environment ( and JAAS is probably the most important one, since it could be integrated with PAM and give access to most auth schemes). Yes, it seems Tomcat has to move towards directly supporting JAAS as that is the way J2EE 1.3 and JDK1.4 are moving. Another big priority is a module that delegates the auth to apache - but we have to wait for ajp14 for that. I am implementing a JAAS Realm which authenticates against a back end EJB user realm. I want to avoid this authentication for every request so I have done the following in authenticate() I would cache it inside the session ( if any ) - that's the most common case ( most people use sessions and authentication ). If you want to deal with the 10% special cases you could maintain a local cache to avoid calling the JAAS for each request. In 3.2.2b4 it is changed (same as 3.3) and now returns null if there is no principal. So, it is sufficient to do this in authenticate()? I think that's the correct behavior. I am assuming the RequestImpl is a per HTTP session object. Is this correct? So, each different HTTP session will get a different RequestImpl? No, that's almost impossible. The session is detected long after the request is received ( and you could have cases where you have multiple requests on the same time in the same session - think about a page with images ). You need to use req.getSession(false). (and keep in mind that authentication doesn't require session, even if most of the time they are used togheter !) If so, when HTTP session times out the authentication for that user is lost. Is it possible to keep the HTTP session alive beyond the configured timeout through some keep alive mechanism? I have a logical session that is container independent and there may have been activity on that session that is not related to the HTTP session and so I want to prevent Tomcat from losing the authenticated context. I don't know if it would be a good idea. If you really want to keep the security context longer you should use your own cache, and let the session work as it is supposed to. ( and it shouldn't be very difficult ). Please let us know how this project evolves - I'm very interested in JAAS authentication for tomcat, as an add-on module. Costin Best regards Antony -- Antony Bowesman Teamware Group [EMAIL PROTECTED] tel: +358 9 5128 2562 fax: +358 9 5128 2705
Re: [PROPOSAL Tomcat 4.x] Cluster
Bip Thelin typed the following on 04:06 PM 5/6/2001 -0700 We also need to answer the question of the request life cycle: the DistributedManager needs to know when a request begins and ends. At the beginning, it must lock the session to prevent other Catalina instances from using it in requests. This can probably just be done in Manager.findSession(). At the end, it must tell the ClusterStore to update the session to other members of the Cluster, and unlock it. I'm not really sure what you're saying here. OK, ignore my use of the term ClusterStore - I was melding the Store and Cluster concepts, but from your comments I see that we may want to be able to use both in the same setup. My point is that the Manager/Cluster needs to know when the session is in use by another instance of Catalina. A locking mechanism must be implemented by the Cluster (or whatever) to prevent a session from being used by multiple instances at once. This mechanism will require the Manager/Cluster system to know when a request begins using a session, and when it has finished. If we say that only one JVM at a time can manipulate a sessions since a sessions only belongs to one machine at a time the only time a session needs to be replicated is when it's created/changed/destroyed. Yes. But putting the session into the Cluster at creation time is unnecessary. It should be put in at the end of the request when it is created (other Catalina instances can't use it before then anyway), and updated at the end of each subsequent request. So we need to have the end of a request call into the Manager to indicate that the session can be sent to the Cluster and unlocked for use. I'd rather see the replication be implemented in a Manager(i.e. DistributedManager or maybe change name to MulticastDistributedManager) thus making it possible to run any Store with the DistributedManager(i.e. FileStore). OK, I take your point that extending Store isn't the way to go. But I don't think we should have a different Manager implementation for each available distribution mechanism - MulticastDistributedManager, JMSDistributedManager, JavaSpacesDistributedManager, JCacheDistributedManager, etc. We should use the same pattern that Manager/Store uses: a single DistributedManager should be implemented which is independent of the actual session sharing mechanism. It should be able to use any implementation of the Cluster interface. I'd like to keep the possibility open to implement different distribution strategies. The strategy we're looking at now is for each instance of the application to hold copies of every session. An alternative Cluster strategy would keep the sessions in a central location such as a database: when a request comes in for a session not found in the current instance, the Cluster checks the database to see if it's there. This isn't too different from simply using JDBCStore. A third way is to have just two instances of the application holding a given session: when instance A creates the session, the Cluster chooses instance B to hold a backup copy in case A goes down: if a request comes in to C, B still has it available. Not that we need to implement all of these, but the architecture we build now should allow these possibilities and others. Other people can try out different ideas, and users can choose the system best suited to their needs. I'm also not sure about the issues with using persistence and distribution simultaneously. If we simply use PersistentManager with this distribution code, each instance will save its own copy of every session to persistent storage. This might be desirable in some cases - I can see using FileStore, for instance. But if you use JDBCStore and the Multicast distribution, it's wasteful - with a 4 server farm, we have 4 copies of each session in the database. So how should this be addressed? Cluster ought to have some mechanism which (optionally) ensures that each session is only persisted once. This may mean having Cluster override Store functionality, which is why I was thinking of combining the two. Kief
RE: bug 235, request problem
The bug 235 is fixed for some times now, but was incorrectly marked as open. I'm also using Apache 1.3.19 (with mod_ssl 2.8.2) and TC 3.2.2b4 or TC 3.3 from CVS. I'm using ajp13 (and ajp12) and got no problem (I got the correct user and auth type :!!!) -Henri Gomez ___[_]EMAIL : [EMAIL PROTECTED] (. .)PGP KEY : 697ECEDD ...oOOo..(_)..oOOo...PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 -Original Message-From: Peter Meijer [mailto:[EMAIL PROTECTED]]Sent: Monday, May 07, 2001 8:55 AMTo: [EMAIL PROTECTED]Subject: bug 235, request problem Dear subscribers, I've recently encountered a problem regarding to the mod_jk connector. When I used Basic Authentication withthe Apache server (1.3.19) andtried to get the name of the user who has logged in, I get an old username from someone who had logged in a couple of hours ago. I have Tomcat version 3.2 installed to use Java. When I printed the headers of the request and the request.getPrincipal().getName(), the latter keeps changing the authenticated username in my loginname and of someone else, while the request headers keeps the same. I was wondering if this was due to bug 235? If so, in which release is this bug fixed? If not, maybe someone could tell me where to find a solution to this problem. Thanks in advance, Sogyo, Masters in e-Technology (www.sogyo.nl)Peter Meijer
cvs commit: jakarta-tomcat/src/doc readme
marcsaeg01/05/07 06:34:36 Modified:.Tag: tomcat_32 RELEASE-NOTES src/doc Tag: tomcat_32 readme Log: Some final updates to the release notes. Revision ChangesPath No revision No revision 1.1.2.6 +7 -14 jakarta-tomcat/Attic/RELEASE-NOTES Index: RELEASE-NOTES === RCS file: /home/cvs/jakarta-tomcat/Attic/RELEASE-NOTES,v retrieving revision 1.1.2.5 retrieving revision 1.1.2.6 diff -u -r1.1.2.5 -r1.1.2.6 --- RELEASE-NOTES 2001/04/30 13:18:59 1.1.2.5 +++ RELEASE-NOTES 2001/05/07 13:34:25 1.1.2.6 @@ -1,4 +1,4 @@ -$Id: RELEASE-NOTES,v 1.1.2.5 2001/04/30 13:18:59 marcsaeg Exp $ +$Id: RELEASE-NOTES,v 1.1.2.6 2001/05/07 13:34:25 marcsaeg Exp $ Release Notes for: @@ -173,15 +173,8 @@ its experimental nature, and the extra overhead required to perform the necessary checks on every request. -6.5 Returned strings from getServletPath, getPathInfo, and getPathTranslated +6.5 Avoiding Out of environment space errors on Windows 95/98 -The Servlet 2.2 Errata - April 27, 2000 specifies that HttpServletRequest -methods getServletPath, getPathInfo, and getPathTranslated should return -decoded strings. This clarification has not been implemented in Tomcat 3.2. -In Tomcat 3.2, these methods return encoded strings. - -6.6 Avoiding Out of environment space errors on Windows 95/98 - This error can easily occur since the default amount of environment space is typically insufficient to run Tomcat. Here are a couple of ways to avoid it. @@ -212,7 +205,7 @@ line to your autoexec.bat or to the startup.bat and shutdown.bat files themselves. -6.7 URL's are now case sensitive on all operating systems +6.6 URL's are now case sensitive on all operating systems As of Tomcat 3.2, URL's are case sensitive for all operating systems, including operating systems which have case insensitive file systems, such as @@ -241,7 +234,7 @@ Tomcat, then invoking those links would carry the mismatched case to Tomcat where it cause the resource not to be found. -6.8 Generated Configuration Files for Web Connectors +6.7 Generated Configuration Files for Web Connectors At startup time, Tomcat normally generates configuration files like tomcat-apache.conf to reflect the contexts that are defined. However, the @@ -254,7 +247,7 @@ and will be addressed by the introduction of the MOD_WARP connector in Tomcat 4.0. -6.9 Limitation on Form Based Login +6.8 Limitation on Form Based Login If the pages you specify for form-login-page or form-error-page are within the area protected by a security constraint, Tomcat 3.2 will be unable to @@ -267,7 +260,7 @@ or more subdirectories, and establish security constraints to protect the subdirectories. -6.10 Limitation on Document Base Paths +6.9 Limitation on Document Base Paths Tomcat 3.2 is unable to support Windows SMB paths in a Context directive like this: @@ -282,7 +275,7 @@ where r: is mapped to this share. -6.11 Resource Paths Can't Contain URL Escapes +6.10 Resource Paths Can't Contain URL Escapes The path passed to javax.servlet.Context.getResource() and javax.servlet.Context.getResrouceAsStream() cannot contain URL escapes of No revision No revision 1.8.2.18 +7 -14 jakarta-tomcat/src/doc/readme Index: readme === RCS file: /home/cvs/jakarta-tomcat/src/doc/readme,v retrieving revision 1.8.2.17 retrieving revision 1.8.2.18 diff -u -r1.8.2.17 -r1.8.2.18 --- readme2001/04/30 13:18:59 1.8.2.17 +++ readme2001/05/07 13:34:32 1.8.2.18 @@ -1,4 +1,4 @@ -$Id: readme,v 1.8.2.17 2001/04/30 13:18:59 marcsaeg Exp $ +$Id: readme,v 1.8.2.18 2001/05/07 13:34:32 marcsaeg Exp $ Release Notes for: @@ -173,15 +173,8 @@ its experimental nature, and the extra overhead required to perform the necessary checks on every request. -6.5 Returned strings from getServletPath, getPathInfo, and getPathTranslated +6.5 Avoiding Out of environment space errors on Windows 95/98 -The Servlet 2.2 Errata - April 27, 2000 specifies that HttpServletRequest -methods getServletPath, getPathInfo, and getPathTranslated should return -decoded strings. This clarification has not been implemented in Tomcat 3.2. -In Tomcat 3.2, these methods return encoded strings. - -6.6 Avoiding Out of environment space errors on Windows 95/98 - This error can easily occur since the default amount of environment
About bug#208
Hi, The BUG #208 (request.getRemoteHost() returns empty string when using mod_jk BugRat Report#320) is still there (3.2.2b4). The difference is that when we're using ajp12, getRemoteHost = and in ajp13, getRemoteHost = null. The fix is easy the getRemoteAddr() is allways set but : - Did we want to Tomcat ask the DNS to resolve the name since it may be time consuming ? - ajp12 return empty string, ajp13 return null, what solution is recommanded in that case ? I also suspect TC 3.3 to have the same kind of problem ;( - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 -Original Message- From: GOMEZ Henri [mailto:[EMAIL PROTECTED]] Sent: Monday, May 07, 2001 2:40 PM To: [EMAIL PROTECTED] Subject: [PROPOSAL AJP14] AJP13 Evolution Hi to all, You could find attached a proposal of evolution to the current Apache JServ Protocol version 1.3, also known as ajp13. Let start the comments, questions, remarks cycle. PS : I've not cover here the full protocol but only the add-on from ajp13. - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6
About bug#421
The BUG#421 could also be closed in 3.2.2 (no more in 3.3) (Code inspections shows that the definition of `jk_pool_atom_t' is conditional on some CPP macro that shows what the OS is: clearly on this system, the macro should be SOLARIS, but that isn't defined anywhere. apxs however defines a SOLARIS2 macro.) The fix is : --- src/native/jk/jk_pool.h.origMon May 7 16:08:04 2001 +++ src/native/jk/jk_pool.h Mon May 7 16:08:21 2001 @@ -91,6 +91,8 @@ typedef long long jk_pool_atom_t; #elif defined(NETWARE) typedef long long jk_pool_atom_t; +#else +typedef long long jk_pool_atom_t; #endif /* Could I commit it Marc ?
Re: [PROPOSAL AJP14] AJP13 Evolution
Henri, Lots of good stuff. A few ideas/possibilities: 1) We've talked about specifying a response packet to indicate that the engine (or the web server) doesn't recognize a packet sent over. This would allow us much more flexiblity to add packet types to ajpv14, without having to make ajpv15,16, etc. 2) What about specifying a separate, out of band control socket connection? If the web server opened up two connections, 1 for data, one for control, then we could have much better communication from the engine to the server (if it was shutting down contexts, for example). We could also have a heartbeat without interfering with the data channel. -Dan GOMEZ Henri wrote: Hi to all, You could find attached a proposal of evolution to the current Apache JServ Protocol version 1.3, also known as ajp13. Let start the comments, questions, remarks cycle. PS : I've not cover here the full protocol but only the add-on from ajp13. - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 Name: AJPv14.txt AJPv14.txtType: Plain Text (text/plain) Encoding: quoted-printable -- Dan Milstein // [EMAIL PROTECTED]
Can't close BUG#132
No Component define ? - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6
[Bug 132] New - No workers found when trying to access jsp or servlet through mod_jk and apache BugRat Report#148
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=132 *** shadow/132 Mon May 7 07:32:33 2001 --- shadow/132.tmp.16461Mon May 7 07:32:33 2001 *** *** 0 --- 1,33 + ++ + | No workers found when trying to access jsp or servlet through mod_jk and a | + ++ + |Bug #: 132 Product: Tomcat 3| + | Status: UNCONFIRMED Version: 3.2.1 Final | + | Resolution:Platform: All | + | Severity: Normal OS/Version: All | + | Priority: High Component: Connectors | + ++ + | Assigned To: [EMAIL PROTECTED] | + | Reported By: [EMAIL PROTECTED]| + | CC list: Cc: | + ++ + | URL: | + ++ + | DESCRIPTION | + This seems to be a serious problem, atleast on my platform + as no jsp/servlet pages can be served through apache while + expiriencing this condition. + + When accessing a jsp page through apache i get the following error in jk.log + [jk_worker.c (123)]: Into wc_get_worker_for_name ajp12 + [jk_worker.c (127)]: wc_get_worker_for_name, done did not found a worker + + I can access the same .jsp through tomcat when accessing it + directly. + + When apache is started jk_post_config NULL is written st + stdout. i checked the source and i assume that WAS_BORN_BY_APACHE + is not accessible to mod_jk. This leads to mod_jk being started without any workers +initialized. + + --- Additional Comments From [EMAIL PROTECTED] 2001-05-07 07:32 --- + Fixed since 3.2.1 and in 3.3
RE: [PROPOSAL AJP14] AJP13 Evolution
Lots of good stuff. A few ideas/possibilities: Happy to see you allready read it Dan :) 1) We've talked about specifying a response packet to indicate that the engine (or the web server) doesn't recognize a packet sent over. This would allow us much more flexiblity to add packet types to ajpv14, without having to make ajpv15,16, etc. Could you develop ? 2) What about specifying a separate, out of band control socket connection? If the web server opened up two connections, 1 for data, one for control, then we could have much better communication from the engine to the server (if it was shutting down contexts, for example). We could also have a heartbeat without interfering with the data channel. Good idea, but how could we be sure that we'll have only one control channel to a given servlet engine ? In multi-threaded environnement like Apache 2.0, it's easy to launch a thread to handle that, but in Apache 1.3 will have no others choice than having each child (forked) opening it's own control connection since each child is forked and so have it's own copy of 'servlet-engine infos But I like this approach of splitting data and control. -Dan GOMEZ Henri wrote: Hi to all, You could find attached a proposal of evolution to the current Apache JServ Protocol version 1.3, also known as ajp13. Let start the comments, questions, remarks cycle. PS : I've not cover here the full protocol but only the add-on from ajp13. - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 --- - Name: AJPv14.txt AJPv14.txtType: Plain Text (text/plain) Encoding: quoted-printable -- Dan Milstein // [EMAIL PROTECTED]
nagoya / bug closing problems
Can't close Bug#354 since there is not Components defined. Same problem for Bug#421 There are both duplicate of bug #1343 we could fix by : --- src/native/jk/jk_pool.h.origMon May 7 16:08:04 2001 +++ src/native/jk/jk_pool.h Mon May 7 16:08:21 2001 @@ -91,6 +91,8 @@ typedef long long jk_pool_atom_t; #elif defined(NETWARE) typedef long long jk_pool_atom_t; +#else +typedef long long jk_pool_atom_t; #endif /* Who could fix the connector miss ?
RE: nagoya / bug closing problems - fixed
Oups, I succeed in marking as duplicate of bug #1343 the bug #354/#421 which no wait the following patch to be applied in 3.2.2 branch --- src/native/jk/jk_pool.h.orig Mon May 7 16:08:04 2001 +++ src/native/jk/jk_pool.hMon May 7 16:08:21 2001 @@ -91,6 +91,8 @@ typedef long long jk_pool_atom_t; #elif defined(NETWARE) typedef long long jk_pool_atom_t; +#else +typedef long long jk_pool_atom_t; #endif /*
.zip lib files
All, In tomcat.bat, there is logic that dynamically loads .jar files from the lib directory. Should this be extended to include .zip files as well, since some vendors distribute libs with the .zip extension? For example, Oracle distributes their jdbc thin client driver as: classes12_01.zip I don't believe it would be a standards issue, since the lib directory is Tomcat specific. :dynClasspath set _LIBJARS= for %%i in (%TOMCAT_HOME%\lib\*.jar) do call %TOMCAT_HOME%\bin\cpappend.bat %%i if not %_LIBJARS% == goto gotLibJars Any objection to adding the following line? set _LIBJARS=%_LIBJARS% for %%i in (%TOMCAT_HOME%\lib\*.zip) do call %TOMCAT_HOME%\bin\cpappend.bat %%i Jonathan
Web application in J2ee under default context
In J2EE -tomcat while creating a web application with context / (default) Iam unable invoke my servlets/jsp as desired(http://domain.com/xxx.jsp) but only by putting this way(http://domain.com///xxx.jsp)Is there any solution..or work around?? __ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/
RE: About bug#208
According to the JavaDoc for ServletRequest.getRemoteHost() Returns the fully qualified name of the client that sent the request, or the IP address of the client if the name cannot be determined. For HTTP servlets, same as the value of the CGI variable REMOTE_HOST. Based on that I would say that both implementations are wrong, you should never get an empty or a null value back. I would also argue strongly against having tomcat do any reverse DNS look ups. If the web server doesn't tell us the remote host name just use the IP address. -Original Message- From: GOMEZ Henri [mailto:[EMAIL PROTECTED]] Sent: Monday, May 07, 2001 9:00 AM To: [EMAIL PROTECTED] Subject: About bug#208 Hi, The BUG #208 (request.getRemoteHost() returns empty string when using mod_jk BugRat Report#320) is still there (3.2.2b4). The difference is that when we're using ajp12, getRemoteHost = and in ajp13, getRemoteHost = null. The fix is easy the getRemoteAddr() is allways set but : - Did we want to Tomcat ask the DNS to resolve the name since it may be time consuming ? - ajp12 return empty string, ajp13 return null, what solution is recommanded in that case ? I also suspect TC 3.3 to have the same kind of problem ;( - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 -Original Message- From: GOMEZ Henri [mailto:[EMAIL PROTECTED]] Sent: Monday, May 07, 2001 2:40 PM To: [EMAIL PROTECTED] Subject: [PROPOSAL AJP14] AJP13 Evolution Hi to all, You could find attached a proposal of evolution to the current Apache JServ Protocol version 1.3, also known as ajp13. Let start the comments, questions, remarks cycle. PS : I've not cover here the full protocol but only the add-on from ajp13. - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6
RE: class reloading
On Mon, 7 May 2001, Kevin Jones wrote: Printing out the value of 'pathname' just before this code executes gives jndi:/localhost/AddressBook/WEB-INF/classes\com\develop\ewebjava\ lab\Browse .class, which means that the 'file' doesn't exist and so doesn't get added to the cache. Should that 'jndi:/localhost' be there ? I take it from the silence that this behaviour is expected and that I should not be able to do any reloading? Remy answered with some patches, and I asked last week if that fixed the reloading for you. Have you tried it with the latest nightly builds? Kevin Jones DevelopMentor www.develop.com Craig
RE: Problems building the Mod_jk.so
We're tring to build the mod_jk.so on solaris 7 but, we have the following error: cc -DEAPI -DMOD_PERL -DUSE_EXPAT -O -G -Kpic -I/usr/apache/include -I../jk -I/us r/java/include -I/usr/java/include/solaris -DSOLARIS -c mod_jk.c /usr/ucb/cc: language optional software package not installed apxs:Break: Command failed with rc=65536 we don't know how install the language package. Strange, what's this language package ? I'm not a Solaris specialist, only Linux Hacker :) If you know other location where we can find the mod_jk.so without compiling it, it will be a good for us. I suggest you to mail the question to the user list
RE: About bug#208
On Mon, 7 May 2001, Marc Saegesser wrote: According to the JavaDoc for ServletRequest.getRemoteHost() Returns the fully qualified name of the client that sent the request, or the IP address of the client if the name cannot be determined. For HTTP servlets, same as the value of the CGI variable REMOTE_HOST. Based on that I would say that both implementations are wrong, you should never get an empty or a null value back. Agreed. You should get either a host name or an IP address (in string form). I would also argue strongly against having tomcat do any reverse DNS look ups. If the web server doesn't tell us the remote host name just use the IP address. That works for the web-connected case. If you're running Tomcat stand-alone you need to be able to do the lookup. In 4.0, that is only done if the web app actually calls getRemoteHost(), so you don't pay the performance hit unless you ask for it. Craig
whitespace jsp stripper, gzip encoding
Hi all, This is my first message to this list. I made a mod to my copy of CharDataGenerator.java in the jsp engine that condenses whitespace, making the generated jsp code and the html that's sent to the client smaller. I think this might be something other people might like, and am wondering what I should do to submit it to the main branch? Also, I'd like to mod the jsp engine to be able to gzip the output if the client accepts it. I think this wouldn't be difficult if I better understood the way the engine works. I expect the hardest part is to determine how to handle different browsers stabily. Based on what I've seen in the mod_gzip apache threads, it's a little more involved than just checking the accept-encoding request header. Thanks, -Matt __ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/
[GUMP] Build Failure - Tomcat 3.x
This email is autogenerated from the output from: http://jakarta.apache.org/builds/gump/2001-05-07/jakarta-tomcat.html Buildfile: build.xml detect: msg.jdk12: [echo] Detected JDK1.2 msg.jsse: [echo] Detected JSSE init: prepare: [mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat/build/tomcat [mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat/build/tomcat/classes [mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat/build/tomcat/conf [mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat/build/tomcat/src [mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat/build/tomcat/lib [mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat/build/tomcat/lib/apps [mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat/build/tomcat/lib/container [mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat/build/tomcat/lib/common [mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat/build/tomcat/logs [mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat/build/tomcat/bin [mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat/build/tomcat/doc [mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat/build/tomcat/webapps [mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat/build/tomcat/native [copy] Copying 10 files to /home/rubys/jakarta/jakarta-tomcat/build/tomcat/bin [copy] Copying 19 files to /home/rubys/jakarta/jakarta-tomcat/build/tomcat/conf [copy] Copied 1 empty directory to /home/rubys/jakarta/jakarta-tomcat/build/tomcat/conf [copy] Copying 42 files to /home/rubys/jakarta/jakarta-tomcat/build/tomcat/doc [copy] Copied 1 empty directory to /home/rubys/jakarta/jakarta-tomcat/build/tomcat/doc [copy] Copying 89 files to /home/rubys/jakarta/jakarta-tomcat/build/tomcat/native [copy] Copied 13 empty directories to /home/rubys/jakarta/jakarta-tomcat/build/tomcat/native [copy] Copying 1 file to /home/rubys/jakarta/jakarta-tomcat/build/tomcat [copy] Copying 7 files to /home/rubys/jakarta/jakarta-tomcat/build/tomcat/bin [copy] Could not find file /home/rubys/jakarta/jakarta-ant/dist/lib/jaxp.jar to copy. BUILD FAILED /home/rubys/jakarta/jakarta-tomcat/build.xml:117: Could not find file /home/rubys/jakarta/jakarta-ant/dist/lib/jaxp.jar to copy. Total time: 7 seconds
RE: About bug#208
According to the JavaDoc for ServletRequest.getRemoteHost() Returns the fully qualified name of the client that sent the request, or the IP address of the client if the name cannot be determined. For HTTP servlets, same as the value of the CGI variable REMOTE_HOST. Based on that I would say that both implementations are wrong, you should never get an empty or a null value back. I would also argue strongly against having tomcat do any reverse DNS look ups. If the web server doesn't tell us the remote host name just use the IP address. Ok, I'll do accordingly. Did the 3.2.2 tree is closed ? -Original Message- From: GOMEZ Henri [mailto:[EMAIL PROTECTED]] Sent: Monday, May 07, 2001 9:00 AM To: [EMAIL PROTECTED] Subject: About bug#208 Hi, The BUG #208 (request.getRemoteHost() returns empty string when using mod_jk BugRat Report#320) is still there (3.2.2b4). The difference is that when we're using ajp12, getRemoteHost = and in ajp13, getRemoteHost = null. The fix is easy the getRemoteAddr() is allways set but : - Did we want to Tomcat ask the DNS to resolve the name since it may be time consuming ? - ajp12 return empty string, ajp13 return null, what solution is recommanded in that case ? I also suspect TC 3.3 to have the same kind of problem ;( - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 -Original Message- From: GOMEZ Henri [mailto:[EMAIL PROTECTED]] Sent: Monday, May 07, 2001 2:40 PM To: [EMAIL PROTECTED] Subject: [PROPOSAL AJP14] AJP13 Evolution Hi to all, You could find attached a proposal of evolution to the current Apache JServ Protocol version 1.3, also known as ajp13. Let start the comments, questions, remarks cycle. PS : I've not cover here the full protocol but only the add-on from ajp13. - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/service/connector Ajp12ConnectionHandler.java Ajp13ConnectorRequest.java
marcsaeg01/05/07 09:24:46
Modified:src/share/org/apache/tomcat/core Tag: tomcat_32
RequestImpl.java
src/share/org/apache/tomcat/service/connector Tag: tomcat_32
Ajp12ConnectionHandler.java
Ajp13ConnectorRequest.java
Log:
The implementation of ServletRequest.getRemoteHost() was not spec compliant.
In cases where the host is not known (e.g. AJP12 and AJP13) the returned
value was either an empty string or a null. These are both wrong. The spec
says that getRemoteHost() return the remote IP address if the host is not
known.
PR: 208
Revision ChangesPath
No revision
No revision
1.52.2.9 +4 -1
jakarta-tomcat/src/share/org/apache/tomcat/core/Attic/RequestImpl.java
Index: RequestImpl.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/core/Attic/RequestImpl.java,v
retrieving revision 1.52.2.8
retrieving revision 1.52.2.9
diff -u -r1.52.2.8 -r1.52.2.9
--- RequestImpl.java 2001/04/17 10:43:52 1.52.2.8
+++ RequestImpl.java 2001/05/07 16:24:34 1.52.2.9
@@ -813,7 +813,10 @@
}
public String getRemoteHost() {
- return remoteHost;
+// This is belt and suspenders. The request adapters should have set this
correctly.
+if(remoteHost == null || remoteHost.length() == 0)
+remoteHost = remoteAddr;
+return remoteHost;
}
/** Fill in the buffer. This method is probably easier to implement than
No revision
No revision
1.28.2.3 +3 -1
jakarta-tomcat/src/share/org/apache/tomcat/service/connector/Attic/Ajp12ConnectionHandler.java
Index: Ajp12ConnectionHandler.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/service/connector/Attic/Ajp12ConnectionHandler.java,v
retrieving revision 1.28.2.2
retrieving revision 1.28.2.3
diff -u -r1.28.2.2 -r1.28.2.3
--- Ajp12ConnectionHandler.java 2000/11/10 06:42:51 1.28.2.2
+++ Ajp12ConnectionHandler.java 2001/05/07 16:24:40 1.28.2.3
@@ -271,7 +271,9 @@
if( doLog ) log(AJP: RA= + remoteAddr );
remoteHost = ajpin.readString();//remote host
- if( doLog ) log(AJP: RH= + remoteHost );
+if(remoteHost.length() == 0)
+remoteHost = remoteAddr; // If host isn't specified then use IP
address
+if( doLog ) log(AJP: RH= + remoteHost );
remoteUser = ajpin.readString(null); //remote user
if( doLog ) log(AJP: RU= + remoteUser);
1.5.2.6 +5 -3
jakarta-tomcat/src/share/org/apache/tomcat/service/connector/Attic/Ajp13ConnectorRequest.java
Index: Ajp13ConnectorRequest.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/service/connector/Attic/Ajp13ConnectorRequest.java,v
retrieving revision 1.5.2.5
retrieving revision 1.5.2.6
diff -u -r1.5.2.5 -r1.5.2.6
--- Ajp13ConnectorRequest.java2001/02/14 22:19:55 1.5.2.5
+++ Ajp13ConnectorRequest.java2001/05/07 16:24:42 1.5.2.6
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/service/connector/Attic/Ajp13ConnectorRequest.java,v
1.5.2.5 2001/02/14 22:19:55 danmil Exp $
- * $Revision: 1.5.2.5 $
- * $Date: 2001/02/14 22:19:55 $
+ * $Header:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/service/connector/Attic/Ajp13ConnectorRequest.java,v
1.5.2.6 2001/05/07 16:24:42 marcsaeg Exp $
+ * $Revision: 1.5.2.6 $
+ * $Date: 2001/05/07 16:24:42 $
*
*
*
@@ -144,6 +144,8 @@
requestURI = msg.getString();
remoteAddr = msg.getString();
remoteHost = msg.getString();
+if(remoteHost == null) //If we don't have a host then use the IP
address
+remoteHost = remoteAddr;
serverName = msg.getString();
serverPort = msg.getInt();
bsc= msg.getByte();
RE: Problems building the Mod_jk.so
Your system is looking for the cc compiler, it does not ship with Solaris, that's why you get the error /usr/ucb/cc: language optional software package not installed Either install the cc compiler ($$) or gcc!! and change your Make setting to use gcc I usually do this on my Solaris systems after I install all the GNU software, mv /usr/ucb/cc to /usr/ucb/cc.orig # Works for a lot ln -s /usr/local/bin/gcc /usr/ucb/cc Hope that helps, PK -Original Message- From: GOMEZ Henri [mailto:[EMAIL PROTECTED]] Sent: May 7, 2001 11:55 AM To: [EMAIL PROTECTED] Subject: RE: Problems building the Mod_jk.so We're tring to build the mod_jk.so on solaris 7 but, we have the following error: cc -DEAPI -DMOD_PERL -DUSE_EXPAT -O -G -Kpic -I/usr/apache/include -I../jk -I/us r/java/include -I/usr/java/include/solaris -DSOLARIS -c mod_jk.c /usr/ucb/cc: language optional software package not installed apxs:Break: Command failed with rc=65536 we don't know how install the language package. Strange, what's this language package ? I'm not a Solaris specialist, only Linux Hacker :) If you know other location where we can find the mod_jk.so without compiling it, it will be a good for us. I suggest you to mail the question to the user list
RE: [PROPOSAL/VOTE] New Repositories for Collaborative Development
On Mon, 7 May 2001, GOMEZ Henri wrote: [snip] In TC 4.0, I think about the excellent works from Bip Thelin (TC 4.x Clustering). What make it specific to TC 4.x ? Here lies the crux of the difficulties in sharing significant code (beyond the kind of stuff you suggested for toolbox). I will try to provide some objective answers to this question -- there's plenty of subjective answers already available :-). * Dependence on the internal architecture of Catalina (i.e. the internal representations of Session, Manager, and so on). As has been clearly documented, this architecture is based on very different principles than 3.3 -- trying to create adaptators across these world views seems pretty challenging, and it would slow down 4.0 development for no apparent gain. * Dependence on Java2 as a base platform. This is not just an issue of using the collections classes (although that's part of it). Consider a few other issues: - If you run Tomcat 4.0 under a security manager, you have to put privileged blocks around some code segments. In order to make Tomcat 3.x run under JDK 1.1, you have to layer all of that stuff into optional classes that are used only in a Java2 runtime -- in 4.0 you can just code them directly. - As Commons matures, I'm going to be proposing switching to the Commons version of many standard utility classes. Many/most of these have Java2 dependencies. The same is true for lots of other external packges we might want to reuse. - Performance tuning for Java2 JVMs (particularly HotSpot) focuses your attention on different areas than JDK 1.1. Trying to optimize for both increases the effort required, and could lead to conflicts where you want to do things differently on different platforms. Working around Java2 dependencies is possible, but (again) is a very substantial amount of work. Where's the benefit? In contrario, why mod_jk from TC 3.3 couldn't be used in TC 4.x ? That's more feasible, but it also has a different set of issues: * Configuring the current generation of web connectors causes 90% of the user gripes about Tomcat. Anyone who needs evidence should subscribe to TOMCAT-USER and start answering all the questions about configuring. * The design assumption of the current generation of web connectors is that Apache will serve the static content. Unless the sysadmin is VERY careful in their configuration, this leads to violations of the servlet spec when static content is protected by a security constraint (2.2 and 2.3) or when filters should be invoked on static content (2.3). These problems are fixable -- but it's just a lot more work than simply porting a connector. Also shareable are all objects related to HTTP (cookies, messages, headers, ). Having smaller CVS, will also encourage new commiters contributing in area where they could be more at ease. Per my previous post, consider Commons for stuff that is not Tomcat specific at all. There are some very interesting developments on this directions with mod_jk and jasper. Focusing in this kind of thing is quite productive and puts some of the 3.3 people cooperating in the development of the 4.x version and vice versa. +1 I strongly think that merging the best of 3.3 and 4.0 could make an incredible Tomcat 5.0. Having Costin and Craig in the same team may be a dream but frankly what a bright combinaison. That's the way things were when I joined Sun 14 months ago. Costin opted to switch to a different project. Let's start by sharing what could be done, it will help identify what's the core and what could be modules (in reference to Apache http server no politics here :). Using 4.0 Valves and 3.3 modules didn't seems incompatible. There is many modules in 3.3 which are not related to Request/Response... Trying to force one of the groups out of its way will just fragment this project and take the 3.3 people somewhere else (SourceForge or so). Not sure it will force people to go somewhere else. Some may be just tired of political problem and stop contributing to ASF. That will be bad news for both groups, and there will be no winner in that case, the looser will be the OpenSource spirit. Besides developers and their own itches, there is another group whose interests ought to be considered - USERS of Tomcat. If you don't have any, then it becomes a much less interesting project to work on. And we've done a pretty good job at confusing people about what the Tomcat road map is. If the user community were to abandon Tomcat, it wouldn't matter much what we do on the development side. There isn't any compelling benefit (to the user community) to have two active development branches, once the next generation branch matures. The 4.0 container code is pretty stable (letting us focus now on performance improvements and feature adds). We could have had mod_jk ported a
Re: whitespace jsp stripper, gzip encoding
On Mon, 7 May 2001, Matt Jones wrote: Hi all, This is my first message to this list. I made a mod to my copy of CharDataGenerator.java in the jsp engine that condenses whitespace, making the generated jsp code and the html that's sent to the client smaller. I think this might be something other people might like, and am wondering what I should do to submit it to the main branch? Hi Matt, The best way to propose new enhancements like this would be to post the code to the developer list as diffs against the current code, as outlined on the Jakarta web site. http://jakarta.apache.org/site/source.html That way, we can all take a look, and it's easy to integrate if accepted. Also, I'd like to mod the jsp engine to be able to gzip the output if the client accepts it. I think this wouldn't be difficult if I better understood the way the engine works. I expect the hardest part is to determine how to handle different browsers stabily. Based on what I've seen in the mod_gzip apache threads, it's a little more involved than just checking the accept-encoding request header. A couple of notes on both of these ideas: * Sometimes, whitespace is significant to the receiver. Therefore, you would at least want to make this configurable. * Compressing whitespace violates a requirement of the JSP spec: all white space within the body text of a document is not significant, but is preserved (JSP 1.2 PFD, section 2.3 -- and I'm sure it was in previous versions as well). * Whitespace compression is nearly always done by modems (if your users are connected that way) and can easily be done by other network components. Thus, the benefits might not be as great as you would expect. * Both whitespace and GZIP compression seem like good candidates for being a Filter (see the Servlet 2.3 spec), rather than being embedded in the JSP engine where they cannot process output created by servlets. * As it happens, Tomcat 4.0 includes an example filter that does GZIP compression automatically, if the client indicates that they can accept it. Thanks, -Matt Craig
RE: [PROPOSAL/VOTE] New Repositories for Collaborative Development
On Mon, 7 May 2001, Craig R. McClanahan wrote: There seems to be consensus growing around these three names. Does that meet with everyone's agreement? If so, I can create the new repositories and set up the permissions stuff later today. +1 ( Regarding the name for the third: +0.7 for tomcat-contrib +0.5 for tomcat-toolbox -0.1 for tomcat-modules -1 for tomcat-sandbox ) PS: Just a note on toolbox -- if the stuff that might go here is independent of Tomcat itself, you might think about making it a Commons package instead of a Tomcat package. You'll find several other useful goodies already there. I think something like the web-based build tool or various modules ( i.e. things that work as interceptor or valves - with most of the code common to 3.x and 4.x ) should be toolbox-based for now. For utils - commons is the target destination, but I personally don't have too much time to spend on it. Costin
Re: [PROPOSAL AJP14] AJP13 Evolution
GOMEZ Henri wrote: Lots of good stuff. A few ideas/possibilities: Happy to see you allready read it Dan :) 1) We've talked about specifying a response packet to indicate that the engine (or the web server) doesn't recognize a packet sent over. This would allow us much more flexiblity to add packet types to ajpv14, without having to make ajpv15,16, etc. Could you develop ? I have an idea: To the LOGON COMP CMD from the WEB-SERVER (second message), Add a CString: WEB-SERVER INFO The string could be something like: Apache mod_jk AJP13 AJP14 AJP15 Tomcat would answer Tomcat AJP14 to tell that it supports protocol AJP14. 2) What about specifying a separate, out of band control socket connection? If the web server opened up two connections, 1 for data, one for control, then we could have much better communication from the engine to the server (if it was shutting down contexts, for example). We could also have a heartbeat without interfering with the data channel. Good idea, but how could we be sure that we'll have only one control channel to a given servlet engine ? If we allow shutdown it could end confusing the user (which Apache has shutdown Tomcat?). So it could be good to have only one control channel. But what to do if more than one WebServer connect to Tomcat? In multi-threaded environnement like Apache 2.0, it's easy to launch a thread to handle that, but in Apache 1.3 will have no others choice than having each child (forked) opening it's own control connection since each child is forked and so have it's own copy of 'servlet-engine infos Probably we need shared memory... But I like this approach of splitting data and control. -Dan GOMEZ Henri wrote: Hi to all, You could find attached a proposal of evolution to the current Apache JServ Protocol version 1.3, also known as ajp13. Let start the comments, questions, remarks cycle. PS : I've not cover here the full protocol but only the add-on from ajp13. - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 --- - Name: AJPv14.txt AJPv14.txtType: Plain Text (text/plain) Encoding: quoted-printable -- Dan Milstein // [EMAIL PROTECTED]
Re: [PROPOSAL AJP14] AJP13 Evolution
On Mon, 7 May 2001, Dan Milstein wrote: Henri, Lots of good stuff. A few ideas/possibilities: 1) We've talked about specifying a response packet to indicate that the engine (or the web server) doesn't recognize a packet sent over. This would allow us much more flexiblity to add packet types to ajpv14, without having to make ajpv15,16, etc. +1 In other words - both ends should deal with unknown packets - maybe by sending back an UNIMPLEMENTED message. 2) What about specifying a separate, out of band control socket connection? If the web server opened up two connections, 1 for data, one for control, then we could have much better communication from the engine to the server (if it was shutting down contexts, for example). We could also have a heartbeat without interfering with the data channel. I'm not sure - but I can see some benefits. Right now we have (almost) bidirectional communication - the protocol is based on message passing, and sort of token-based: each side sends a message, then waits for a message. The main reason for that is the single-threaded web server. ( Apache1.3, maybe other servers ). It is a bit difficult to deal with 2 connections in a single threaded env ( while keeping the code as simple as possible ). My feeling is that for most needs of a servlet container we can deal with the single socket protocol. I don't know any (major) use case or feature of tomcat that would require the second socket. ( that doesn't mean I'm -1 on such thing ) Costin
Re: [PROPOSAL Tomcat 4.x] Cluster
Kief Morris wrote: [...] My point is that the Manager/Cluster needs to know when the session is in use by another instance of Catalina. A locking mechanism must be implemented by the Cluster (or whatever) to prevent a session from being used by multiple instances at once. This mechanism will require the Manager/Cluster system to know when a request begins using a session, and when it has finished. If we say that only one JVM at a time can manipulate a sessions since a sessions only belongs to one machine at a time the only time a session needs to be replicated is when it's created/changed/destroyed. Yes. But putting the session into the Cluster at creation time is unnecessary. It should be put in at the end of the request when it is created (other Catalina instances can't use it before then anyway), and updated at the end of each subsequent request. So we need to have the end of a request call into the Manager to indicate that the session can be sent to the Cluster and unlocked for use. Do we really need to lock a session for each request and then replicate it? Sorry I might be confused, you mean a request for a session or a request as in generating a new request object(http request). If we assume that a session is only in use in one JVM at a time(which I think we can assume) then that session doesn't need to be locked it just needs replication when it's changed. I'd rather see the replication be implemented in a Manager(i.e. DistributedManager or maybe change name to MulticastDistributedManager) thus making it possible to run any Store with the DistributedManager(i.e. FileStore). OK, I take your point that extending Store isn't the way to go. But I don't think we should have a different Manager implementation for each available distribution mechanism - MulticastDistributedManager, JMSDistributedManager, JavaSpacesDistributedManager, JCacheDistributedManager, etc. We should use the same pattern that Manager/Store uses: a single DistributedManager should be implemented which is independent of the actual session sharing mechanism. It should be able to use any implementation of the Cluster interface. Yes, sorry I was clear as mudd in my last email, so if you look at the DistributedManager.java I checked in 14h ago(as of writing) it now uses the new API's I created which is common for any distribuition protocol you might implement. I'd like to keep the possibility open to implement different distribution strategies. The strategy we're looking at now is for each instance of the application to hold copies of every session. An alternative Cluster strategy would keep the sessions in a central location such as a database: when a request comes in for a session not found in the current instance, the Cluster checks the database to see if it's there. This isn't too different from simply using JDBCStore. A third way is to have just two instances of the application holding a given session: when instance A creates the session, the Cluster chooses instance B to hold a backup copy in case A goes down: if a request comes in to C, B still has it available. One way that you could simply go with the cluster is to group them. So there is an option now to specify the name/port/address of the cluster. What I was thinking is that you could specify a cluster that this.jvm belongs too and then specify a cluster it should replicate too. Not that we need to implement all of these, but the architecture we build now should allow these possibilities and others. Other people can try out different ideas, and users can choose the system best suited to their needs. yes, agree. I'm also not sure about the issues with using persistence and distribution simultaneously. If we simply use PersistentManager with this distribution code, each instance will save its own copy of every session to persistent storage. This might be desirable in some cases - I can see using FileStore, for instance. But if you use JDBCStore and the Multicast distribution, it's wasteful - with a 4 server farm, we have 4 copies of each session in the database. So how should this be addressed? Cluster ought to have some mechanism which (optionally) ensures that each session is only persisted once. This may mean having Cluster override Store functionality, which is why I was thinking of combining the two. Yes, that's a good point, at first I was thinking that each machine in a Cluster is having it's own unique key, so when you generate an session id machine 1 would get something like: A1KDSFNRKIFLKMFDSFDSA where: || -- Are the two letters that identifies the machine, so when you know which machine that owns the session all machines that have the session replicated know that it doesn't belong to them so they shouldn't save in a Store. It's also useful for an eventuall tomcat dispatcher frontend to know which machine the session origins from. However some complications occur when you
RE: [PROPOSAL/VOTE] New Repositories for Collaborative Development
On Mon, 7 May 2001, Craig R. McClanahan wrote: * Dependence on Java2 as a base platform. This is not just an issue of using the collections classes (although that's part of it). Consider a few other issues: Once again - there is no problem with using Java2 for tomcat modules in 3.x. Tomcat3.x already has java2 modules - and it allways had. The security manager, setting the thread class loader, etc - all those are Java2 features, and we allways had them. The only requirement is not having java2 in the core, and providing a functional servlet container that works on Java1.1. That's done, and there's no plan to change the existing modules (except fixing bugs), so the goal of supporting 1.1 in 3.x shouldn't be a concern for anyone writing new modules. Costin P.S: my latest hobby is J2ME - and if I'll be able to get this voted I would like to do some changes to make sure tomcat3.x works fine on j2me - there are few changes and few additional restrictions. If not - it'll be a private patch to tomcat. (Check ibutton.com and tini, it's cool.) But again, that doesn't affect in any way existing modules - just the core, and an additional set of modules that will be specialized for the device.
RE: [PROPOSAL/VOTE] New Repositories for Collaborative Development
- Performance tuning for Java2 JVMs (particularly HotSpot) focuses your attention on different areas than JDK 1.1. Trying to optimize for both increases the effort required, and could lead to conflicts where you want to do things differently on different platforms. Well, tomcat3.x was never optimized for JDK1.1 ( or for any JVM for that matter ). Most optimizations are classical lazy evaluation, good memory management, avoid duplicated operations, etc - most of the stuff isn't even specific to java. The only important thing about Java2 and performance is the collections, weak references, etc - and the plan is to take full advantage of all those features in new modules ( after 3.3 is released ). As I said few times - the focus so far has been on core and modularity - not on individual modules ( few modules have been rewritten - for clarity mostly ). The only exception is the http module, which was slightly tuned ( mea cupla for that :-) Costin Working around Java2 dependencies is possible, but (again) is a very substantial amount of work. Where's the benefit? In contrario, why mod_jk from TC 3.3 couldn't be used in TC 4.x ? That's more feasible, but it also has a different set of issues: * Configuring the current generation of web connectors causes 90% of the user gripes about Tomcat. Anyone who needs evidence should subscribe to TOMCAT-USER and start answering all the questions about configuring. * The design assumption of the current generation of web connectors is that Apache will serve the static content. Unless the sysadmin is VERY careful in their configuration, this leads to violations of the servlet spec when static content is protected by a security constraint (2.2 and 2.3) or when filters should be invoked on static content (2.3). These problems are fixable -- but it's just a lot more work than simply porting a connector. Also shareable are all objects related to HTTP (cookies, messages, headers, ). Having smaller CVS, will also encourage new commiters contributing in area where they could be more at ease. Per my previous post, consider Commons for stuff that is not Tomcat specific at all. There are some very interesting developments on this directions with mod_jk and jasper. Focusing in this kind of thing is quite productive and puts some of the 3.3 people cooperating in the development of the 4.x version and vice versa. +1 I strongly think that merging the best of 3.3 and 4.0 could make an incredible Tomcat 5.0. Having Costin and Craig in the same team may be a dream but frankly what a bright combinaison. That's the way things were when I joined Sun 14 months ago. Costin opted to switch to a different project. Let's start by sharing what could be done, it will help identify what's the core and what could be modules (in reference to Apache http server no politics here :). Using 4.0 Valves and 3.3 modules didn't seems incompatible. There is many modules in 3.3 which are not related to Request/Response... Trying to force one of the groups out of its way will just fragment this project and take the 3.3 people somewhere else (SourceForge or so). Not sure it will force people to go somewhere else. Some may be just tired of political problem and stop contributing to ASF. That will be bad news for both groups, and there will be no winner in that case, the looser will be the OpenSource spirit. Besides developers and their own itches, there is another group whose interests ought to be considered - USERS of Tomcat. If you don't have any, then it becomes a much less interesting project to work on. And we've done a pretty good job at confusing people about what the Tomcat road map is. If the user community were to abandon Tomcat, it wouldn't matter much what we do on the development side. There isn't any compelling benefit (to the user community) to have two active development branches, once the next generation branch matures. The 4.0 container code is pretty stable (letting us focus now on performance improvements and feature adds). We could have had mod_jk ported a long time ago if someone wanted to work on it then (as they are apparently willing to now). In due time, the usual survival rules will tend to favor the solution that proves to be the best and everybody will work together again... until the next revolution. A sort of 'Software Darwinism' and species adaptability. Craig
Re: [PROPOSAL Tomcat 4.x] Cluster
On Mon, 7 May 2001, Bip Thelin wrote: [SNIP] Do we really need to lock a session for each request and then replicate it? Sorry I might be confused, you mean a request for a session or a request as in generating a new request object(http request). If we assume that a session is only in use in one JVM at a time(which I think we can assume) then that session doesn't need to be locked it just needs replication when it's changed. The servlet spec *requires* that all requests for a given session, at any point in time, be served by a single JVM. Whether and when replication happens seems to me like a quality of service issue for different implementations of the cluster -- I don't think a single answer will suffice here. I can conceive of everything from never migrating an existing session (essentially what the current load balancing support provides) to duplicating every single change live. An interesting question is, how do you detect when a session has been changed? Obviously, you can detect setAttribute/removeAttribute, but what about changes to the *internal* state of the attributes themselves that the session does not know about? (I understand, but haven't verified, that some J2EE containers expect you to call setAttribute again, on the same attribute, to tell the container that you've modified something). Craig
RE: [PROPOSAL AJP14] AJP13 Evolution
On Mon, 7 May 2001, Mike Braden wrote: +1 As for the security key, would it be possible to generate a unique key when mod_jk is first installed? Maybe we could create some basic mechanism, similar to the way ssh generates That's what tomcat3.3 does for ajp12 shutdown messages: at startup it generates a random password ( if none was explicitely set ). The code is quite simple to add for ajp14 too. Costin
Re: [PROPOSAL Tomcat 4.x] Cluster
Craig R. McClanahan typed the following on 11:18 AM 5/7/2001 -0700 An interesting question is, how do you detect when a session has been changed? Obviously, you can detect setAttribute/removeAttribute, but what about changes to the *internal* state of the attributes themselves that the session does not know about? I think we have to consider the session to be dirty at the end of any request in which it was accessed. Kief
RE: About bug#208
According to the JavaDoc for ServletRequest.getRemoteHost() Returns the fully qualified name of the client that sent the request, or the IP address of the client if the name cannot be determined. For HTTP servlets, same as the value of the CGI variable REMOTE_HOST. Based on that I would say that both implementations are wrong, you should never get an empty or a null value back. That will be fixed ASAP. In TC 3.2.2, I'm not sure if the CVS is still open (imminent release) Agreed. You should get either a host name or an IP address (in string form). I would also argue strongly against having tomcat do any reverse DNS look ups. If the web server doesn't tell us the remote host name just use the IP address. That works for the web-connected case. If you're running Tomcat stand-alone you need to be able to do the lookup. In 4.0, that is only done if the web app actually calls getRemoteHost(), so you don't pay the performance hit unless you ask for it. The DNS lookup must be done somewhere, and for example well-configured Apache HTTP servers didn't do the DNS lookup. So the RemoteHostName will not be passed in ajp12/ajp13. The job must be done by the servlet engine. It's the case in TC 3.2 for the HTTP connector. I'll modify the code accordingly.
Re: Tomcat 3.2.2 beta 4 (insecure default settings)
On Mon, May 07, 2001 at 02:11:35PM +0200, GOMEZ Henri wrote: You're right. TC still use ajp12 at its default connector so it listen all interface (which I agree could rise problem). I'm using in my prod systems, ajp13 to connect webservers and ajp12 only for the shutdown purpose (and listen only on localhost) Here is the same test but with slightly modified server.xml: Connector className=org.apache.tomcat.service.PoolTcpConnector Parameter name=handler value=org.apache.tomcat.service.connector.Ajp12ConnectionHandler/ Parameter name=port value=8007/ Parameter name=inet value=127.0.0.1/ /Connector Thanks to mention this one. The inet is not a well know and used param. Please note that port 8007 is bound to 127.0.0.1 interface _ONLY_. The secure way. Should it become default? I hope the answer is yes:) It also has another value: inet is not a well-known parameter. Having it in default server.xml along with a little comment about what it does may compensate for the lack of proper documentation:) I understand your valid requirement, but why not just developp a servlet in admin which use ajp12 to send (to localhost), the ajp12 shutdown command. Hope this helps :) Yes, and I hope you'll take a look at the ajp14 proposal... I did. I don't really understand why Ajp protocol should handle shutdown command at all. I agree that there may be a need for some kind of servlet that handles this operation but WHY THROUGH Ajp protocol??? It almost sounds like merging two things that serve totally different purpose together. What if you want to add more commands in the future? Would you really want to add these commands into ALL versions of protocol? And how do you handle these commands if you don't? IMHO there are few related but different things one wants to do with TC: 1)Serve requests - handled by Ajp protocol. 2)Configureadministrate - this one is a bit more complex. Some people (including myself) like doing configuration manually in command line interface. Hence there needs to be well defined set of config files and scripts one needs to care about. One of my personal challenges while setting up TC for the first time was to find out what config files are actually necessary. There is whole bunch of files in config directory for ALL the possible platforms/servers, etc. Some people would prefer to use some UI tool to configure the server and issue commands - here is your idea of extending functionality of admin application, add shutdown/restart commands to it as well as may be some other options like configuring connectors, including configuration of ports, interfaces, etc. There may even be some applet for monitoring the log files (like in Sun's JavaWebServer). I think good example is configuration as it is done in Enhydra. This kind of tool doesn't need any middle man in the form of Ajp or any other protocol. It can have hooks directly into server API. The advantage of this is that Ajp protocols remain plugguble unlike Ajp12 that you need to have to issue simple shutdown command and configuration may evolve without any weird dependencies on any particular protocol. Some people MIGHT want to set up distributed environment (read load balancing here) where the same application is physically distributed across multiple machines but configuration MUST be changed synchronously. This may be handled just by some *NIX scripts, etc but in this case having some administration protocol might be usable to build centralized configuration where all the changes are made in one place and communicated to all the balanced servers using some protocol. There are lots of complicated issues here but this is the place where IMHO some protocol might be NECESSERY. And even than I wouldn't add this features into any Ajp?? protocols. I'd much rather define another one that again may evolve differently from Ajp protocols but might use Ajp protocol as a transport layer. Here is the list of modifications that I've done to TC so far: 1) changed defaults to bind to 127.0.0.1 interface in server.xml. 2) changed shutdown code to make it work correctly if inet parameter is used. 3) modified mod_jk logger function to print timestamps in Apache Web server style. 4) modified tomcat.sh file in bin to redirect stdoutstderr to a log file (people complained about not seeing System.out.println() stuff) 5) modified default load balancing behavior to make use of wireless device's global id (I'm not giving details on this one because it's specific to what we are doing and probably useless for others. But I'm not hiding it:) I can describe it if anyone is interested). Sorry for the long E-Mail:) Hope you've read it:) -- oo Andrey oo
RE: About bug#208
I just commited the fix for 3.2.2. Not really. When the hostname is null or missing, you copy the host IP adress, but we there the name (DNS resolution). Something done by the caller (which agree to pay the price). -Original Message- From: GOMEZ Henri [mailto:[EMAIL PROTECTED]] Sent: Monday, May 07, 2001 11:16 AM To: [EMAIL PROTECTED] Subject: RE: About bug#208 According to the JavaDoc for ServletRequest.getRemoteHost() Returns the fully qualified name of the client that sent the request, or the IP address of the client if the name cannot be determined. For HTTP servlets, same as the value of the CGI variable REMOTE_HOST. Based on that I would say that both implementations are wrong, you should never get an empty or a null value back. I would also argue strongly against having tomcat do any reverse DNS look ups. If the web server doesn't tell us the remote host name just use the IP address. Ok, I'll do accordingly. Did the 3.2.2 tree is closed ? -Original Message- From: GOMEZ Henri [mailto:[EMAIL PROTECTED]] Sent: Monday, May 07, 2001 9:00 AM To: [EMAIL PROTECTED] Subject: About bug#208 Hi, The BUG #208 (request.getRemoteHost() returns empty string when using mod_jk BugRat Report#320) is still there (3.2.2b4). The difference is that when we're using ajp12, getRemoteHost = and in ajp13, getRemoteHost = null. The fix is easy the getRemoteAddr() is allways set but : - Did we want to Tomcat ask the DNS to resolve the name since it may be time consuming ? - ajp12 return empty string, ajp13 return null, what solution is recommanded in that case ? I also suspect TC 3.3 to have the same kind of problem ;( - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 -Original Message- From: GOMEZ Henri [mailto:[EMAIL PROTECTED]] Sent: Monday, May 07, 2001 2:40 PM To: [EMAIL PROTECTED] Subject: [PROPOSAL AJP14] AJP13 Evolution Hi to all, You could find attached a proposal of evolution to the current Apache JServ Protocol version 1.3, also known as ajp13. Let start the comments, questions, remarks cycle. PS : I've not cover here the full protocol but only the add-on from ajp13. - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6
Re: [PROPOSAL Tomcat 4.x] Cluster
On Mon, 7 May 2001, Kief Morris wrote: Craig R. McClanahan typed the following on 11:18 AM 5/7/2001 -0700 An interesting question is, how do you detect when a session has been changed? Obviously, you can detect setAttribute/removeAttribute, but what about changes to the *internal* state of the attributes themselves that the session does not know about? I think we have to consider the session to be dirty at the end of any request in which it was accessed. That's certainly feasible, but I'd bet we find it's too conservative a view given the potential impact on performance (i.e. needless replications). Kief Craig
RE: [PROPOSAL AJP14] AJP13 Evolution
In the doc, the secret key is a string present in web-server and servlet engine : must be defined for each workers: worker.myworker.port=8010 worker.myworker.type=ajp14 worker.myworker.host=myremotesystem worker.myworker.secretkey=myverysecretkey = in TC 3.2.x = Connector className=org.apache.tomcat.service.PoolTcpConnector Parameter name=handler value=org.apache.tomcat.service.connector.Ajp13ConnectionHandler/ Parameter name=port value=8009/ Parameter name=secretkey value=myverysecretkey/ /Connector = in TC 3.3 = RequestInterceptor className=org.apache.tomcat.modules.server.Ajp13Interceptor port=8009 secretkey=myverysecretkey / = in TC 4.0 = Connector className=org.apache.catalina.connector.ajp.Ajp13Connector port=8009 secretkey=myverysecretkey / AJP12/MOD_JSERV used the same system of allready know common key. The key is passed in md5 to get the 32 chars data - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6
NBIO
http://www.cs.berkeley.edu/~mdw/proj/java-nbio/ How about using that? :-) -jon
RE: About bug#208
I just commited the fix for 3.2.2.
Not really.
Arg damn't kd
When the hostname is null or missing, you just copy the host IP
adress.
I'd like better the HTTP native connector method :
public String getRemoteAddr() {
return xxx.getInetAddress().getHostAddress();
}
public String getRemoteHost() {
return xxx.getInetAddress().getHostName();
}
The name lookup (DNS resolution) will be done on
demand done by the caller (which agree to pay the price)
-Original Message-
From: GOMEZ Henri [mailto:[EMAIL PROTECTED]]
Sent: Monday, May 07, 2001 11:16 AM
To: [EMAIL PROTECTED]
Subject: RE: About bug#208
According to the JavaDoc for ServletRequest.getRemoteHost()
Returns the fully qualified name of the client that sent the
request, or the
IP address of the client if the name cannot be determined. For HTTP
servlets, same as the value of the CGI variable REMOTE_HOST.
Based on that I would say that both implementations are wrong,
you should
never get an empty or a null value back. I would also
argue strongly
against having tomcat do any reverse DNS look ups. If the
web server
doesn't tell us the remote host name just use the IP address.
Ok, I'll do accordingly.
Did the 3.2.2 tree is closed ?
-Original Message-
From: GOMEZ Henri [mailto:[EMAIL PROTECTED]]
Sent: Monday, May 07, 2001 9:00 AM
To: [EMAIL PROTECTED]
Subject: About bug#208
Hi,
The BUG #208 (request.getRemoteHost() returns empty string when
using mod_jk
BugRat Report#320)
is still there (3.2.2b4). The difference is that when we're
using ajp12,
getRemoteHost =
and in ajp13, getRemoteHost = null.
The fix is easy the getRemoteAddr() is allways set but :
- Did we want to Tomcat ask the DNS to resolve the name
since it may
be time consuming ?
- ajp12 return empty string, ajp13 return null, what solution is
recommanded
in that case ?
I also suspect TC 3.3 to have the same kind of problem ;(
-
Henri Gomez ___[_]
EMAIL : [EMAIL PROTECTED](. .)
PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6
-Original Message-
From: GOMEZ Henri [mailto:[EMAIL PROTECTED]]
Sent: Monday, May 07, 2001 2:40 PM
To: [EMAIL PROTECTED]
Subject: [PROPOSAL AJP14] AJP13 Evolution
Hi to all,
You could find attached a proposal of evolution to
the current Apache JServ Protocol version 1.3,
also known as ajp13.
Let start the comments, questions, remarks cycle.
PS : I've not cover here the full protocol but only the add-on
from ajp13.
-
Henri Gomez ___[_]
EMAIL : [EMAIL PROTECTED](. .)
PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6
RE: NBIO
Good stuff. Thanks - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 -Original Message- From: Jon Stevens [mailto:[EMAIL PROTECTED]] Sent: Monday, May 07, 2001 11:25 PM To: tomcat-dev Subject: NBIO http://www.cs.berkeley.edu/~mdw/proj/java-nbio/ How about using that? :-) -jon
RE: About bug#208
For Tomcat 3.2.2 I think the existing solution is OK. If 3.3 and 4.0 want to add DNS lookup, thats fine. If someone wants to add DNS lookup to 3.2.3, thats OK, too. The 2.2 specification only says that if we don't know the remote host's name we have to supply the remote host's IP address, it doesn't say how hard we have to try to figure out the host name if all we have is an IP address. The previous behavior violated the spec and therefore had to be changed prior to releasing 3.2.2. Right now I can live with a simple solution. I'm waiting to hear back from a user to make sure that the last change for JDK 1.1 support fixed his problem and then I plan to call a final release vote for TC3.2.2. Adding DNS lookups is not something I'm comfortable with at this point. Marc Just ship it Saegesser -Original Message- From: GOMEZ Henri [mailto:[EMAIL PROTECTED]] Sent: Monday, May 07, 2001 4:14 PM To: [EMAIL PROTECTED] Subject: RE: About bug#208 I just commited the fix for 3.2.2. Not really. When the hostname is null or missing, you copy the host IP adress, but we there the name (DNS resolution). Something done by the caller (which agree to pay the price). -Original Message- From: GOMEZ Henri [mailto:[EMAIL PROTECTED]] Sent: Monday, May 07, 2001 11:16 AM To: [EMAIL PROTECTED] Subject: RE: About bug#208 According to the JavaDoc for ServletRequest.getRemoteHost() Returns the fully qualified name of the client that sent the request, or the IP address of the client if the name cannot be determined. For HTTP servlets, same as the value of the CGI variable REMOTE_HOST. Based on that I would say that both implementations are wrong, you should never get an empty or a null value back. I would also argue strongly against having tomcat do any reverse DNS look ups. If the web server doesn't tell us the remote host name just use the IP address. Ok, I'll do accordingly. Did the 3.2.2 tree is closed ? -Original Message- From: GOMEZ Henri [mailto:[EMAIL PROTECTED]] Sent: Monday, May 07, 2001 9:00 AM To: [EMAIL PROTECTED] Subject: About bug#208 Hi, The BUG #208 (request.getRemoteHost() returns empty string when using mod_jk BugRat Report#320) is still there (3.2.2b4). The difference is that when we're using ajp12, getRemoteHost = and in ajp13, getRemoteHost = null. The fix is easy the getRemoteAddr() is allways set but : - Did we want to Tomcat ask the DNS to resolve the name since it may be time consuming ? - ajp12 return empty string, ajp13 return null, what solution is recommanded in that case ? I also suspect TC 3.3 to have the same kind of problem ;( - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 -Original Message- From: GOMEZ Henri [mailto:[EMAIL PROTECTED]] Sent: Monday, May 07, 2001 2:40 PM To: [EMAIL PROTECTED] Subject: [PROPOSAL AJP14] AJP13 Evolution Hi to all, You could find attached a proposal of evolution to the current Apache JServ Protocol version 1.3, also known as ajp13. Let start the comments, questions, remarks cycle. PS : I've not cover here the full protocol but only the add-on from ajp13. - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6
[PATCH] jk_lb_worker patch
Attached is a patch for the lb worker for mod_jk. Basically, it changes
the selection behavior slightly and adds some error and debugging
logging where we would find it useful.
The code uses two variables, lb_factor, and lb_value. lb_factor is the
numerical inverse (1/x) of what is entered into the workers.properties
file. This causes the lb_factor to become very large if the lb_factor
in workers.properties is 0. lb_value always starts at 0.
The decision of which worker is used is based on lb_value. The worker
with the lowest lb_value gets selected to service a request. After a
worker is used, its lb_value is incremented by lb_factor.
Unfortunately, this causes the balancer to service at least one request
on each worker before the lb_factor actually has any effect. This one
request will often lead to an entire session being served off of a
different worker.
This behavior isn't really a problem, but in a scenario where you have
an external load balancer, it is preferable to try to honor its
decisions except where there is an error. Such an error can happen with
providers that use IP randomizing proxies such as AOL. Its also nice to
be more deterministic in the normal case.
This patch seeds the lb_value with 1/lb_factor. This changes the
behavior by causing lb_value to be larger for servers with lower weights
than servers with higher weights. If the lb_factor in
workers.properties is 0, it becomes very large and should only be
selected in the case of all the regular workers being unavailable or due
to a session route.
I added error logging for if the worker specified by the session route
is unavailable. I added debug logging for selecting a worker by session
route, and for which worker is selected.
This hasn't been tested much, but its almost a trivial change. This is
against 3.2.1, but it should apply clean to later versions as well.
Feedback is welcome.
Paul
--- /tmp/jakarta-tomcat-3.2.1-src/src/native/jk/jk_lb_worker.c Tue Dec 12 16:51:56
2000
+++ ../jk/jk_lb_worker.cMon May 7 16:23:20 2001
@@ -244,7 +244,8 @@
}
static worker_record_t *get_most_suitable_worker(lb_worker_t *p,
- jk_ws_service_t *s)
+ jk_ws_service_t *s,
+jk_logger_t *l)
{
worker_record_t *rc = NULL;
double lb_min = 0.0;
@@ -255,8 +256,14 @@
for(i = 0 ; i p-num_of_workers ; i++) {
if(0 == strcmp(session_route, p-lb_workers[i].name)) {
if(p-lb_workers[i].in_error_state) {
- break;
+ jk_log(l, JK_LOG_ERROR,
+ In get_most_suitable_worker, requested worker (%s)
+unavailable, redirecting session\n,
+ p-lb_workers[i].name);
+ break;
} else {
+ jk_log(l, JK_LOG_DEBUG,
+ In get_most_suitable_worker, selected %s because of
+session_route\n,
+ p-lb_workers[i].name);
return (p-lb_workers[i]);
}
}
@@ -282,13 +289,13 @@
lb_min = p-lb_workers[i].lb_value;
rc = (p-lb_workers[i]);
}
-}
+}
}
if(rc) {
rc-lb_value += rc-lb_factor;
+ jk_log(l, JK_LOG_DEBUG, In get_most_suitable_worker, selected %s\n,
+rc-name);
}
-
return rc;
}
@@ -309,7 +316,7 @@
while(1) {
-worker_record_t *rec = get_most_suitable_worker(p-worker, s);
+worker_record_t *rec = get_most_suitable_worker(p-worker, s, l);
int rc;
if(rec) {
@@ -347,7 +354,7 @@
* Error is not recoverable - break with an error.
*/
jk_log(l, JK_LOG_ERROR,
- In jk_endpoint_t::service, none recoverable error...\n);
+ In jk_endpoint_t::service, non recoverable error...\n);
break;
}
@@ -426,7 +433,7 @@
p-lb_workers[i].lb_factor = jk_get_lb_factor(props,
worker_names[i]);
p-lb_workers[i].lb_factor = 1/p-lb_workers[i].lb_factor;
-p-lb_workers[i].lb_value = 0.0;
+p-lb_workers[i].lb_value = p-lb_workers[i].lb_factor;
p-lb_workers[i].in_error_state = JK_FALSE;
p-lb_workers[i].in_recovering = JK_FALSE;
if(!wc_create_worker(p-lb_workers[i].name,
RE: Tomcat 3.2.2 beta 4 - AJP14 continuation
Should it become default? I hope the answer is yes:) It also has another value: inet is not a well-known parameter. Having it in default server.xml along with a little comment about what it does may compensate for the lack of proper documentation:) +1 for the addition in server.xml (Marc, Larry ?) I understand your valid requirement, but why not just developp a servlet in admin which use ajp12 to send (to localhost), the ajp12 shutdown command. Hope this helps :) Yes, and I hope you'll take a look at the ajp14 proposal... I did. I don't really understand why Ajp protocol should handle shutdown command at all. I agree that there may be a need for some kind of servlet that handles this operation but WHY THROUGH Ajp protocol??? Adding shutdown in ajp14 will help a web admin to build a control deck to shutdown from ONE POINT some or all of its Tomcat. It almost sounds like merging two things that serve totally different purpose together. What if you want to add more commands in the future? The AJP14 is not closed, it's just a starting point for discussion. Would you really want to add these commands into ALL versions of protocol? And how do you handle these commands if you don't? The AJP15 must handle all commands from AJP14 and will have its owns one. Also you must have notice about the negociation at startup. Some asked to add at start of negociation a string indicating which protocol are supported by web-server. The servlet engine will then use the higher common protocol : ie: web-servlet knows about AJ14/AJP15 but servlet engine only AJP14. The protocol used will be AJP14. web-servlet knows AJ14/AJP15 and servlet engine AJP14/AJP15/AJP16. The discussion will use AJP15. IMHO there are few related but different things one wants to do with TC: 1)Serve requests - handled by Ajp protocol. 2)Configureadministrate - this one is a bit more complex. Some people (including myself) like doing configuration manually in command line interface. Hence there needs to be well defined set of config files and scripts one needs to care about. One of my personal challenges while setting up TC for the first time was to find out what config files are actually necessary. There is whole bunch of files in config directory for ALL the possible platforms/servers, etc. I'm like you and do by hand all my configuration, and set my JkMount in VirtualHost. But many starting users will like the autoconf features. Note that JkMount could still be used and JkAutoMount is then mandatory... Some people would prefer to use some UI tool to configure the server and issue commands - here is your idea of extending functionality of admin application, add shutdown/restart commands to it as well as may be some other options like configuring connectors, including configuration of ports, interfaces, etc. There may even be some applet for monitoring the log files (like in Sun's JavaWebServer). I think good example is configuration as it is done in Enhydra. This kind of tool doesn't need any middle man in the form of Ajp or any other protocol. It can have hooks directly into server API. The advantage of this is that Ajp protocols remain plugguble unlike Ajp12 that you need to have to issue simple shutdown command and configuration may evolve without any weird dependencies on any particular protocol. Some Admin Servlet could do the job Some people MIGHT want to set up distributed environment (read load balancing here) where the same application is physically distributed across multiple machines but configuration MUST be changed synchronously. This may be handled just by some *NIX scripts, etc but in this case having some administration protocol might be usable to build centralized configuration where all the changes are made in one place and communicated to all the balanced servers using some protocol. There are lots of complicated issues here but this is the place where IMHO some protocol might be NECESSERY. And even than I wouldn't add this features into any Ajp?? protocols. I'd much rather define another one that again may evolve differently from Ajp protocols but might use Ajp protocol as a transport layer. AJP13 is still present and supported, but lack some features needed for Servlet API 2.3. My english is bad but AJP14 WILL USE AJP13 as transport layer, there will be new commands added and new cinematic, but AJP14 = AJP13++ Here is the list of modifications that I've done to TC so far: 1) changed defaults to bind to 127.0.0.1 interface in server.xml. Will be changed in server.xml for 3.2/3.3 (Marc/larry are you agree) 2) changed shutdown code to make it work correctly if inet parameter is used. Thanks to (re)send the code to list. 3) modified
RE: About bug#208
The previous behavior violated the spec and therefore had to be changed prior to releasing 3.2.2. Right now I can live with a simple solution. And you fix it. I'm waiting to hear back from a user to make sure that the last change for JDK 1.1 support fixed his problem and then I plan to call a final release vote for TC3.2.2. Adding DNS lookups is not something I'm comfortable with at this point. Marc Just ship it Saegesser Could be changed by : Marc Thanks to ship it Saegesser :) I agree with you the fix will be suffisant for 3.2.2 release which is imminent ? Thanks for that just-in-time fix
RE: [PROPOSAL AJP14] AJP13 Evolution
Will this be the next step to combining mod_webapp with mod_jk? Discussion is open and Pier is my guess, even if he loose an occasion to eat splendid 'pasta fresca'. Maybe this could be the first step to merging the two. ajp14 could offer some automatic configuration similar to mod_webapp, as you suggested in the proposal. I also think that a security mechanism is important. There should be some form of login for the connector to make sure that communication with the server is allowed. I think we should be careful with the security side, however. This could lead into a complex discussion over what is appropriate. My suggestion would be to go with something simple, as suggested in the proposal. The system is aimed to be simple, we don't want SSH/SSL here but just a basic 'protected' login. This level of security would cover most of the installations and when someone requires an additional level of security or interface to other security mechanisms, that could be added later. We can add native SSH tunneling for example using openssh. This proposal hits on the most important issues with mod_jk at this point. +1 As for the security key, would it be possible to generate a unique key when mod_jk is first installed? Maybe we could create some basic mechanism, similar to the way ssh generates a key when it is installed. This would avoid the possibility of having many TC servers out there that can be logged into with the default key or no key. It could avoid the problem that the admin webapp has with the password needing to be changed and trust being turned on. mod_jk could serve many tomcats on different systems. Each Tomcat could need a different secret key, but worker concept help here. Cf my previous mail about it Just a thought. Mike. -- Mike Braden [EMAIL PROTECTED] [EMAIL PROTECTED] -Original Message- From: GOMEZ Henri [mailto:[EMAIL PROTECTED]] Sent: Monday, May 07, 2001 8:40 AM To: [EMAIL PROTECTED] Subject: [PROPOSAL AJP14] AJP13 Evolution Hi to all, You could find attached a proposal of evolution to the current Apache JServ Protocol version 1.3, also known as ajp13. Let start the comments, questions, remarks cycle. PS : I've not cover here the full protocol but only the add-on from ajp13. - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6
RE: [PROPOSAL AJP14] AJP13 Evolution
2 things: The system is aimed to be simple, we don't want SSH/SSL here but just a basic 'protected' login. and that you can bind the socket to 127.0.0.1:PORT instead of *:PORT through a config change. This level of security would cover most of the installations and when someone requires an additional level of security or interface to other security mechanisms, that could be added later. We can add native SSH tunneling for example using openssh. You could do that already with no modifications to the ajp by using port forwarded SSH tunneling. Heck, you could do it with STunnel if you want to use RSA/SSL instead of SSH also without modifications to ajp. -- Nick Bauman Software Developer 3023 Lynn #22 Minneapolis, MN 55416 Mobile Phone: (612) 810-7406
RE: [PROPOSAL AJP14] AJP13 Evolution
1) We've talked about specifying a response packet to indicate that the engine (or the web server) doesn't recognize a packet sent over. This would allow us much more flexiblity to add packet types to ajpv14, without having to make ajpv15,16, etc. +1 In other words - both ends should deal with unknown packets - maybe by sending back an UNIMPLEMENTED message. Since AJP indicate size we could deal with unknow packets. But if we negociate at startup the common protocol level, we must avoid that situation. I like the idea of reject cmd, +1 2) What about specifying a separate, out of band control socket connection? If the web server opened up two connections, 1 for data, one for control, then we could have much better communication from the engine to the server (if it was shutting down contexts, for example). We could also have a heartbeat without interfering with the data channel. I'm not sure - but I can see some benefits. Right now we have (almost) bidirectional communication - the protocol is based on message passing, and sort of token-based: each side sends a message, then waits for a message. The main reason for that is the single-threaded web server. ( Apache1.3, maybe other servers ). It is a bit difficult to deal with 2 connections in a single threaded env ( while keeping the code as simple as possible ). My feeling is that for most needs of a servlet container we can deal with the single socket protocol. I don't know any (major) use case or feature of tomcat that would require the second socket. Argh, all the subtility is here. Basically even if ajp13 is a bidirectional protocol, it's a request/reply protocol since it's how a web server function : 1) FORWARD REQUEST FROM WEB-SERVER TO SERVLET ENGINE 2) WAIT FOR RESPONSE 3) GET RESPONSE AND FORWARD TO WEB-SERVER. We could have a second socket for control but : 1) How did we share it in forked (apache 1.3) env ? = shared memory = MM or APR 2) Ditto in a threaded architecture (Apache 2.0) at least in MPM mode (a forked child which will in turn thread child), but again how did we info we other forked. Also doubling the socket, will double the descriptors open and will be a problem under heavy load. In an HTTP architecture we need again to mix data (tons of messages) with control (very low traffic). And so we need to read for possible message at some time. 1) FORWARD REQUEST FROM WEB-SERVER TO SERVLET ENGINE 2) WAIT FOR END OF PREVIOUS REPLY AND EVENTUALLY ADMIN MESSAGE 3) GET ADMIN MESSAGE and evnetually RESPONSE 4) GET RESPONSE AND FORWARD TO WEB-SERVER. The admin message could be send() in socket at any time and will be handled when a request will came
RE: [PROPOSAL AJP14] AJP13 Evolution
2 things: The system is aimed to be simple, we don't want SSH/SSL here but just a basic 'protected' login. and that you can bind the socket to 127.0.0.1:PORT instead of *:PORT through a config change. In that case, you restrict to a web-sevlet/tomcat on the same machine, but yes we could do that (allready possible on TC 3.2/3.3) This level of security would cover most of the installations and when someone requires an additional level of security or interface to other security mechanisms, that could be added later. We can add native SSH tunneling for example using openssh. You could do that already with no modifications to the ajp by using port forwarded SSH tunneling. Heck, you could do it with STunnel if you want to use RSA/SSL instead of SSH also without modifications to ajp. I better use jonama (http://www.multimania.com/jonama/) to do SSL tunneling since I wrote this one ;)
Re: About bug#208
[EMAIL PROTECTED] (Craig R. McClanahan) writes: On Mon, 7 May 2001, Marc Saegesser wrote: According to the JavaDoc for ServletRequest.getRemoteHost() Returns the fully qualified name of the client that sent the request, or the IP address of the client if the name cannot be determined. For HTTP servlets, same as the value of the CGI variable REMOTE_HOST. Based on that I would say that both implementations are wrong, you should never get an empty or a null value back. Agreed. You should get either a host name or an IP address (in string form). Disagree. The CGI specification (1.1) has the following to say: * REMOTE_HOST The hostname making the request. If the server does not have this information, it should set REMOTE_ADDR and leave this unset. I would say the equivalent of not setting the REMOTE_HOST CGI variable is to have request.getRemoteHost() return null. -- `O O' | [EMAIL PROTECTED] // ^ \\ | http://www.pyrites.org.uk/
URGENT!
Hi!, I get the following exceptions from tomcat when Itry to access a secure JSP using Veisign certificates: 2001-03-22 03:47:18 - Ctx( ): 400 R( /) null 2001-03-22 03:47:18 - Ctx( ): IOException in: R( /) Socket closedAnd the browser displays the following message: The page cannot be displayedI can get Tomcat SSL working if I generate the .keystore the following way: keytool -genkey -alias tomcat -keyalg RSABut when I: 1. generate a request and key; openssl req -new -out REQ.pem -keyout KEY.pem 2. generate a self signed certificate; openssl req -x509 -in REQ.pem -key KEY.pem -out CERT.pem 3. and finally import the certificate into the .keystore; keytool -import -v -trustcacerts -alias tomcat -fileCERT.pem I need this to work so I can use a certificate from verisign. PLEASE IF YOU WILLFIX THIS WITH A PATCH, LET ME KNOW WHEN IT BE AVAILABLE, BECAUSE WE ARE REALLY URGENT TO MAKE THIS WORK.ANOTHER ISSUE, WHEN WE TRY TO CONNECT THE APACHE-SSL WITH TOMCAT WE CAN'T MADE IT WORK, WHERE CAN QWE FIND A HOW-TO FOR THIS PROBLEM, WE READ THE ON-LINE DOCUMENTATION AND IT DOESN'T WORK.Thanks!!!
Re: URGENT!
on 5/7/01 4:31 PM, Victor González [EMAIL PROTECTED] wrote: PLEASE IF YOU WILL FIX THIS WITH A PATCH, LET ME KNOW WHEN IT BE AVAILABLE, BECAUSE WE ARE REALLY URGENT TO MAKE THIS WORK. ANOTHER ISSUE, WHEN WE TRY TO CONNECT THE APACHE-SSL WITH TOMCAT WE CAN'T MADE IT WORK, WHERE CAN QWE FIND A HOW-TO FOR THIS PROBLEM, WE READ THE ON-LINE DOCUMENTATION AND IT DOESN'T WORK. YOU TYPE IN ALL CAPS AND POST TO THE WRONG MAILING LIST SO YOUR MESSAGE WILL BE IGNORED. :-) -jon
Re: load-on-startup / classloader bug??
doh! not only did i not mention which version i'm using, i also mispoke... mondays... so, i'm using the latest tomcat 4.0 out of cvs (co'd this morning). also, it's in the servlet init method, *not* it's service method where the thread is created. when i get some time, i'm going to try and recreate this in a small example that i can post. -kevin. kevin seguin wrote: i have a servlet that creates a thread in it's service method. this thread basically does a bunch of initialization stuff. when i add a load-on-startup element for this servlet in web.xml, it reports a NoClassDefFoundError on a class in the same package as the servlet. i have not seen this problem with any other load-on-startup servlets. the only difference is that this servlet kicks off a new thread. ideas? is this a bug, or just bad programming on my part (well, not really my part, but that's another story...)? i started to look through the startup/loader/class loader, but quickly got overwhelmed :) -kevin.
Re: load-on-startup / classloader bug??
doh! not only did i not mention which version i'm using, i also mispoke... mondays... so, i'm using the latest tomcat 4.0 out of cvs (co'd this morning). also, it's in the servlet init method, *not* it's service method where the thread is created. when i get some time, i'm going to try and recreate this in a small example that i can post. -kevin. kevin seguin wrote: i have a servlet that creates a thread in it's service method. this thread basically does a bunch of initialization stuff. when i add a load-on-startup element for this servlet in web.xml, it reports a NoClassDefFoundError on a class in the same package as the servlet. i have not seen this problem with any other load-on-startup servlets. the only difference is that this servlet kicks off a new thread. ideas? is this a bug, or just bad programming on my part (well, not really my part, but that's another story...)? i started to look through the startup/loader/class loader, but quickly got overwhelmed :) With the current code it will fail indeed. Remy
Re: load-on-startup / classloader bug??
With the current code it will fail indeed. any reason(s) why? will this be fixed? thanks, -kevin.
Re: URGENT!
Uppercase words represents shouting which is poor list etiquette. On Monday 07 May 2001 18:31, you wrote: Hi!, I get the following exceptions from tomcat when I try to access a secure JSP using Veisign certificates: 2001-03-22 03:47:18 - Ctx( ): 400 R( /) null 2001-03-22 03:47:18 - Ctx( ): IOException in: R( /) Socket closed And the browser displays the following message: The page cannot be displayed I can get Tomcat SSL working if I generate the .keystore the following way: keytool -genkey -alias tomcat -keyalg RSA But when I: 1. generate a request and key; openssl req -new -out REQ.pem -keyout KEY.pem 2. generate a self signed certificate; openssl req -x509 -in REQ.pem -key KEY.pem -out CERT.pem 3. and finally import the certificate into the .keystore; keytool -import -v -trustcacerts -alias tomcat -file CERT.pem I need this to work so I can use a certificate from verisign. PLEASE IF YOU WILL FIX THIS WITH A PATCH, LET ME KNOW WHEN IT BE AVAILABLE, BECAUSE WE ARE REALLY URGENT TO MAKE THIS WORK. ANOTHER ISSUE, WHEN WE TRY TO CONNECT THE APACHE-SSL WITH TOMCAT WE CAN'T MADE IT WORK, WHERE CAN QWE FIND A HOW-TO FOR THIS PROBLEM, WE READ THE ON-LINE DOCUMENTATION AND IT DOESN'T WORK. Thanks!!! Content-Type: text/html; charset=iso-8859-1; name=Attachment: 1 Content-Transfer-Encoding: quoted-printable Content-Description:
RE: About bug#208
I think this area is sufficiently grey. The *only* place I've been able to find reference to the return value of getRemoteHost() is in the JavaDoc. The specification text is silent on this topic. The JavaDoc makes two statements: 1) Returns either a fully qualified host name or an IP address. 2) Same as the CGI REMOTE_HOST variable. As Nick points out, these two statements are not compatible. I'm inclined to lean towards option 1 simply because it is the behaviour that is explicitly spelled out in the JavaDoc, but the point could be argued in either way. In any case, the current implementation is no more broken then the previous one. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Monday, May 07, 2001 4:58 PM To: [EMAIL PROTECTED] Subject: Re: About bug#208 [EMAIL PROTECTED] (Craig R. McClanahan) writes: On Mon, 7 May 2001, Marc Saegesser wrote: According to the JavaDoc for ServletRequest.getRemoteHost() Returns the fully qualified name of the client that sent the request, or the IP address of the client if the name cannot be determined. For HTTP servlets, same as the value of the CGI variable REMOTE_HOST. Based on that I would say that both implementations are wrong, you should never get an empty or a null value back. Agreed. You should get either a host name or an IP address (in string form). Disagree. The CGI specification (1.1) has the following to say: * REMOTE_HOST The hostname making the request. If the server does not have this information, it should set REMOTE_ADDR and leave this unset. I would say the equivalent of not setting the REMOTE_HOST CGI variable is to have request.getRemoteHost() return null. -- `O O' | [EMAIL PROTECTED] // ^ \\ | http://www.pyrites.org.uk/
cvs commit: jakarta-tomcat/src/doc readme
marcsaeg01/05/07 18:31:20 Modified:.Tag: tomcat_32 RELEASE-NOTES src/doc Tag: tomcat_32 readme Log: Updated descriptions in section 4, added note about AJP12/SSL limitation to section 6 and added description of fix for bug 208. Revision ChangesPath No revision No revision 1.1.2.7 +19 -3 jakarta-tomcat/Attic/RELEASE-NOTES Index: RELEASE-NOTES === RCS file: /home/cvs/jakarta-tomcat/Attic/RELEASE-NOTES,v retrieving revision 1.1.2.6 retrieving revision 1.1.2.7 diff -u -r1.1.2.6 -r1.1.2.7 --- RELEASE-NOTES 2001/05/07 13:34:25 1.1.2.6 +++ RELEASE-NOTES 2001/05/08 01:31:17 1.1.2.7 @@ -1,4 +1,4 @@ -$Id: RELEASE-NOTES,v 1.1.2.6 2001/05/07 13:34:25 marcsaeg Exp $ +$Id: RELEASE-NOTES,v 1.1.2.7 2001/05/08 01:31:17 marcsaeg Exp $ Release Notes for: @@ -70,9 +70,14 @@ version 3.1 also focused on reorganizing the code (modularization, cleanup, refactoring, removal of dead code, and separation of J2EE-specific code). -- Tomcat 3.2 is the first performance tune-up, and also adds a few new -features (see next section). +- Tomcat 3.2 was the first performance tune-up, and also added a few new +features. +- Tomcat 3.2.1 was a security update. See section 7.3 for details. + +- Tomcat 3.2.2 is a bug fix release. Section 7.1 describes the issues +that have been fixed in the version. + - Tomcat 4.0 is separate development from Tomcat 3.x. It is based on the Catalina architecture, which is very different from the architecture of Tomcat 3.x. In addition, Tomcat 4.0 is to be the reference implementation @@ -281,6 +286,15 @@ javax.servlet.Context.getResrouceAsStream() cannot contain URL escapes of the form %HH. Paths containing any URL escapes will return null. +6.11 AJP12 and SSL + +The AJP12 protocol does not provide a mechanism for identifying requests +that arrived on a secure transport (e.g. SSL). Tomcat assumes that any +request that arrived on server port 443 is secure and sets the URL scheme +to HTTPS. Requests on any other port are assumed to be non-secure and +will indicate a URL scheme of HTTP. The AJP13 protocol does not suffer +from this problem. + === 7. FIXES AND ENHANCEMENTS IN UPDATES @@ -318,6 +332,8 @@ - HttpServletRequest.encodeURL() now properly encodes URLs that contain an anchor but no query string. (#1182) - Error pages now work in virtual hosts. + - ServletRequest.getRemoteHost() now returns the remote IP address + if the remote host name isn't known. (#208) Jasper - Fix for UnsupportedEncodingException due to UTF8 instead of UTF-8. (#269) No revision No revision 1.8.2.19 +19 -3 jakarta-tomcat/src/doc/readme Index: readme === RCS file: /home/cvs/jakarta-tomcat/src/doc/readme,v retrieving revision 1.8.2.18 retrieving revision 1.8.2.19 diff -u -r1.8.2.18 -r1.8.2.19 --- readme2001/05/07 13:34:32 1.8.2.18 +++ readme2001/05/08 01:31:19 1.8.2.19 @@ -1,4 +1,4 @@ -$Id: readme,v 1.8.2.18 2001/05/07 13:34:32 marcsaeg Exp $ +$Id: readme,v 1.8.2.19 2001/05/08 01:31:19 marcsaeg Exp $ Release Notes for: @@ -70,9 +70,14 @@ version 3.1 also focused on reorganizing the code (modularization, cleanup, refactoring, removal of dead code, and separation of J2EE-specific code). -- Tomcat 3.2 is the first performance tune-up, and also adds a few new -features (see next section). +- Tomcat 3.2 was the first performance tune-up, and also added a few new +features. +- Tomcat 3.2.1 was a security update. See section 7.3 for details. + +- Tomcat 3.2.2 is a bug fix release. Section 7.1 describes the issues +that have been fixed in the version. + - Tomcat 4.0 is separate development from Tomcat 3.x. It is based on the Catalina architecture, which is very different from the architecture of Tomcat 3.x. In addition, Tomcat 4.0 is to be the reference implementation @@ -281,6 +286,15 @@ javax.servlet.Context.getResrouceAsStream() cannot contain URL escapes of the form %HH. Paths containing any URL escapes will return null. +6.11 AJP12 and SSL + +The AJP12 protocol does not provide a mechanism for identifying requests +that arrived on a secure transport (e.g. SSL). Tomcat assumes that any +request that arrived on server port 443 is secure and sets the URL scheme +to HTTPS. Requests on any other port are
Re: About bug#208
On 7 May 2001, Nick Holloway wrote: [EMAIL PROTECTED] (Craig R. McClanahan) writes: On Mon, 7 May 2001, Marc Saegesser wrote: According to the JavaDoc for ServletRequest.getRemoteHost() Returns the fully qualified name of the client that sent the request, or the IP address of the client if the name cannot be determined. For HTTP servlets, same as the value of the CGI variable REMOTE_HOST. Based on that I would say that both implementations are wrong, you should never get an empty or a null value back. Agreed. You should get either a host name or an IP address (in string form). Disagree. The CGI specification (1.1) has the following to say: * REMOTE_HOST The hostname making the request. If the server does not have this information, it should set REMOTE_ADDR and leave this unset. I would say the equivalent of not setting the REMOTE_HOST CGI variable is to have request.getRemoteHost() return null. Equivalent doesn't matter any more, because the semantics for this and several other calls are no longer identical to CGI semantics. (I've been lobbying to get rid of all the same as CGI variable FOO comments in the JavaDocs, but that is a different story ...). Interestingly, this issue is being discussed by the JSR-053 expert group as we speak, so a refinement in the semantics might show up in 2.3 final. In the mean time, we need to obey what the Javadocs say: Returns the fully qualified name of the client that sent the request, or the IP address of the client if the name cannot be determined. -- `O O' | [EMAIL PROTECTED] // ^ \\ | http://www.pyrites.org.uk/ Craig McClanahan
Servlet Mapping problem
Greetings I apologize if this question has been answered properly in other place but i'm unable to fix this problem :( I'm trying to mapp a Servlet to the following url: http://localhost/HolaMundo And i added the following to the WEB_INF/web.xml file: web-app display-nameHola Mundo/display-name session-timeout30/session-timeout servlet servlet-nameHolaMundo/servlet-name servlet-classorg.eslared.taller2.HolaMundo/servlet-class /servlet servlet-mapping servlet-nameHolaMundo/servlet-name url-pattern/HolaMundo/url-pattern /servlet-mapping /web-app I'm also using the automatic generated configuration file on apache (i'm including the file at the end of the httpd.conf file): #VirtualHost * #ServerAdmin [EMAIL PROTECTED] #DocumentRoot /www/docs/dummy-host.example.com #ServerName dummy-host.example.com #ErrorLog logs/dummy-host.example.com-error_log #CustomLog logs/dummy-host.example.com-access_log common #/VirtualHost Include /local/jakarta/dist/tomcat/conf/mod_jk.conf-auto This is the directory layout: [root@jose webapps]# find ./holamundo -print ./holamundo ./holamundo/META-INF ./holamundo/META-INF/MANIFEST.MF ./holamundo/WEB-INF ./holamundo/WEB-INF/classes ./holamundo/WEB-INF/classes/org ./holamundo/WEB-INF/classes/org/eslared ./holamundo/WEB-INF/classes/org/eslared/taller2 ./holamundo/WEB-INF/classes/org/eslared/taller2/HolaMundo.class ./holamundo/WEB-INF/lib ./holamundo/WEB-INF/web.xml ./holamundo/holamundo.jsp I got errors calling the following url's: http://localhost/HolaMundo (this the desired url) http://localhost:8080/HolaMundo http://localhost/holamundo/HolaMundo But the following ones work perfectly (but without the desired effect): http://localhost/holamundo/servlet/HolaMundo http://localhost:8080/holamundo/HolaMundo I checked the following resources witthout any results: http://mikal.org/interests/java/tomcat/archive/view?mesg=27294 Any ideas what i'm doing wrong? = José Vicente Núñez Zuleta System Engineer / Developer Development Leader, Diario El Universal http://www.eluniversal.com http://www.autofuturo.com (current project) _ Do You Yahoo!? Obtenga su dirección de correo-e gratis @yahoo.com en http://correo.espanol.yahoo.com
cvs commit: jakarta-tomcat-connectors - Imported sources
craigmcc01/05/07 19:08:43 Log: Initial import of jakarta-tomcat-connectors repository. Status: Vendor Tag: Apache Release Tags: start N jakarta-tomcat-connectors/LICENSE No conflicts created by this import
cvs commit: jakarta-tomcat-jasper - Imported sources
craigmcc01/05/07 19:09:17 Log: Initial import of the jakarta-tomcat-jasper repository. Status: Vendor Tag: Apache Release Tags: start N jakarta-tomcat-jasper/LICENSE No conflicts created by this import
New CVS Repositories
Per our discussion today, I have created two new CVS repositories associated with the Tomcat subproject: jakarta-tomcat-connectorsFor development of web connectors for various versions of Tomcat. jakarta-tomcat-jasperFor development of a next generation Jasper (JSP) implementation. As with the other repositories that are part of Tomcat, all Tomcat committers have commit access to these new repositories automatically. Craig
[PROPOSAL/VOTE] Tomcat 4.0 Beta 4 Release
Now that the Proposed Final Draft 2 versions of the Servlet 2.3 and JSP 1.2 specs have been published (with Tomcat 4.0 updated to support the latest changes), and a ton of bug fixes have been made, I would like to propose that we create a Tomcat 4.0 Beta 4 release as follows: Release Manager: Craig McClanahan Code Freeze: Thursday, May 10, 2001 at 05:00pm Pacific Time See the file RELEASE-NOTES-4.0-B4.txt for a reasonably up-to-date list of the changes to date. This document will be updated with any additional changes that are made, plus a list of known outstanding issues. Between now and the code freeze, I'd like us to focus on fixing outstanding bugs and catching the configuration documentation up to date. I'm OK with continuing work on the new distributed session stuff in the mean time (as long as it is not enabled in the default configuration), but please hold off on making substantive changes in the core container until after the Beta 4 release. Comments? Votes? The usual rules apply: [ ] +1 = I agree with this proposal and will support it [ ] +0 = I agree with this proposal, but do not have time to support it [ ] -0 = I do not agree with this proposal, but don't want to try to block it [ ] -1 = I do not agree with this proposal (requires reasons) Craig
Re: [PROPOSAL/VOTE] Tomcat 4.0 Beta 4 Release
+1 Amy Now that the Proposed Final Draft 2 versions of the Servlet 2.3 and JSP 1.2 specs have been published (with Tomcat 4.0 updated to support the latest changes), and a ton of bug fixes have been made, I would like to propose that we create a Tomcat 4.0 Beta 4 release as follows: Release Manager: Craig McClanahan Code Freeze: Thursday, May 10, 2001 at 05:00pm Pacific Time See the file RELEASE-NOTES-4.0-B4.txt for a reasonably up-to-date list of the changes to date. This document will be updated with any additional changes that are made, plus a list of known outstanding issues. Between now and the code freeze, I'd like us to focus on fixing outstanding bugs and catching the configuration documentation up to date. I'm OK with continuing work on the new distributed session stuff in the mean time (as long as it is not enabled in the default configuration), but please hold off on making substantive changes in the core container until after the Beta 4 release. Comments? Votes? The usual rules apply: [ ] +1 = I agree with this proposal and will support it [ ] +0 = I agree with this proposal, but do not have time to support it [ ] -0 = I do not agree with this proposal, but don't want to try to block it [ ] -1 = I do not agree with this proposal (requires reasons) Craig
Re: [PROPOSAL/VOTE] Tomcat 4.0 Beta 4 Release
Now that the Proposed Final Draft 2 versions of the Servlet 2.3 and JSP 1.2 specs have been published (with Tomcat 4.0 updated to support the latest changes), and a ton of bug fixes have been made, I would like to propose that we create a Tomcat 4.0 Beta 4 release as follows: Release Manager: Craig McClanahan Code Freeze: Thursday, May 10, 2001 at 05:00pm Pacific Time See the file RELEASE-NOTES-4.0-B4.txt for a reasonably up-to-date list of the changes to date. This document will be updated with any additional changes that are made, plus a list of known outstanding issues. Between now and the code freeze, I'd like us to focus on fixing outstanding bugs and catching the configuration documentation up to date. I'm OK with continuing work on the new distributed session stuff in the mean time (as long as it is not enabled in the default configuration), but please hold off on making substantive changes in the core container until after the Beta 4 release. Comments? Votes? The usual rules apply: [ ] +1 = I agree with this proposal and will support it [ ] +0 = I agree with this proposal, but do not have time to support it [ ] -0 = I do not agree with this proposal, but don't want to try to block it [ ] -1 = I do not agree with this proposal (requires reasons) +1. Remy
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets SnoopAllServlet.java
craigmcc01/05/07 20:31:18 Modified:catalina/src/share/org/apache/catalina/servlets SnoopAllServlet.java Log: Reflect the fact that getCookies() can return null. Revision ChangesPath 1.3 +6 -4 jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/SnoopAllServlet.java Index: SnoopAllServlet.java === RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/SnoopAllServlet.java,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- SnoopAllServlet.java 2000/08/22 00:11:37 1.2 +++ SnoopAllServlet.java 2001/05/08 03:31:18 1.3 @@ -1,7 +1,7 @@ /* - * $Header: /home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/SnoopAllServlet.java,v 1.2 2000/08/22 00:11:37 craigmcc Exp $ - * $Revision: 1.2 $ - * $Date: 2000/08/22 00:11:37 $ + * $Header: /home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/SnoopAllServlet.java,v 1.3 2001/05/08 03:31:18 craigmcc Exp $ + * $Revision: 1.3 $ + * $Date: 2001/05/08 03:31:18 $ * * * @@ -84,7 +84,7 @@ * into an HTML page. * * @author Craig R. McClanahan - * @version $Revision: 1.2 $ $Date: 2000/08/22 00:11:37 $ + * @version $Revision: 1.3 $ $Date: 2001/05/08 03:31:18 $ */ public final class SnoopAllServlet @@ -158,6 +158,8 @@ writer.println(libcontextPath/b = + request.getContextPath()); Cookie cookies[] = request.getCookies(); +if (cookies == null) +cookies = new Cookie[0]; for (int i = 0; i cookies.length; i++) writer.println(libcookie/b + cookies[i].getName() + = + cookies[i].getValue());
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/http10 HttpConnector.java HttpRequestImpl.java
craigmcc01/05/07 20:37:04
Modified:catalina/src/conf server.xml
catalina/src/share/org/apache/catalina Connector.java
catalina/src/share/org/apache/catalina/connector/http
HttpConnector.java HttpRequestImpl.java
catalina/src/share/org/apache/catalina/connector/http10
HttpConnector.java HttpRequestImpl.java
Log:
Make it possible to disable DNS lookups of the remote host name, for
Tomcat used stand-alone, even when the web app calls
request.getRemoteHost(). Lookups are enabled by default -- disable them
by modifying the Connector ... disableLookups .../ attribute.
Submitted by: Roy T. Fielding [EMAIL PROTECTED]
Revision ChangesPath
1.22 +3 -0 jakarta-tomcat-4.0/catalina/src/conf/server.xml
Index: server.xml
===
RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/src/conf/server.xml,v
retrieving revision 1.21
retrieving revision 1.22
diff -u -r1.21 -r1.22
--- server.xml2001/04/27 00:34:00 1.21
+++ server.xml2001/05/08 03:37:01 1.22
@@ -45,6 +45,7 @@
!-- Define a non-SSL HTTP/1.1 Connector on port 8080 --
Connector className=org.apache.catalina.connector.http.HttpConnector
port=8080 minProcessors=5 maxProcessors=75
+ disableLookups=false
acceptCount=10 debug=0 connectionTimeout=6/
!-- Note : To disable connection timeouts, set connectionTimeout value
to -1 --
@@ -53,6 +54,7 @@
!--
Connector className=org.apache.catalina.connector.http.HttpConnector
port=8443 minProcessors=5 maxProcessors=75
+ disableLookups=false
acceptCount=10 debug=0 scheme=https secure=true
Factory className=org.apache.catalina.net.SSLServerSocketFactory
clientAuth=false protocol=TLS/
@@ -72,6 +74,7 @@
!--
Connector className=org.apache.catalina.connector.http10.HttpConnector
port=8082 minProcessors=5 maxProcessors=75
+ disableLookups=false
acceptCount=10 debug=0/
--
1.3 +18 -4
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/Connector.java
Index: Connector.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/Connector.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- Connector.java2000/09/08 22:29:34 1.2
+++ Connector.java2001/05/08 03:37:02 1.3
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/Connector.java,v
1.2 2000/09/08 22:29:34 craigmcc Exp $
- * $Revision: 1.2 $
- * $Date: 2000/09/08 22:29:34 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/Connector.java,v
1.3 2001/05/08 03:37:02 craigmcc Exp $
+ * $Revision: 1.3 $
+ * $Date: 2001/05/08 03:37:02 $
*
*
*
@@ -117,7 +117,7 @@
* normative.
*
* @author Craig R. McClanahan
- * @version $Revision: 1.2 $ $Date: 2000/09/08 22:29:34 $
+ * @version $Revision: 1.3 $ $Date: 2001/05/08 03:37:02 $
*/
public interface Connector {
@@ -140,6 +140,20 @@
* @param container The new Container to use
*/
public void setContainer(Container container);
+
+
+/**
+ * Return the disable DNS lookups flag.
+ */
+public boolean getDisableLookups();
+
+
+/**
+ * Set the disable DNS lookups flag.
+ *
+ * @param disableLookups The new disable DNS lookups flag value
+ */
+public void setDisableLookups(boolean disableLookups);
/**
1.13 +32 -4
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/http/HttpConnector.java
Index: HttpConnector.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/http/HttpConnector.java,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -r1.12 -r1.13
--- HttpConnector.java2001/04/12 01:06:12 1.12
+++ HttpConnector.java2001/05/08 03:37:02 1.13
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/http/HttpConnector.java,v
1.12 2001/04/12 01:06:12 craigmcc Exp $
- * $Revision: 1.12 $
- * $Date: 2001/04/12 01:06:12 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/http/HttpConnector.java,v
1.13 2001/05/08 03:37:02 craigmcc Exp $
+ * $Revision: 1.13 $
+ * $Date: 2001/05/08
cvs commit: jakarta-tomcat-4.0/catalina/docs/config http11.html
craigmcc01/05/07 20:42:21 Modified:catalina/docs/config http11.html Log: Update the configuration docs to reflect the new disableLookups option. Revision ChangesPath 1.4 +10 -0 jakarta-tomcat-4.0/catalina/docs/config/http11.html Index: http11.html === RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/docs/config/http11.html,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- http11.html 2001/04/12 01:06:11 1.3 +++ http11.html 2001/05/08 03:42:21 1.4 @@ -106,6 +106,16 @@ /tr tr +tdcodedisableLookups/code/td +td + Set this attribute to codetrue/code to disable DNS lookups of the + remote host name when coderequest.getRemoteHost()/code is called. + If lookups are disabled, the remote IP address (as a String) is + returned instead. By default, DNS lookups are enabled. +/td + /tr + + tr tdcodemaxProcessors/code/td td The maximum number of processor threads that will ever be created by
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/warp WarpConnector.java
craigmcc01/05/07 21:12:41
Modified:catalina build.xml
catalina/src/conf server.xml
catalina/src/share/org/apache/catalina/connector/warp
WarpConnector.java
Log:
Re-enable compiling and starting the Java side of the warp connector.
Revision ChangesPath
1.38 +1 -4 jakarta-tomcat-4.0/catalina/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/build.xml,v
retrieving revision 1.37
retrieving revision 1.38
diff -u -r1.37 -r1.38
--- build.xml 2001/04/27 00:33:59 1.37
+++ build.xml 2001/05/08 04:12:37 1.38
@@ -106,7 +106,6 @@
classpath=${parser.jar}:${jaxp.jar}:${regexp.jar}:${servlet.jar}:${jcert.jar}:${jnet.jar}:${jsse.jar}:${jmxri.jar}
deprecation=off debug=on optimize=off target=1.2
excludes=**/CVS/**
- exclude name=**/warp/*.java/
exclude name=**/factory/Tyrex*.java
unless=tyrex.present /
exclude name=**/factory/ResourceFactory.java
@@ -233,11 +232,9 @@
jar jarfile=${catalina.deploy}/server/lib/catalina.jar
basedir=${catalina.build}/classes
excludes=**/org/apache/naming/**,**/connector/warp/**,org/apache/catalina/startup/Bootstrap.class,org/apache/catalina/loader/StandardClassLoader*.class,org/apache/catalina/loader/Extension.class,org/apache/catalina/loader/Reloader.class
/
-!--
jar jarfile=${catalina.deploy}/server/lib/warp.jar
basedir=${catalina.build}/classes
includes=**/connector/warp/** /
---
/target
@@ -280,7 +277,7 @@
jar jarfile=${catalina.dist}/server/lib/catalina.jar
basedir=${catalina.build}/classes
excludes=**/org/apache/naming/**,**/connector/warp/** /
-jar jarfile=${catalina.dist}/server/lib/catalina.jar
+jar jarfile=${catalina.dist}/server/lib/warp.jar
basedir=${catalina.build}/classes
includes=**/connector/warp/** /
1.23 +1 -14 jakarta-tomcat-4.0/catalina/src/conf/server.xml
Index: server.xml
===
RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/src/conf/server.xml,v
retrieving revision 1.22
retrieving revision 1.23
diff -u -r1.22 -r1.23
--- server.xml2001/05/08 03:37:01 1.22
+++ server.xml2001/05/08 04:12:38 1.23
@@ -297,40 +297,27 @@
!-- Define an Apache-Connector Service --
-!--
Service name=Tomcat-Apache
---
-!--
Connector className=org.apache.catalina.connector.warp.WarpConnector
port=8008 minProcessors=5 maxProcessors=75
+ disableLookups=false
acceptCount=10 debug=0/
---
!-- Replace localhost with what your Apache ServerName is set to --
-!--
Engine className=org.apache.catalina.connector.warp.WarpEngine
name=Apache defaultHost=localhost debug=0 appBase=webapps
---
!-- Global logger unless overridden at lower levels --
-!--
Logger className=org.apache.catalina.logger.FileLogger
prefix=apache_log. suffix=.txt
timestamp=true/
---
!-- Because this Realm is here, an instance will be shared globally --
-!--
Realm className=org.apache.catalina.realm.MemoryRealm /
---
-!--
/Engine
---
-!--
/Service
---
/Server
1.9 +17 -1
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/warp/WarpConnector.java
Index: WarpConnector.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/warp/WarpConnector.java,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- WarpConnector.java2001/01/24 23:10:43 1.8
+++ WarpConnector.java2001/05/08 04:12:40 1.9
@@ -78,7 +78,7 @@
* @author a href=mailto:[EMAIL PROTECTED];Pier Fumagalli/a
* @author Copyright copy; 1999, 2000 a href=http://www.apache.org;The
* Apache Software Foundation.
- * @version CVS $Id: WarpConnector.java,v 1.8 2001/01/24 23:10:43 pier Exp $
+ * @version CVS $Id: WarpConnector.java,v 1.9 2001/05/08 04:12:40 craigmcc Exp $
*/
public class WarpConnector implements Connector, Lifecycle, Runnable {
@@ -99,6 +99,8 @@
private boolean started=false;
/** The accept count for the server socket. */
private int count = 10;
+/** Should we disable DNS lookups? */
+private boolean disableLookups = false;
// BEAN PROPERTIES
@@ -308,6 +310,20 @@
else this.debug(Setting container +container.getInfo());
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/warp WarpConnector.java
craigmcc01/05/07 22:58:44 Modified:catalina/docs/config http11.html catalina/src/conf server.xml catalina/src/share/org/apache/catalina Connector.java catalina/src/share/org/apache/catalina/connector/http HttpConnector.java HttpRequestImpl.java catalina/src/share/org/apache/catalina/connector/http10 HttpConnector.java HttpRequestImpl.java catalina/src/share/org/apache/catalina/connector/warp WarpConnector.java Log: Avoid confusing users with a double negative, by changing disableLookups to enableLookups instead. The default in the example config file is still to have lookups enabled, because that is what new Tomcat users expect, but it is easy to turn this off. Submitted by: Roy Fielding [EMAIL PROTECTED] Revision ChangesPath 1.5 +2 -2 jakarta-tomcat-4.0/catalina/docs/config/http11.html Index: http11.html === RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/docs/config/http11.html,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- http11.html 2001/05/08 03:42:21 1.4 +++ http11.html 2001/05/08 05:58:43 1.5 @@ -106,9 +106,9 @@ /tr tr -tdcodedisableLookups/code/td +tdcodeenableLookups/code/td td - Set this attribute to codetrue/code to disable DNS lookups of the + Set this attribute to codetrue/code to enable DNS lookups of the remote host name when coderequest.getRemoteHost()/code is called. If lookups are disabled, the remote IP address (as a String) is returned instead. By default, DNS lookups are enabled. 1.24 +11 -4 jakarta-tomcat-4.0/catalina/src/conf/server.xml Index: server.xml === RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/src/conf/server.xml,v retrieving revision 1.23 retrieving revision 1.24 diff -u -r1.23 -r1.24 --- server.xml2001/05/08 04:12:38 1.23 +++ server.xml2001/05/08 05:58:43 1.24 @@ -40,12 +40,18 @@ * Execute: keytool -genkey -alias tomcat -keyalg RSA with a password value of changeit. + By default, DNS lookups are enabled when a web application calls + request.getRemoteHost(). This can have an adverse impact on + performance, so you can disable it by setting the + enableLookups attribute to false. When DNS lookups are disabled, + request.getRemoteHost() will return the String version of the + IP address of the remote client. -- !-- Define a non-SSL HTTP/1.1 Connector on port 8080 -- Connector className=org.apache.catalina.connector.http.HttpConnector port=8080 minProcessors=5 maxProcessors=75 - disableLookups=false + enableLookups=true acceptCount=10 debug=0 connectionTimeout=6/ !-- Note : To disable connection timeouts, set connectionTimeout value to -1 -- @@ -54,7 +60,7 @@ !-- Connector className=org.apache.catalina.connector.http.HttpConnector port=8443 minProcessors=5 maxProcessors=75 - disableLookups=false + enableLookups=true acceptCount=10 debug=0 scheme=https secure=true Factory className=org.apache.catalina.net.SSLServerSocketFactory clientAuth=false protocol=TLS/ @@ -66,6 +72,7 @@ !-- Connector className=org.apache.catalina.connector.http.HttpConnector port=8081 minProcessors=5 maxProcessors=75 + enableLookups=true acceptCount=10 debug=0 connectionTimeout=6 proxyPort=80/ -- @@ -74,7 +81,7 @@ !-- Connector className=org.apache.catalina.connector.http10.HttpConnector port=8082 minProcessors=5 maxProcessors=75 - disableLookups=false + enableLookups=true acceptCount=10 debug=0/ -- @@ -301,7 +308,7 @@ Connector className=org.apache.catalina.connector.warp.WarpConnector port=8008 minProcessors=5 maxProcessors=75 - disableLookups=false + enableLookups=true acceptCount=10 debug=0/ !-- Replace localhost with what your Apache ServerName is set to -- 1.4 +9 -9 jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/Connector.java Index: Connector.java === RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/Connector.java,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4
