RE: [4.0-HEAD] JSP source exposure ?
I had a few spare minutes so I went ahead and grabbed last night's build. I ran it on Red Hat Linux 7.2 and can confirm the report. Requesting foo.jsp%00.txt gets you the source. Requesting foo.jsp%00 gets you a strange page that includes some html widgets and some of the jsp source too. Surprising (at least to me) and ugly. -David -Original Message- From: Remy Maucherat [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 16, 2002 2:18 PM To: [EMAIL PROTECTED] Subject: [4.0-HEAD] JSP source exposure ? Hi, I got a report about a URL based exploit against the nightly builds for TC 4 (4.0-HEAD). Basically, accessing foo.jsp%00 (or foo.jsp%00.txt) is supposed to get the source code for foo.jsp. I cannot reproduce the problem when Tomcat is running on Windows (I get a 404 for that kind of URLs). However, since I refactored the URL handling, this kind of problem may have been reintroduced. If I could get reports from people running the nightlies on Unix, that would be nice. Note: If there's a problem, it would be a good idea for the URL decoding method to complain when it encounters a null character when decoding a %xx, as I don't see a single valid use case for that (except in URL based attacks, of course). Thanks, Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[PATCH] TC3.3.1 sendError(404, msg) ignores msg
Short version:
Here's a patch that modifies the NotFoundHandler to incorporate the
msg from sendError(sc, msg) into the html response body. Currently, the
passed in msg is ignored.
Long version:
I know the servlet spec lets the server decide what the response body will
contain, and I know the ErrorHandler is just a default, but is there an
important reason why the NotFoundHandler shouldn't incorporate the msg ?
Currently if you call sendError(404, msg), the returned response does not
include the message because it gets sent to the NotFoundHandler (which
ignores it). Other status codes go through the StatusHandler and the
specified msg is incorporated into the response.
I can't think of an important reason to suppress the msg and think it might
be nice to see it. That way you could easily use sendError to send back an
href or other information giving the user a way to report a problem or get
help. This came up for us when a page we had served up had a bad link in
it. I know there are better ways to do this but having sendError honor the
msg on a 404 is cheap and lets us get out an easy fix while we work on
something better ...
Anyway, here it is in case anyone else thinks it's a good idea.
Cheers,
-David
--- ErrorHandler.java.orig Tue Mar 5 19:50:50 2002
+++ ErrorHandler.java Fri Mar 22 12:26:32 2002
@@ -484,6 +484,7 @@
public void doService(Request req, Response res)
throws Exception
{
+ String msg=(String)req.getAttribute(javax.servlet.error.message);
res.setContentType(text/html);// ISO-8859-1 default
// javax.servlet.include.request_uri is set to this handler
@@ -524,6 +525,12 @@
.append( HttpMessages.filter( requestURI ) )
.append(\r\n);
}
+
+ if (msg != null){
+buf.append(brbr\r\nb)
+.append(msg)
+.append(/bbr\r\n);
+}
// only add /body if reset was successful
if ( needsHead )
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[PATCH] Fix typo in jtc/jk/native/nt_server/jk_nt_service.c
usage_message() says lphanumeric instead of alphanumeric
-David
--- jk_nt_service.c.origThu Mar 21 16:52:21 2002
+++ jk_nt_service.c Thu Mar 21 16:52:29 2002
@@ -173,7 +173,7 @@
printf(%s -i service name {optional params} config properties file\n, name);
printf(Optional parameters\n);
printf(-u user name - In the form DomainName\\UserName (.\\UserName
for local)\n);
-printf(-n service display name - In quotes if contains non-lphanumeric
chars\n);
+printf(-n service display name - In quotes if contains
+non-alphanumeric chars\n);
printf(-p user password\n);
printf(-a - Set startup type to automatic\n);
printf(-d service dependency - Can be entered multiple times\n\n);
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: cvs commit: jakarta-tomcat-connectors/jk/native/nt_service jk_nt_service.c
Hi Costin,
This merge from 3.3 doesn't include the -n option that Larry added 2 weeks
ago. It allows for specifying a display name separately from the service
name since the rules for what is a valid name differ in each case. For
example, the display name is allowed to contain spaces while the service
name is not.
Was it left behind on purpose?
I have a tough time keeping up with all the great stuff you're checking in
but I'm trying.
Thanks,
-David
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Thursday, March 14, 2002 9:44 AM
To: [EMAIL PROTECTED]
Subject: cvs commit: jakarta-tomcat-connectors/jk/native/nt_service
jk_nt_service.c
costin 02/03/14 09:43:47
Modified:jk/native/nt_service jk_nt_service.c
Log:
Merged changes from 3.3
Addition of stop_cmd, allowing the stop to be done by executing
a command. ( catalina shutdown protocol is already supported )
Removed some of the checks for settings that are not required.
If cmd_line is specified, there is no need for server.xml
or other tomcat-specific things.
cmd_line, stdout, stderr are required.
Revision ChangesPath
1.4 +288 -79
jakarta-tomcat-connectors/jk/native/nt_service/jk_nt_service.c
Index: jk_nt_service.c
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/jk/native/nt_service/jk_nt_service.c,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- jk_nt_service.c 17 Jan 2002 21:17:02 - 1.3
+++ jk_nt_service.c 14 Mar 2002 17:43:47 - 1.4
@@ -58,14 +58,14 @@
/***
* Description: NT System service for Jakarta/Tomcat
*
* Author: Gal Shachor [EMAIL PROTECTED]
*
- * Version: $Revision: 1.3 $
*
+ * Dave Oxley [EMAIL PROTECTED]
*
+ * Version: $Revision: 1.4 $
*
***/
#include jk_global.h
#include jk_util.h
#include jk_ajp13.h
#include jk_connect.h
-
#include windows.h
#include stdio.h
#include stdlib.h
@@ -86,23 +86,39 @@
static HANDLE hServerStopEvent = NULL;
static int shutdown_port;
static char*shutdown_protocol = AJP12_TAG;
-static char*shutdown_secret = NULL;
+static char*shutdown_secret = NULL;
+static char*shutdown_cmd=NULL;
+
+typedef enum ActionEnum
+{ acNoAction = 0,
+acInstall = 1,
+acRemove= 2,
+acStartTC = 3,
+acStopTC= 4
+} ActionEnum;
+
struct jk_tomcat_startup_data {
-char *classpath;
-char *tomcat_home;
+char *cmd_line; /* Start command line */
char *stdout_file;
char *stderr_file;
+char *extra_path;
+char *tomcat_home;
char *java_bin;
-char *tomcat_class;
-char *server_file;
-char *cmd_line;
-int shutdown_port;
+
char *shutdown_protocol;
+/* for cmd */
+char *stop_cmd;
+/* For ajp13/ajp12/catalina */
+int shutdown_port;
char *shutdown_secret;
-char *extra_path;
+/* Optional/not needed */
+char *classpath;
+char *tomcat_class;
+char *server_file;
};
+
typedef struct jk_tomcat_startup_data jk_tomcat_startup_data_t;
// internal function prototypes
@@ -110,8 +126,16 @@
static void WINAPI service_main(DWORD dwArgc,
char **lpszArgv);
static void install_service(char *name,
-char *prp_file);
+char *user,
+char *password,
+char *deps,
+BOOL bAutomatic,
+char *rel_prp_file);
static void remove_service(char *name);
+static void start_service(char *name,
+ char *machine);
+static void stop_service(char *name,
+ char *machine);
static char *GetLastErrorText(char *lpszBuf, DWORD dwSize);
static void AddToMessageLog(char *lpszMsg);
static BOOL ReportStatusToSCMgr(DWORD dwCurrentState,
@@ -131,34 +155,59 @@
char *b, DWORD sz);
static int start_tomcat(const char *name,
HANDLE *hTomcat);
-static void stop_tomcat(short port,
+static void stop_tomcat(char *name,
+short port,
const char *protocol,
- char *secret,
-HANDLE hTomcat);
+char *secret,
+HANDLE hTomcat);
static int read_startup_data(jk_map_t *init_map,
RE: cvs commit: jakarta-tomcat-connectors/jk/native/nt_service jk _nt_service.c
Costin, One of my initial patches for this followed a similar strategy of morphing the display name into something usable as a service name. In fact, this is the approach I've used with other products in the past. However, I settled on being able to specify the names separately when I found that a lot of vendors use totally different names for the display name vs the service name. For example, internal name for NetMeeting Remote Desktop Sharing is mnmsrvc. I know this isn't a big deal but I think it is nice to have such flexibility. -David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Thursday, March 14, 2002 11:10 AM To: Tomcat Developers List Subject: RE: cvs commit: jakarta-tomcat-connectors/jk/native/nt_service jk _nt_service.c On Thu, 14 Mar 2002, Schreibman, David wrote: Hi Costin, This merge from 3.3 doesn't include the -n option that Larry added 2 weeks ago. It allows for specifying a display name separately from the service name since the rules for what is a valid name differ in each case. For example, the display name is allowed to contain spaces while the service name is not. Was it left behind on purpose? Ops, I may have an old version, I'll check. Thanks. BTW, I have another change ( contributed by WRowe ) to allow spaces in names and few other improvements ( it is leaving the name with spaces as display name, and removing the spaces for the internal name ). The -n is a different solution ( you specify both names in the command line ). After 3.3.1 is released I would like to remove nt_service from jakarta-tomcat CVS. The version in j-t-c has few additional fixes and improvements ( including the ability to execute a program to stop, support for catalina shutdown protocol, etc ). Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: cvs commit: jakarta-tomcat-connectors/jk/native/nt_service jk _nt_service.c
Sounds like a good plan. I know you all have a ton of work to do so I was
just pointing out a tiny thing that caught my attention. I always like to
speak up and possibly seem foolish than keep things to myself that might
actually matter.
Thanks again for all the time y'all put into keeping this great thing going.
-David
-Original Message-
From: Larry Isaacs [mailto:[EMAIL PROTECTED]]
Sent: Thursday, March 14, 2002 11:04 AM
To: 'Tomcat Developers List'
Subject: RE: cvs commit: jakarta-tomcat-connectors/jk/native/nt_service
jk _nt_service.c
David,
I believe the J-T-C version of jk_nt_service.c is more out of
sync than just this. This is why I didn't apply your patch
to the J-T-C version when I applied it to jakarta-tomcat.
It is on my to do list to get them back in sync after
Tomcat 3.3.1 is final.
Cheers,
Larry
-Original Message-
From: Schreibman, David [mailto:[EMAIL PROTECTED]]
Sent: Thursday, March 14, 2002 1:31 PM
To: 'Tomcat Developers List'
Subject: RE: cvs commit:
jakarta-tomcat-connectors/jk/native/nt_service jk _nt_service.c
Hi Costin,
This merge from 3.3 doesn't include the -n option that Larry
added 2 weeks ago. It allows for specifying a display name
separately from the service name since the rules for what is
a valid name differ in each case. For example, the display
name is allowed to contain spaces while the service name is not.
Was it left behind on purpose?
I have a tough time keeping up with all the great stuff
you're checking in but I'm trying.
Thanks,
-David
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Thursday, March 14, 2002 9:44 AM
To: [EMAIL PROTECTED]
Subject: cvs commit: jakarta-tomcat-connectors/jk/native/nt_service
jk_nt_service.c
costin 02/03/14 09:43:47
Modified:jk/native/nt_service jk_nt_service.c
Log:
Merged changes from 3.3
Addition of stop_cmd, allowing the stop to be done by executing
a command. ( catalina shutdown protocol is already supported )
Removed some of the checks for settings that are not required.
If cmd_line is specified, there is no need for server.xml
or other tomcat-specific things.
cmd_line, stdout, stderr are required.
Revision ChangesPath
1.4 +288 -79
jakarta-tomcat-connectors/jk/native/nt_service/jk_nt_service.c
Index: jk_nt_service.c
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/jk/native/nt_service/jk_nt
_service.c,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- jk_nt_service.c 17 Jan 2002 21:17:02 - 1.3
+++ jk_nt_service.c 14 Mar 2002 17:43:47 - 1.4
@@ -58,14 +58,14 @@
/*
**
* Description: NT System service for Jakarta/Tomcat
*
* Author: Gal Shachor [EMAIL PROTECTED]
*
- * Version: $Revision: 1.3 $
*
+ * Dave Oxley [EMAIL PROTECTED]
*
+ * Version: $Revision: 1.4 $
*
**
*/
#include jk_global.h
#include jk_util.h
#include jk_ajp13.h
#include jk_connect.h
-
#include windows.h
#include stdio.h
#include stdlib.h
@@ -86,23 +86,39 @@
static HANDLE hServerStopEvent = NULL;
static int shutdown_port;
static char*shutdown_protocol = AJP12_TAG;
-static char*shutdown_secret = NULL;
+static char*shutdown_secret = NULL;
+static char*shutdown_cmd=NULL;
+
+typedef enum ActionEnum
+{ acNoAction = 0,
+acInstall = 1,
+acRemove= 2,
+acStartTC = 3,
+acStopTC= 4
+} ActionEnum;
+
struct jk_tomcat_startup_data {
-char *classpath;
-char *tomcat_home;
+char *cmd_line; /* Start command line */
char *stdout_file;
char *stderr_file;
+char *extra_path;
+char *tomcat_home;
char *java_bin;
-char *tomcat_class;
-char *server_file;
-char *cmd_line;
-int shutdown_port;
+
char *shutdown_protocol;
+/* for cmd */
+char *stop_cmd;
+/* For ajp13/ajp12/catalina */
+int shutdown_port;
char *shutdown_secret;
-char *extra_path;
+/* Optional/not needed */
+char *classpath;
+char *tomcat_class;
+char *server_file;
};
+
typedef struct jk_tomcat_startup_data jk_tomcat_startup_data_t;
// internal function prototypes
@@ -110,8 +126,16 @@
static void WINAPI service_main(DWORD dwArgc,
char **lpszArgv);
static void install_service(char *name,
-char *prp_file
RE: cvs commit: jakarta-tomcat/src/etc/jk wrapper.properties
Hi Larry, Thanks for checking this in. By the way, what's up with -Djava.security.policy==$(wrapper.tomcat_policy) ? Is the == intentional? I had changed it to just = in the patch I submitted but I noticed that you left it in. Just curious and didn't want to pass up the chance to learn something Thanks, -David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Tuesday, March 12, 2002 7:40 PM To: [EMAIL PROTECTED] Subject: cvs commit: jakarta-tomcat/src/etc/jk wrapper.properties larryi 02/03/12 19:40:07 Modified:src/etc/jk wrapper.properties Log: Added quotes around wrapper.javabin in the wrapper.cmd_line. Submitted by: David Schreibman Added wrapper.jvm.options and some documentation. Revision ChangesPath 1.4 +24 -4 jakarta-tomcat/src/etc/jk/wrapper.properties Index: wrapper.properties === RCS file: /home/cvs/jakarta-tomcat/src/etc/jk/wrapper.properties,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- wrapper.properties13 Oct 2001 02:25:13 - 1.3 +++ wrapper.properties13 Mar 2002 03:40:07 - 1.4 @@ -1,7 +1,7 @@ # -# $Header: /home/cvs/jakarta-tomcat/src/etc/jk/wrapper.properties,v 1.3 2001/10/13 02:25:13 billbarker Exp $ -# $Revision: 1.3 $ -# $Date: 2001/10/13 02:25:13 $ +# $Header: /home/cvs/jakarta-tomcat/src/etc/jk/wrapper.properties,v 1.4 2002/03/13 03:40:07 larryi Exp $ +# $Revision: 1.4 $ +# $Date: 2002/03/13 03:40:07 $ # # # jk_service.properties - a bootstrup file for the Tomcat NT service. @@ -100,17 +100,37 @@ # wrapper.shutdown_port tells the service the identity of the port that # is used by AJP12/AJP13. # +# Ajp12 wrapper.shutdown_port=8007 +# Ajp13 +#wrapper.shutdown_port=8009 + # # Can either be ajp12 or ajp13 depending on your configuration. # +# Note: If you use ajp13, be sure to enable shutdown on the Ajp13Connector. +# For Tomcat 3.3 add: shutDownEnable=true +# For Tomcat 3.3.1 add: shutdownEnable=true or shutDownEnable=true +# +# Note: Use of a shutdown secret (i.e. password) is not supported. +# # Default value is ajp12 # wrapper.shutdown_protocol=ajp12 # +# JVM Options +# +# Useful Options: +# -Xms256m= Initial heap size, modify for desired size +# -Xmx256m= Maximum heap size, modify for desired size +# -Xrs= Available in Jdk1.3.1 to avoid JVM termination during logoff +# +wrapper.jvm.options= + +# # This is the command line that is used to start Tomcat. You can *add* extra # parameters to it but you can not remove anything. # -wrapper.cmd_line=$(wrapper.javabin) -Djava.security.policy==$(wrapper.tomcat_policy) -Dtomcat.home=$(wrapper.tomcat_home) -classpath $(wrapper.class_path) $(wrapper.startup_class) -config $(wrapper.server_xml) +wrapper.cmd_line=$(wrapper.javabin) $(wrapper.jvm.options) -Djava.security.policy==$(wrapper.tomcat_policy) -Dtomcat.home=$(wrapper.tomcat_home) -classpath $(wrapper.class_path) $(wrapper.startup_class) -config $(wrapper.server_xml) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[PATCH] small tweaks to wrapper.properties from the head of jakarta-tomcat
This patch makes 2 minor changes to the wrapper.cmd_line 1) removes extra equals sign from the security policy assignment 2) adds quotes around wrapper.javabin so that JDK paths with spaces will work. For example c:\Program Files\Javasoft\JRE\1.3.1_02\bin\java.exe -David patch.txt --- wrapper.properties.orig Fri Mar 1 16:06:11 2002 +++ wrapper.properties Fri Mar 1 16:01:51 2002 @@ -113,4 +113,4 @@ # This is the command line that is used to start Tomcat. You can *add* extra # parameters to it but you can not remove anything. # -wrapper.cmd_line=$(wrapper.javabin) -Djava.security.policy==$(wrapper.tomcat_policy) -Dtomcat.home=$(wrapper.tomcat_home) -classpath $(wrapper.class_path) $(wrapper.startup_class) -config $(wrapper.server_xml) +wrapper.cmd_line=$(wrapper.javabin) +-Djava.security.policy=$(wrapper.tomcat_policy) +-Dtomcat.home=$(wrapper.tomcat_home) -classpath $(wrapper.class_path) +$(wrapper.startup_class) -config $(wrapper.server_xml) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: DO NOT REPLY [Bug 5881] - DB2 JDBC: no suitable driver!
You have to rename the file db2java.zip to db2java.jar. Previous versions of Tomcat were not as strict about the requirement for classes to be stored in jar files -David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 16, 2002 6:41 AM To: [EMAIL PROTECTED] Subject: DO NOT REPLY [Bug 5881] - DB2 JDBC: no suitable driver! DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5881. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5881 DB2 JDBC: no suitable driver! [EMAIL PROTECTED] changed: What|Removed |Added Priority|Other |High -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
PATCH: NT Service display name should not be used as service name
Hi,
We've encountered a problem with the way jk_nt_service.c creates nt
services.
Specifically, the call to CreateService uses the name passed in for the
service as both the service name and the service display name. This is a
problem because there are restrictions on the service name that do not apply
to the display name. The MS documentation states that neither forward nor
back slashes are allowed but in practice I have found that other characters
cause problems as well.
For example, if you create a service via jk_nt_service -i My Service
wrapper.properties the service creates just fine but it fails to start.
Since the MS source is not readily available we can't check on what the REAL
rules are for the internal service name.
To be safe, a solution I have used in the past is to treat the name passed
in via the command line as the display name, and then remove all
non-alphanumeric characters to generate the internal service name.
This is cheap, but might cause trouble if you are unlucky enough to have
multiple service display names mapping to a single internal name as in My
Service 1.1 and My Service 11.
An alternative that fixes this is to convert non alphanumerics to their hex
representation.
I've attached a patch using the first approach since I've used in in the
past without any problems. I'll be happy to rework it to hex encode non
alphanumerics if there is interest.
-David
--- jk_nt_service.c.origSun Oct 21 13:25:54 2001
+++ jk_nt_service.c Wed Dec 19 17:59:38 2001
@@ -113,16 +113,22 @@
static void WINAPI service_ctrl(DWORD dwCtrlCode);
static void WINAPI service_main(DWORD dwArgc,
char **lpszArgv);
+
+static char *sanitize_service_name(char *displayName);
static void install_service(char *name,
+ char *dname,
char *user,
char *password,
char *deps,
BOOL bAutomatic,
char *rel_prp_file);
-static void remove_service(char *name);
+static void remove_service(char *name,
+ char *dname);
static void start_service(char *name,
+ char *dname,
char *machine);
static void stop_service(char *name,
+char *dname,
char *machine);
static char *GetLastErrorText(char *lpszBuf, DWORD dwSize);
static void AddToMessageLog(char *lpszMsg);
@@ -132,6 +138,7 @@
static void start_jk_service(char *name);
static void stop_jk_service(void);
static int set_registry_values(char *name,
+ char *dname,
char *prp_file);
static int create_registry_key(const char *tag,
HKEY *key);
@@ -182,6 +189,7 @@
int count;
int iAction = acNoAction;
char *pServiceName = NULL;
+char *pServiceDisplayName = NULL;
char *pUserName = NULL;
char *pPassword = NULL;
char *pMachine = NULL;
@@ -219,16 +227,16 @@
cmd++;
if(0 == stricmp(i, cmd)) {
iAction = acInstall;
-pServiceName = argv[i+1];
+pServiceDisplayName = argv[i+1];
} else if(0 == stricmp(r, cmd)) {
iAction = acRemove;
-pServiceName = argv[i+1];
+pServiceDisplayName = argv[i+1];
} else if(0 == stricmp(s, cmd)) {
iAction = acStartTC;
-pServiceName = argv[i+1];
+pServiceDisplayName = argv[i+1];
} else if(0 == stricmp(t, cmd)) {
iAction = acStopTC;
-pServiceName = argv[i+1];
+pServiceDisplayName = argv[i+1];
} else if(0 == stricmp(u, cmd)) {
pUserName = argv[i+1];
} else if(0 == stricmp(p, cmd)) {
@@ -243,18 +251,19 @@
}
}
}
+ pServiceName = sanitize_service_name(pServiceDisplayName);
switch (iAction) {
case acInstall:
-install_service(pServiceName, pUserName, pPassword, strDependancy,
bAutomatic, argv[i-1]);
+install_service(pServiceName, pServiceDisplayName, pUserName,
+pPassword, strDependancy, bAutomatic, argv[i-1]);
return;
case acRemove:
-remove_service(pServiceName);
+remove_service(pServiceName, pServiceDisplayName);
return;
case acStartTC:
-start_service(pServiceName, pMachine);
+start_service(pServiceName, pServiceDisplayName, pMachine);
return;
case acStopTC:
-
RE: [PATCH] TC 3.3 WebXmlReader.java
Cool.
If and when you decide to check it in, you might want to consider this minor
update applying the same logic to the error handler's warning method. The
previously posted patch only covered calls the to error handler's error and
fatalError methods. I couldn't make up my mind as to whether parser
warnings should impose the same startup penalty but now think it might be a
good idea.
-David
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Friday, November 02, 2001 8:33 AM
To: Tomcat Developers List
Subject: Re: [PATCH] TC 3.3 WebXmlReader.java
On Fri, 2 Nov 2001, Bojan Smojver wrote:
Notice that here, only the second time around things go bad
(at context
reload) and that's only sometimes. Normally, there is nothing in the
logs. Weird...
I'll have to dig into it to find out what it really is. I
might apply
this patch to my local build, just to see if it makes any
difference.
The patch seems ok to me ( thanks David !) - I was planning
to check it
in. If you find any problem let me know.
I added this 'validation mark' to avoid the expensive
validation if the
file was already validated before. Since tomcat can ( or
should be able to
) tolerate some errors in web.xml everything should still
work - but you
get the warning that the file have errors like bad ordering
of elements.
Without the patch you get the warning only once ( or after each
modification of web.xml ). With the patch you'll be warned on
each server
startup and the startup time will be longer until you fix web.xml -
which should give time to read the warnings and be the punishment.
Costin
Some people I work with noticed that Tomcat was spitting
out a web.xml
validation error for their app, but only the first time
they started up.
This gave them the impression that everything was ok the
second time.
Well, I looked around a bit and found that WebXmlReader
writes out a
validation mark (webxmlval.txt) in the work directory.
The timestamp of
the validation mark is used as part of deciding whether
to validate. The
thing is, this mark is written out even if web.xml was
not valid so next
time through validation is skipped.
I'm not sure if this was done on purpose and I can even
imagine an argument
about not nagging more than once. Still, in our case the
disappearance of
the validation errors brought about false confidence.
In case this seems like a problem to anyone else, here's
a patch that only
writes out the validation mark if the XML parsed without
errors. That way
you keep seeing the validation errors until you a)
disable validation or b)
fix the offending xml.
Interestingly, this patch takes advantage of an unused
boolean field in the
error handler. Makes me wonder if somebody already
thought of this but
decided not to deal with it. Perhaps there was a good reason.
Regards,
-David
--
--
--- WebXmlReader.java.origWed Oct 31 13:00:07 2001
+++ WebXmlReader.java Wed Oct 31 12:12:55 2001
@@ -99,7 +99,7 @@
static class WebXmlErrorHandler implements ErrorHandler{
Context ctx;
XmlMapper xm;
- boolean ok;
+ boolean ok = true;
WebXmlErrorHandler( XmlMapper xm,Context ctx ) {
this.ctx=ctx;
this.xm=xm;
@@ -113,16 +113,21 @@
public void error (SAXParseException exception)
throws SAXException
{
+ ok = false;
ctx.log(web.xml: Error + exception );
ctx.log(xm.positionToString());
}
public void fatalError (SAXParseException exception)
throws SAXException
{
+ ok = false;
ctx.log(web.xml: Fatal error + exception );
ctx.log(xm.positionToString());
throw new SAXException( Fatal error + exception );
}
+ public boolean isOk() {
+ return ok;
+ }
}
void processWebXmlFile( Context ctx, String file) {
@@ -134,13 +139,15 @@
}
if( ctx.getDebug() 0 ) ctx.log(Reading + file );
XmlMapper xh=new XmlMapper();
+ WebXmlErrorHandler xeh = null;
File v=new File( ctx.getWorkDir(), webxmlval.txt );
if( validate ) {
if( ! v.exists() ||
v.lastModified() f.lastModified() ) {
ctx.log(Validating web.xml);
xh.setValidating(true);
- xh.setErrorHandler( new WebXmlErrorHandler(
xh, ctx ) );
+ xeh = new WebXmlErrorHandler( xh, ctx );
+ xh.setErrorHandler( xeh );
}
}
@@ -230,7 +237,8 @@
Object ctx1=xh.readXml(f, ctx);
- if( validate ) {
+ if( validate xeh.isOk()) {
+ // don't create/update the validation mark if
an error was detected
try
[PATCH] TC 3.3 WebXmlReader.java
Hi All,
Some people I work with noticed that Tomcat was spitting out a web.xml
validation error for their app, but only the first time they started up.
This gave them the impression that everything was ok the second time.
Well, I looked around a bit and found that WebXmlReader writes out a
validation mark (webxmlval.txt) in the work directory. The timestamp of
the validation mark is used as part of deciding whether to validate. The
thing is, this mark is written out even if web.xml was not valid so next
time through validation is skipped.
I'm not sure if this was done on purpose and I can even imagine an argument
about not nagging more than once. Still, in our case the disappearance of
the validation errors brought about false confidence.
In case this seems like a problem to anyone else, here's a patch that only
writes out the validation mark if the XML parsed without errors. That way
you keep seeing the validation errors until you a) disable validation or b)
fix the offending xml.
Interestingly, this patch takes advantage of an unused boolean field in the
error handler. Makes me wonder if somebody already thought of this but
decided not to deal with it. Perhaps there was a good reason.
Regards,
-David
--- WebXmlReader.java.orig Wed Oct 31 13:00:07 2001
+++ WebXmlReader.java Wed Oct 31 12:12:55 2001
@@ -99,7 +99,7 @@
static class WebXmlErrorHandler implements ErrorHandler{
Context ctx;
XmlMapper xm;
- boolean ok;
+ boolean ok = true;
WebXmlErrorHandler( XmlMapper xm,Context ctx ) {
this.ctx=ctx;
this.xm=xm;
@@ -113,16 +113,21 @@
public void error (SAXParseException exception)
throws SAXException
{
+ ok = false;
ctx.log(web.xml: Error + exception );
ctx.log(xm.positionToString());
}
public void fatalError (SAXParseException exception)
throws SAXException
{
+ ok = false;
ctx.log(web.xml: Fatal error + exception );
ctx.log(xm.positionToString());
throw new SAXException( Fatal error + exception );
}
+ public boolean isOk() {
+ return ok;
+ }
}
void processWebXmlFile( Context ctx, String file) {
@@ -134,13 +139,15 @@
}
if( ctx.getDebug() 0 ) ctx.log(Reading + file );
XmlMapper xh=new XmlMapper();
+ WebXmlErrorHandler xeh = null;
File v=new File( ctx.getWorkDir(), webxmlval.txt );
if( validate ) {
if( ! v.exists() ||
v.lastModified() f.lastModified() ) {
ctx.log(Validating web.xml);
xh.setValidating(true);
- xh.setErrorHandler( new WebXmlErrorHandler( xh, ctx ) );
+ xeh = new WebXmlErrorHandler( xh, ctx );
+ xh.setErrorHandler( xeh );
}
}
@@ -230,7 +237,8 @@
Object ctx1=xh.readXml(f, ctx);
- if( validate ) {
+ if( validate xeh.isOk()) {
+ // don't create/update the validation mark if an error was detected
try {
FileOutputStream fos=new FileOutputStream( v );
fos.write( 1 );
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Where's the 3.3 release build?
Hi, Just wondering what happened to the 3.3 release build at http://jakarta.apache.org/site/binindex.html I'm pretty sure I got a copy from there last week but it's gone now. One of my co-workers was looking to install it today and just came by to ask me about this. Thanks, -David
[PATCH] SimplePool.java
Here's a simple tweak that clears out references to objects that are removed
from the pool. The current code can delay garbage collection for objects
that are removed from the pool but not returned.
The diff is against 3.3-rc1
-David
--- SimplePool.java.origThu Oct 4 10:14:51 2001
+++ SimplePool.java Thu Oct 4 10:54:08 2001
@@ -132,6 +132,7 @@
synchronized( lock ) {
if( current = 0 ) {
item = pool[current];
+ pool[current] = null;
current -= 1;
}
if( debug 0 )
[PATCH] SingleThreadModel Pool for TC 3.3
I'm submitting this with mixed feelings since the recent discussion has
shown strong opinions about the utility of the SingleThreadModel.
I was already in the middle of doing the work when all that came about so I
went ahead and finished it. After reaping the benefits of Tomcat for a
couple of years I've been wanting to give something back. So after a recent
post about how to help, I went into bugzilla and found this issue. I don't
even use STM, but was somewhat familiar with the ServletHandler and figured
I could contribute here.
At a minimum, I had fun doing the work and was able to learn a bit more
about the code base.
Maybe it will be of some use to others.
Looking forward to more good stuff from this project!!
-David
--- ServletHandler.java.origThu Oct 4 15:57:50 2001
+++ ServletHandler.java Thu Oct 4 16:06:28 2001
@@ -59,7 +59,7 @@
package org.apache.tomcat.facade;
import org.apache.tomcat.core.*;
-import org.apache.tomcat.util.*;
+import org.apache.tomcat.util.collections.*;
import java.io.*;
import java.net.*;
import java.util.*;
@@ -106,11 +106,18 @@
public static final int STATE_READY=3;
// Properties
+
+public static final String STM_POOL_SIZE = tomcat.stmpoolsize;
// extra informations - if the servlet is declared in web.xml
private ServletInfo sw;
private String servletClassName;
+
+private SimplePool stmPool; // pool of SingleThreadModel instances
+private int stmPoolSize;
+private int stmInstances; // number of servlet instances already being pooled
+(we create them as needed)
+
protected Class servletClass;
protected Servlet servlet;
protected Context context;
@@ -153,7 +160,6 @@
return context;
}
-
public void setServletClassName( String servletClassName) {
servlet=null; // reset the servlet, if it was set
servletClass=null;
@@ -192,7 +198,6 @@
} catch( Exception ex ) {
log(context, Error during destroy , ex );
}
-
errorException=null;
}
@@ -330,6 +335,14 @@
}
servlet = (Servlet)servletClass.newInstance();
+
+if (servlet instanceof SingleThreadModel) {
+ stmPoolSize = Integer.getInteger(STM_POOL_SIZE,
+SimplePool.DEFAULT_SIZE).intValue();
+ stmPool = new SimplePool(stmPoolSize);
+ stmPool.set(servlet);
+ stmInstances++;
+ }
+
return servlet;
}
@@ -348,7 +361,15 @@
log(context, preServletDestroy, ex);
}
}
- servlet.destroy();
+
+ if (!(servlet instanceof SingleThreadModel)) {
+ servlet.destroy();
+ } else {
+ Servlet sl = null;
+ while ((sl = (Servlet)stmPool.get()) != null) {
+ sl.destroy();
+ }
+ }
for( int i=0; i cI.length; i++ ) {
try {
@@ -432,6 +453,40 @@
super.service( req, res );
}
+protected void doSTMService(HttpServletRequest reqF, HttpServletResponse resF)
+throws Exception {
+ Servlet sl = null;
+ try {
+ boolean newInstance = false;
+ if ((sl = (Servlet)stmPool.get()) == null) {
+ synchronized (this) {
+ if (stmInstances stmPoolSize) {
+ stmInstances++;
+ newInstance = true;
+ }
+ }
+ if (newInstance) {
+ sl = (Servlet)servletClass.newInstance();
+ sl.init(getServletInfo().getServletConfig());
+ }
+
+ }
+
+ if (sl != null) {
+ sl.service(reqF, resF);
+ } else {
+ // The pool is full, just synchronize on the initial instance.
+ // Ideally, we would the pain across all pooled instances
+ // to avoid a bottleneck on a single instance.
+ synchronized(servlet) {
+ servlet.service(reqF, resF);
+ }
+ }
+ } finally {
+ if (sl != null) {
+ stmPool.put(sl);
+ }
+ }
+}
protected void doService(Request req, Response res)
throws Exception
@@ -476,10 +531,8 @@
try {
// We are initialized and fine
- if (servlet instanceof SingleThreadModel) {
- synchronized(servlet) {
- servlet.service(reqF, resF);
- }
+ if ( servlet instanceof SingleThreadModel ) {
+ doSTMService(reqF, resF);
} else {
servlet.service(reqF, resF);
}
RE: DO NOT REPLY [Bug 3851] - SingleThreadModel ignored
FYI: I'm taking a look at implementing a pool for this since it seems like a
fun task. If nobody beats me to it, I'll post my attempt when it's ready.
-David
-Original Message-
From: Bill Barker [mailto:[EMAIL PROTECTED]]
Sent: Sunday, September 30, 2001 9:22 PM
To: [EMAIL PROTECTED]
Subject: Re: DO NOT REPLY [Bug 3851] - SingleThreadModel ignored
While pooling was a very nice feature of JServe (which I have
personally
taken advantage of in the past), the operative word in the
spec is may.
The 3.x and 4.0 implementations are entirely within their
rights within the
spec to simply synchronize.
In other words, this comes under the if it itches, scratch
it yourself
clause of OS development. (personally, I can still tolerate
the itching, but
would +1 someone else taking this on).
- Original Message -
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Sunday, September 30, 2001 5:37 PM
Subject: DO NOT REPLY [Bug 3851] - SingleThreadModel ignored
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3851.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3851
SingleThreadModel ignored
--- Additional Comments From [EMAIL PROTECTED] 2001-09-30
17:37 ---
After reading the source for TC 3.3, I can now see I was
totally wrong
about the
pool approach. There are comments about it in the code, but
it doesn't
seem to
be implemented. JServ used to use the pool approach (as in: good old
JServ!), so
I thought this must be the case in TC as well. I missed one
minor detail
here:
JServ and Tomcat have nothing to do with one another...
I have found this code snippet in ServletHandler.java of TC 3.3:
if (servlet instanceof SingleThreadModel) {
synchronized(servlet) {
servlet.service(reqF, resF);
}
} else {
servlet.service(reqF, resF);
}
which suggest that during the execution of service(), servlet is
synchronised
for SingleThreadModel. This is a piece of code from JspServlet.java:
if (servlet instanceof SingleThreadModel) {
// sync on the wrapper so that the freshness
// of the page is determined right before servicing
synchronized (this) {
servlet.service(request, response);
}
} else {
servlet.service(request, response);
}
---
which also suggests syncronisation for SingleThreadModel.
Can someone that understands this whole thing a bit better
comment. I
think we
should be very clear in release notes of TC 3.3 if it
doesn't comply with
parts
of the spec.
From the code, it seems to be compliant...
**
This message is intended only for the use of the person(s)
listed above
as the intended recipient(s), and may contain information that is
PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient,
you may not read, copy, or distribute this message or any
attachment.
If you received this communication in error, please notify us
immediately
by e-mail and then delete all copies of this message and any
attachments.
In addition you should be aware that ordinary (unencrypted)
e-mail sent
through the Internet is not secure. Do not send confidential
or sensitive
information, such as social security numbers, account
numbers, personal
identification numbers and passwords, to us via ordinary
(unencrypted)
e-mail.
RE: cvs commit: jakarta-tomcat-connectors/jk/native/apache-1.3 mod_jk.c
Hi,
Shouldn't content-length be Content-Length? Or are the headers already
forced to lowercase elsewhere? Or how about a case insensitive comparison
to be nice
-David
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Friday, September 14, 2001 3:32 PM
To: [EMAIL PROTECTED]
Subject: cvs commit: jakarta-tomcat-connectors/jk/native/apache-1.3
mod_jk.c
hgomez 01/09/14 15:31:36
Modified:jk/native/apache-1.3 mod_jk.c
Log:
Complete the support of chunk encoding and
add the required content-length which is
now required by recent ajp13 present in JT
and which will soon be ported to JTC for
at least TC 4.0 use (candidate here ?)
Revision ChangesPath
1.16 +57 -36
jakarta-tomcat-connectors/jk/native/apache-1.3/mod_jk.c
Index: mod_jk.c
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/jk/native/apache-1.3/mod_jk.c,v
retrieving revision 1.15
retrieving revision 1.16
diff -u -r1.15 -r1.16
--- mod_jk.c 2001/09/14 17:45:14 1.15
+++ mod_jk.c 2001/09/14 22:31:36 1.16
@@ -61,7 +61,7 @@
* Author: Gal Shachor [EMAIL PROTECTED]
*
* Dan Milstein [EMAIL PROTECTED]
*
* Henri Gomez [EMAIL PROTECTED]
*
- * Version: $Revision: 1.15 $
*
+ * Version: $Revision: 1.16 $
*
***/
/*
@@ -118,15 +118,22 @@
* Configuration object for the mod_jk module.
*/
typedef struct {
-char *log_file;
-int log_level;
+
+/*
+ * Log stuff
+ */
+char*log_file;
+int log_level;
jk_logger_t *log;
-char *worker_file;
-int mountcopy;
+/*
+ * Worker stuff
+ */
+char *worker_file;
jk_map_t *uri_to_context;
- char * secret_key;
+int mountcopy;
+ char *secret_key;
jk_map_t *automount;
jk_uri_worker_map_t *uw_map;
@@ -440,35 +447,16 @@
s-remote_host = NULL_FOR_EMPTY(s-remote_host);
s-remote_addr = NULL_FOR_EMPTY(r-connection-remote_ip);
-/* Wrong:s-server_name = (char *)ap_get_server_name( r ); */
-s-server_name= (char *)(r-hostname ? r-hostname :
r-server-server_hostname);
-
-s-server_port= htons( r-connection-local_addr.sin_port );
-/* Wrong: s-server_port = r-server-port; */
-
+s-server_name = (char *)(r-hostname ? r-hostname :
r-server-server_hostname);
-/*Winners: htons( r-connection-local_addr.sin_port )
- (r-hostname ? r-hostname :
- r-server-server_hostname),
-*/
-/* printf( Port %u %u %u %s %s %s %d %d \n,
-ap_get_server_port( r ),
-htons( r-connection-local_addr.sin_port ),
-ntohs( r-connection-local_addr.sin_port ),
-ap_get_server_name( r ),
-(r-hostname ? r-hostname : r-server-server_hostname),
-r-hostname,
-r-connection-base_server-port,
-r-server-port
-);
-*/
+s-server_port = htons( r-connection-local_addr.sin_port );
s-server_software = (char *)ap_get_server_version();
-s-method = (char *)r-method;
+s-method = (char *)r-method;
s-content_length = get_content_length(r);
-s-is_chunked = r-read_chunked;
+s-is_chunked = r-read_chunked;
s-no_more_chunks = 0;
-s-query_string = r-args;
+s-query_string = r-args;
if (conf-options JK_OPT_FWDUNPARSED) {
/*
@@ -515,10 +503,12 @@
s-ssl_cipher = (char *)ap_table_get(r-subprocess_env,
conf-cipher_indicator);
s-ssl_session = (char *)ap_table_get(r-subprocess_env,
conf-session_indicator);
- /* Servlet 2.3 API */
-ssl_temp = (char *)ap_table_get(r-subprocess_env,
conf-key_size_indicator);
- if (ssl_temp)
- s-ssl_key_size = atoi(ssl_temp);
+if (conf-options JK_OPT_FWDKEYSIZE) {
+ /* Servlet 2.3 API */
+ssl_temp = (char *)ap_table_get(r-subprocess_env,
conf-key_size_indicator);
+ if (ssl_temp)
+ s-ssl_key_size = atoi(ssl_temp);
+}
}
}
@@ -547,13 +537,17 @@
s-headers_values = NULL;
s-num_headers = 0;
if(r-headers_in ap_table_elts(r-headers_in)) {
+int need_content_length_header = (!s-is_chunked
s-content_length == 0) ? JK_TRUE : JK_FALSE;
array_header *t = ap_table_elts(r-headers_in);
if(t t-nelts) {
int i;
table_entry *elts = (table_entry *)t-elts;
RE: cvs commit: jakarta-tomcat-connectors/jk/native/apache-1.3 mo d_jk.c
OK, Sorry. It's right there in front of me! Been a long week ...
-David
-Original Message-
From: Schreibman, David [mailto:[EMAIL PROTECTED]]
Sent: Friday, September 14, 2001 4:07 PM
To: '[EMAIL PROTECTED]';
[EMAIL PROTECTED]
Subject: RE: cvs commit: jakarta-tomcat-connectors/jk/native/apache-1.3
mo d_jk.c
Hi,
Shouldn't content-length be Content-Length? Or are the headers already
forced to lowercase elsewhere? Or how about a case insensitive comparison
to be nice
-David
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Friday, September 14, 2001 3:32 PM
To: [EMAIL PROTECTED]
Subject: cvs commit: jakarta-tomcat-connectors/jk/native/apache-1.3
mod_jk.c
hgomez 01/09/14 15:31:36
Modified:jk/native/apache-1.3 mod_jk.c
Log:
Complete the support of chunk encoding and
add the required content-length which is
now required by recent ajp13 present in JT
and which will soon be ported to JTC for
at least TC 4.0 use (candidate here ?)
Revision ChangesPath
1.16 +57 -36
jakarta-tomcat-connectors/jk/native/apache-1.3/mod_jk.c
Index: mod_jk.c
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/jk/native/apache-1.3/mod_jk.c,v
retrieving revision 1.15
retrieving revision 1.16
diff -u -r1.15 -r1.16
--- mod_jk.c 2001/09/14 17:45:14 1.15
+++ mod_jk.c 2001/09/14 22:31:36 1.16
@@ -61,7 +61,7 @@
* Author: Gal Shachor [EMAIL PROTECTED]
*
* Dan Milstein [EMAIL PROTECTED]
*
* Henri Gomez [EMAIL PROTECTED]
*
- * Version: $Revision: 1.15 $
*
+ * Version: $Revision: 1.16 $
*
***/
/*
@@ -118,15 +118,22 @@
* Configuration object for the mod_jk module.
*/
typedef struct {
-char *log_file;
-int log_level;
+
+/*
+ * Log stuff
+ */
+char*log_file;
+int log_level;
jk_logger_t *log;
-char *worker_file;
-int mountcopy;
+/*
+ * Worker stuff
+ */
+char *worker_file;
jk_map_t *uri_to_context;
- char * secret_key;
+int mountcopy;
+ char *secret_key;
jk_map_t *automount;
jk_uri_worker_map_t *uw_map;
@@ -440,35 +447,16 @@
s-remote_host = NULL_FOR_EMPTY(s-remote_host);
s-remote_addr = NULL_FOR_EMPTY(r-connection-remote_ip);
-/* Wrong:s-server_name = (char *)ap_get_server_name( r ); */
-s-server_name= (char *)(r-hostname ? r-hostname :
r-server-server_hostname);
-
-s-server_port= htons( r-connection-local_addr.sin_port );
-/* Wrong: s-server_port = r-server-port; */
-
+s-server_name = (char *)(r-hostname ? r-hostname :
r-server-server_hostname);
-/*Winners: htons( r-connection-local_addr.sin_port )
- (r-hostname ? r-hostname :
- r-server-server_hostname),
-*/
-/* printf( Port %u %u %u %s %s %s %d %d \n,
-ap_get_server_port( r ),
-htons( r-connection-local_addr.sin_port ),
-ntohs( r-connection-local_addr.sin_port ),
-ap_get_server_name( r ),
-(r-hostname ? r-hostname : r-server-server_hostname),
-r-hostname,
-r-connection-base_server-port,
-r-server-port
-);
-*/
+s-server_port = htons( r-connection-local_addr.sin_port );
s-server_software = (char *)ap_get_server_version();
-s-method = (char *)r-method;
+s-method = (char *)r-method;
s-content_length = get_content_length(r);
-s-is_chunked = r-read_chunked;
+s-is_chunked = r-read_chunked;
s-no_more_chunks = 0;
-s-query_string = r-args;
+s-query_string = r-args;
if (conf-options JK_OPT_FWDUNPARSED) {
/*
@@ -515,10 +503,12 @@
s-ssl_cipher = (char *)ap_table_get(r-subprocess_env,
conf-cipher_indicator);
s-ssl_session = (char *)ap_table_get(r-subprocess_env,
conf-session_indicator);
- /* Servlet 2.3 API */
-ssl_temp = (char *)ap_table_get(r-subprocess_env,
conf-key_size_indicator);
- if (ssl_temp)
- s-ssl_key_size = atoi(ssl_temp);
+if (conf-options JK_OPT_FWDKEYSIZE) {
+ /* Servlet 2.3 API */
+ssl_temp = (char *)ap_table_get(r-subprocess_env,
conf-key_size_indicator);
+ if (ssl_temp)
+ s-ssl_key_size = atoi(ssl_temp);
+}
}
}
@@ -547,13 +537,17 @@
s-headers_values = NULL;
s-num_headers = 0;
if(r
Chunked input in 3.3-b2
I downloaded the 3.3-b2 sources to investigate the issue below further.
However, I am unable to get chunked input to work at all. It's almost as if
the Java side is declaring eof before reading all the data available on the
apache side. I have confirmed that mod_jk thinks the request is chunked.
I'm going to keep digging to get at the root of the problem, but thought I
would send in a report in case anyone has any ideas (btw, I'm running Apache
1.3.20).
From looking over the code, I'm now pretty sure the issue discussed below is
also going to be a problem. I won't know for sure until I get past the
current problem and get to do my stress tests.
-David
-Original Message-
From: Schreibman, David
Sent: Tuesday, September 04, 2001 11:27 AM
To: '[EMAIL PROTECTED]'
Subject: RE: cvs commit:
jakarta-tomcat/src/share/org/apache/tomcat/modules/server Ajp13.java
Oops. Sorry for the typo.
About
... chunk-size [ chunk-ext ] CRLF, as defined in rfc 2069. That's ...
I meant rfc 2068!
-David
-Original Message-
From: Schreibman, David
Sent: Tuesday, September 04, 2001 11:03 AM
To: '[EMAIL PROTECTED]'; [EMAIL PROTECTED]
Subject: RE: cvs commit:
jakarta-tomcat/src/share/org/apache/tomcat/modules/server Ajp13.java
It's great to see this work on chunked input progressing!
It's hard for me to see if it's covered here, so I wanted to double check
whether this code addresses a subtle bug that I ran into while getting
chunked input working on 3.2.2
For me, the problem came up when read_fully_from_server() would call read()
with a very small value of len.
The bug would not manifest itself all the time so I didn't notice it for a
while. The problem occurs only when you happen to call
ap_get_client_block() with a very small value of len and
ap_get_client_block() needs to start a new chunk. By small value, I mean
anything less than the length of chunk-size [ chunk-ext ] CRLF, as defined
in rfc 2069. That's because ap_get_client_block() actually uses the buffer
that is passed in, to read the chunk-size data.
The comments for ap_get_client_block in http_protocol.c indicate the
requirement for the caller to provide enough buffer space to deal with this.
You can luck out a lot of the time, but if you hit this case
ap_get_client_block() will fail. I only spotted this while doing a stress
test that was repeatedly posting 100MB.
It know it was heavy handed but this is what lead me to set up a separate
read buffer for each endpoint. That way I would be sure to always call
ap_get_client_block() with a generously sized buffer. I don't blame you for
avoiding this approach.
Again, my apologies is this is obviously covered. Just wanted to make sure
this was addressed in the latest changes (and bring it up while my memory on
the topic is still fresh).
Thanks,
-David
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Friday, August 31, 2001 6:53 PM
To: [EMAIL PROTECTED]
Subject: cvs commit:
jakarta-tomcat/src/share/org/apache/tomcat/modules/server Ajp13.java
keith 01/08/31 18:53:25
Modified:src/native/mod_jk/apache1.3 mod_jk.c
src/native/mod_jk/common jk_ajp13_worker.c jk_service.h
jk_util.c
src/share/org/apache/tomcat/modules/server Ajp13.java
Log:
Upgrade mod_jk to support chunked input from Apache 1.3.
TODO: port to Apache 2.0 module. (And forward port to j-t-c)
Revision ChangesPath
1.10 +22 -11jakarta-tomcat/src/native/mod_jk/apache1.3/mod_jk.c
Index: mod_jk.c
===
RCS file: /home/cvs/jakarta-tomcat/src/native/mod_jk/apache1.3/mod_jk.c,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- mod_jk.c 2001/06/01 08:41:13 1.9
+++ mod_jk.c 2001/09/01 01:53:25 1.10
@@ -267,16 +267,19 @@
if(s s-ws_private b actually_read) {
apache_private_data_t *p = s-ws_private;
if(!p-read_body_started) {
-if(!ap_setup_client_block(p-r, REQUEST_CHUNKED_DECHUNK)) {
-if(ap_should_client_block(p-r)) {
-p-read_body_started = JK_TRUE;
-}
+if(ap_should_client_block(p-r)) {
+p-read_body_started = JK_TRUE;
}
}
-if(p-read_body_started) {
-*actually_read = ap_get_client_block(p-r, b, len);
-return JK_TRUE;
+if(p-read_body_started) {
+ long rv;
+ if ((rv = ap_get_client_block(p-r, b, len)) 0) {
+ *actually_read = 0;
+ } else {
+ *actually_read = (unsigned) rv;
+ }
+return JK_TRUE;
}
}
return JK_FALSE;
@@ -454,7 +457,9 @@
s-server_software = (char *)ap_get_server_version();
s-method = (char *)r-method;
-s-content_length
RE: cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/modules/server Ajp13.java
It's great to see this work on chunked input progressing!
It's hard for me to see if it's covered here, so I wanted to double check
whether this code addresses a subtle bug that I ran into while getting
chunked input working on 3.2.2
For me, the problem came up when read_fully_from_server() would call read()
with a very small value of len.
The bug would not manifest itself all the time so I didn't notice it for a
while. The problem occurs only when you happen to call
ap_get_client_block() with a very small value of len and
ap_get_client_block() needs to start a new chunk. By small value, I mean
anything less than the length of chunk-size [ chunk-ext ] CRLF, as defined
in rfc 2069. That's because ap_get_client_block() actually uses the buffer
that is passed in, to read the chunk-size data.
The comments for ap_get_client_block in http_protocol.c indicate the
requirement for the caller to provide enough buffer space to deal with this.
You can luck out a lot of the time, but if you hit this case
ap_get_client_block() will fail. I only spotted this while doing a stress
test that was repeatedly posting 100MB.
It know it was heavy handed but this is what lead me to set up a separate
read buffer for each endpoint. That way I would be sure to always call
ap_get_client_block() with a generously sized buffer. I don't blame you for
avoiding this approach.
Again, my apologies is this is obviously covered. Just wanted to make sure
this was addressed in the latest changes (and bring it up while my memory on
the topic is still fresh).
Thanks,
-David
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Friday, August 31, 2001 6:53 PM
To: [EMAIL PROTECTED]
Subject: cvs commit:
jakarta-tomcat/src/share/org/apache/tomcat/modules/server Ajp13.java
keith 01/08/31 18:53:25
Modified:src/native/mod_jk/apache1.3 mod_jk.c
src/native/mod_jk/common jk_ajp13_worker.c jk_service.h
jk_util.c
src/share/org/apache/tomcat/modules/server Ajp13.java
Log:
Upgrade mod_jk to support chunked input from Apache 1.3.
TODO: port to Apache 2.0 module. (And forward port to j-t-c)
Revision ChangesPath
1.10 +22 -11jakarta-tomcat/src/native/mod_jk/apache1.3/mod_jk.c
Index: mod_jk.c
===
RCS file: /home/cvs/jakarta-tomcat/src/native/mod_jk/apache1.3/mod_jk.c,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- mod_jk.c 2001/06/01 08:41:13 1.9
+++ mod_jk.c 2001/09/01 01:53:25 1.10
@@ -267,16 +267,19 @@
if(s s-ws_private b actually_read) {
apache_private_data_t *p = s-ws_private;
if(!p-read_body_started) {
-if(!ap_setup_client_block(p-r, REQUEST_CHUNKED_DECHUNK)) {
-if(ap_should_client_block(p-r)) {
-p-read_body_started = JK_TRUE;
-}
+if(ap_should_client_block(p-r)) {
+p-read_body_started = JK_TRUE;
}
}
-if(p-read_body_started) {
-*actually_read = ap_get_client_block(p-r, b, len);
-return JK_TRUE;
+if(p-read_body_started) {
+ long rv;
+ if ((rv = ap_get_client_block(p-r, b, len)) 0) {
+ *actually_read = 0;
+ } else {
+ *actually_read = (unsigned) rv;
+ }
+return JK_TRUE;
}
}
return JK_FALSE;
@@ -454,7 +457,9 @@
s-server_software = (char *)ap_get_server_version();
s-method = (char *)r-method;
-s-content_length = get_content_length(r);
+s-content_length = get_content_length(r);
+s-is_chunked = r-read_chunked;
+s-no_more_chunks = 0;
s-query_string = r-args;
s-req_uri = r-uri;
@@ -784,10 +789,16 @@
{
/* Retrieve the worker name stored by jk_translate() */
const char *worker_name = ap_table_get(r-notes, JK_WORKER_ID);
+int rc;
if(r-proxyreq) {
return HTTP_INTERNAL_SERVER_ERROR;
-}
+}
+
+/* Set up r-read_chunked flags for chunked encoding, if present */
+if(rc = ap_setup_client_block(r, REQUEST_CHUNKED_DECHUNK)) {
+ return rc;
+}
if(worker_name) {
jk_server_conf_t *conf =
@@ -820,12 +831,12 @@
l,
is_recoverable_error);
-if (s.content_read s.content_length) {
+if (s.content_read s.content_length ||
s.is_chunked) {
/*
* If the servlet engine didn't consume all of
the
* request data, consume and discard all further
* characters left to read
RE: cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/modules/server Ajp13.java
Oops. Sorry for the typo.
About
... chunk-size [ chunk-ext ] CRLF, as defined in rfc 2069. That's ...
I meant rfc 2068!
-David
-Original Message-
From: Schreibman, David
Sent: Tuesday, September 04, 2001 11:03 AM
To: '[EMAIL PROTECTED]'; [EMAIL PROTECTED]
Subject: RE: cvs commit:
jakarta-tomcat/src/share/org/apache/tomcat/modules/server Ajp13.java
It's great to see this work on chunked input progressing!
It's hard for me to see if it's covered here, so I wanted to double check
whether this code addresses a subtle bug that I ran into while getting
chunked input working on 3.2.2
For me, the problem came up when read_fully_from_server() would call read()
with a very small value of len.
The bug would not manifest itself all the time so I didn't notice it for a
while. The problem occurs only when you happen to call
ap_get_client_block() with a very small value of len and
ap_get_client_block() needs to start a new chunk. By small value, I mean
anything less than the length of chunk-size [ chunk-ext ] CRLF, as defined
in rfc 2069. That's because ap_get_client_block() actually uses the buffer
that is passed in, to read the chunk-size data.
The comments for ap_get_client_block in http_protocol.c indicate the
requirement for the caller to provide enough buffer space to deal with this.
You can luck out a lot of the time, but if you hit this case
ap_get_client_block() will fail. I only spotted this while doing a stress
test that was repeatedly posting 100MB.
It know it was heavy handed but this is what lead me to set up a separate
read buffer for each endpoint. That way I would be sure to always call
ap_get_client_block() with a generously sized buffer. I don't blame you for
avoiding this approach.
Again, my apologies is this is obviously covered. Just wanted to make sure
this was addressed in the latest changes (and bring it up while my memory on
the topic is still fresh).
Thanks,
-David
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Friday, August 31, 2001 6:53 PM
To: [EMAIL PROTECTED]
Subject: cvs commit:
jakarta-tomcat/src/share/org/apache/tomcat/modules/server Ajp13.java
keith 01/08/31 18:53:25
Modified:src/native/mod_jk/apache1.3 mod_jk.c
src/native/mod_jk/common jk_ajp13_worker.c jk_service.h
jk_util.c
src/share/org/apache/tomcat/modules/server Ajp13.java
Log:
Upgrade mod_jk to support chunked input from Apache 1.3.
TODO: port to Apache 2.0 module. (And forward port to j-t-c)
Revision ChangesPath
1.10 +22 -11jakarta-tomcat/src/native/mod_jk/apache1.3/mod_jk.c
Index: mod_jk.c
===
RCS file: /home/cvs/jakarta-tomcat/src/native/mod_jk/apache1.3/mod_jk.c,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- mod_jk.c 2001/06/01 08:41:13 1.9
+++ mod_jk.c 2001/09/01 01:53:25 1.10
@@ -267,16 +267,19 @@
if(s s-ws_private b actually_read) {
apache_private_data_t *p = s-ws_private;
if(!p-read_body_started) {
-if(!ap_setup_client_block(p-r, REQUEST_CHUNKED_DECHUNK)) {
-if(ap_should_client_block(p-r)) {
-p-read_body_started = JK_TRUE;
-}
+if(ap_should_client_block(p-r)) {
+p-read_body_started = JK_TRUE;
}
}
-if(p-read_body_started) {
-*actually_read = ap_get_client_block(p-r, b, len);
-return JK_TRUE;
+if(p-read_body_started) {
+ long rv;
+ if ((rv = ap_get_client_block(p-r, b, len)) 0) {
+ *actually_read = 0;
+ } else {
+ *actually_read = (unsigned) rv;
+ }
+return JK_TRUE;
}
}
return JK_FALSE;
@@ -454,7 +457,9 @@
s-server_software = (char *)ap_get_server_version();
s-method = (char *)r-method;
-s-content_length = get_content_length(r);
+s-content_length = get_content_length(r);
+s-is_chunked = r-read_chunked;
+s-no_more_chunks = 0;
s-query_string = r-args;
s-req_uri = r-uri;
@@ -784,10 +789,16 @@
{
/* Retrieve the worker name stored by jk_translate() */
const char *worker_name = ap_table_get(r-notes, JK_WORKER_ID);
+int rc;
if(r-proxyreq) {
return HTTP_INTERNAL_SERVER_ERROR;
-}
+}
+
+/* Set up r-read_chunked flags for chunked encoding, if present */
+if(rc = ap_setup_client_block(r, REQUEST_CHUNKED_DECHUNK)) {
+ return rc;
+}
if(worker_name) {
jk_server_conf_t *conf =
@@ -820,12 +831,12 @@
l,
is_recoverable_error
RE: PATCH: jk_nt_service can't automatically be restarted by Windows Service Control Manager upon crash
If you really want the service code to be aggressive about restarting Tomcat, I would suggest just calling start_tomcat() again. This would avoid any dependency on the Service Control Manager's reaction to ungraceful exits. In fact, I've never seen any documentation from Microsoft about such restarts. The only automatic service startups that I know about are upon booting. Can you send a reference to MS documentation about this? In addition, I don't think you would want this to just keep restarting indefinitely. If the vm is crashing a lot then there's something going on that needs to be looked at. Such restart functionality should be limited to a certain number of retries. Continuing to run the vm might interfere with other software running on the same machine. Especially if the vm is crashing due to some unusual resource consumption. Just my 2 bits worth. -David -Original Message- From: Dave Ringoen [mailto:[EMAIL PROTECTED]] Sent: Thursday, August 30, 2001 2:55 PM To: '[EMAIL PROTECTED]' Cc: Chien-Ming Huang; Brian Enright; Rob Webb; Patti Vrobel; Steven Velez Subject: PATCH: jk_nt_service can't automatically be restarted by Windows Service Control Manager upon crash We're using Tomcat at our company with considerable success, but discovered that if java.exe crashes for some reason, the Tomcat service won't restart automatically. I diagnosed the problem and came up with this discovery and a proposed fix. jk_nt_service.exe exits too gracefully if the java.exe process dies, notifying the Service Control Manager that it is shutting down. When Service Control Manager receives the shutdown message, it does not restart the service. It assumes that the service was supposed to be shut down. This patch makes jk_nt_service exit more abruptly without notifying SCM. With this patch, SCM will correctly initiate a restart of the Tomcat service. I couldn't file this in Bugzilla because Bugzilla was down. Thanks for your consideration on this patch. I'm very impressed with the Tomcat development approach and process. Dave Ringoen Alventive, Inc. cvs diff -u jk_nt_service.c (in directory C:\Temp\tomcatsrcnightly\jakarta-tomcat\src\native\mod_jk\nt_service) Index: jk_nt_service.c === RCS file: /home/cvspublic/jakarta-tomcat/src/native/mod_jk/nt_service/jk_nt_service.c, v retrieving revision 1.3 diff -u -r1.3 jk_nt_service.c --- jk_nt_service.c 2001/04/24 08:49:46 1.3 +++ jk_nt_service.c 2001/08/30 18:05:02 @@ -535,6 +535,11 @@ /* * Tomcat died !!! */ +CloseHandle(hServerStopEvent); +CloseHandle(hTomcat); +exit(0); // exit ungracefully so + // Service Control Manager + // will attempt a restart. break; default: /*
RE: PATCH: jk_nt_service can't automatically be restarted by Windows Service Control Manager upon crash
I guess that was what I was trying to get at. The failure restart functionality was not available before Windows 2000. Otherwise I totally agree with taking full advantage of the OS. Thanks, -David -Original Message- From: Marc Saegesser [mailto:[EMAIL PROTECTED]] Sent: Thursday, August 30, 2001 7:30 PM To: [EMAIL PROTECTED] Subject: RE: PATCH: jk_nt_service can't automatically be restarted by Windows Service Control Manager upon crash As of Win2000 (not sure if this existed in WinNT) you can configure a service to attempt to recover if it dies. This is fairly flexible in that you can cause it to attempt up to three restarts (after a delay period), execute a file on failure, reboot the system, etc. We might as well use the facilities the OS provides instead of duplicating this inside the service. Marc Saegesser -Original Message- From: Schreibman, David [mailto:[EMAIL PROTECTED]] Sent: Thursday, August 30, 2001 6:06 PM To: '[EMAIL PROTECTED]' Subject: RE: PATCH: jk_nt_service can't automatically be restarted by Windows Service Control Manager upon crash If you really want the service code to be aggressive about restarting Tomcat, I would suggest just calling start_tomcat() again. This would avoid any dependency on the Service Control Manager's reaction to ungraceful exits. In fact, I've never seen any documentation from Microsoft about such restarts. The only automatic service startups that I know about are upon booting. Can you send a reference to MS documentation about this? In addition, I don't think you would want this to just keep restarting indefinitely. If the vm is crashing a lot then there's something going on that needs to be looked at. Such restart functionality should be limited to a certain number of retries. Continuing to run the vm might interfere with other software running on the same machine. Especially if the vm is crashing due to some unusual resource consumption. Just my 2 bits worth. -David -Original Message- From: Dave Ringoen [mailto:[EMAIL PROTECTED]] Sent: Thursday, August 30, 2001 2:55 PM To: '[EMAIL PROTECTED]' Cc: Chien-Ming Huang; Brian Enright; Rob Webb; Patti Vrobel; Steven Velez Subject: PATCH: jk_nt_service can't automatically be restarted by Windows Service Control Manager upon crash We're using Tomcat at our company with considerable success, but discovered that if java.exe crashes for some reason, the Tomcat service won't restart automatically. I diagnosed the problem and came up with this discovery and a proposed fix. jk_nt_service.exe exits too gracefully if the java.exe process dies, notifying the Service Control Manager that it is shutting down. When Service Control Manager receives the shutdown message, it does not restart the service. It assumes that the service was supposed to be shut down. This patch makes jk_nt_service exit more abruptly without notifying SCM. With this patch, SCM will correctly initiate a restart of the Tomcat service. I couldn't file this in Bugzilla because Bugzilla was down. Thanks for your consideration on this patch. I'm very impressed with the Tomcat development approach and process. Dave Ringoen Alventive, Inc. cvs diff -u jk_nt_service.c (in directory C:\Temp\tomcatsrcnightly\jakarta-tomcat\src\native\mod_jk\nt_service) Index: jk_nt_service.c === RCS file: /home/cvspublic/jakarta-tomcat/src/native/mod_jk/nt_service/jk_nt_ service.c, v retrieving revision 1.3 diff -u -r1.3 jk_nt_service.c --- jk_nt_service.c 2001/04/24 08:49:46 1.3 +++ jk_nt_service.c 2001/08/30 18:05:02 @@ -535,6 +535,11 @@ /* * Tomcat died !!! */ +CloseHandle(hServerStopEvent); +CloseHandle(hTomcat); +exit(0); // exit ungracefully so + // Service Control Manager + // will attempt a restart. break; default: /*
RE: cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/util/t estHeader.java HttpRequest.java
Great! I will limp along with what I've got now in 3.2.2. Looking forward to getting your changes. What version(s) of Tomcat this will get into? Thanks 100, -David -Original Message- From: Keith Wannamaker [mailto:[EMAIL PROTECTED]] Sent: Tuesday, August 28, 2001 6:21 PM To: [EMAIL PROTECTED] Subject: RE: cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/util/t estHeader.java HttpRequest.java | | - Does the java part need to know that the incoming data came in | CHUNKED ? | | The Java side can figure it out if the Content-Length is not set. Still, | | the Content-Length might be set even when the transfer was chunked. Not | | sure how much value would be added in knowing this explicitly. | | I don't *think* the Java side needs to be changed at all, Yeah, I've got chunked input working ok with just some changes to the c side of jk. I'll clean it up and post tomorrow for dissection. Keith
RE: cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/util/testHeader.java HttpRequest.java
For whatever it's worth, here are some changes I made to the 3.2.2 code base
to add support for chunked requests. I just did the work a few days ago and
am still in the process of moving them to 3.3. Still, since the topic came
up now I thought it would be helpful to share my approach. I have been
running some heavy stress tests on this and have not seen any problems yet.
It would be great to run the changes through some unit tests as well.
The changes are in Ajp13ConnectorRequest.java, jk_ajp13_worker.c, and a
minor change to mod_jk.c.
The key change in Ajp13ConnectorRequest.java is not to set a limit on the
BufferedServletInputStream when there is no Content-Length.
On key change in jk_ajp13_worker.c was to add a read buffer to the
ajp13_endpoint struct.
This was needed to ensure that calls to ap_get_client_block() (via the
service's read() function) will always ask for a fixed amount. Without
this, you can end up calling read_client_block() with a buffer that is too
small and it will return an error. This is due to ap_get_client_block()
requiring a buffer size large enough to hold a chunk-size line.
In mod_jk.c, I made a simple change to avoid possible cross platform issues
due to assigning a long to an unsigned.
I welcome any questions or comments about this approach. Hopefully, I have
presented the changes in a way that makes sense. If not, I'll be happy to
take suggestions about how to make the changes easier to understand.
-David
Here are the changes:
In Ajp13ConnectorRequest.java $Revision: 1.5.2.7
234c234,235
((BufferedServletInputStream)this.in).setLimit(contentLength);
---
236,244c237,246
/* Read present data */
int err = con.receive(msg);
if(err 0) {
return -1;
}
blen = msg.peekInt();
msg.getBytes(bodyBuff);
}
---
((BufferedServletInputStream)this.in).setLimit(contentLength);
}
/* Read present data */
int err = con.receive(msg);
if(err 0) {
return -1;
}
blen = msg.peekInt();
msg.getBytes(bodyBuff);
306,311c308,313
MsgBuffer msg = con.getMsgBuffer();
msg.appendByte(JK_AJP13_GET_BODY_CHUNK);
msg.appendInt(MAX_READ_SIZE);
con.send(msg);
int err = con.receive(msg);
---
MsgBuffer msg = con.getMsgBuffer();
msg.appendByte(JK_AJP13_GET_BODY_CHUNK);
msg.appendInt(MAX_READ_SIZE);
con.send(msg);
int err = con.receive(msg);
313,314c315,316
throw new IOException();
}
---
throw new IOException();
}
317,319c319,325
pos = 0;
msg.getBytes(bodyBuff);
---
if (blen 0) {
pos = 0;
msg.getBytes(bodyBuff);
} else {
pos = 0;
msg.getBytes(bodyBuff);
}
In jk_ajp13_worker.c $Revision: 1.3.2.2
111c111,117
unsigned left_bytes_to_send;
---
int left_bytes_to_send;
int had_content_length;
unsigned char readbuf[READ_BUF_SIZE];
unsigned left;
unsigned int current;
116c122,124
ep-reuse = JK_FALSE;
---
ep-reuse = JK_FALSE;
ep-left = 0;
ep-current = 0;
236c244,246
static int read_fully_from_server(jk_ws_service_t *s,
---
static int read_fully_from_server(ajp13_endpoint_t *ep,
jk_ws_service_t *s,
238c248,249
unsigned len)
---
unsigned len,
jk_logger_t *l)
240a252
unsigned this_time;
243,245c255,261
unsigned this_time = 0;
if(!s-read(s, buf + rdlen, len - rdlen, this_time)) {
return -1;
---
if (ep-left = 0) {
if(!s-read(s, ep-readbuf, (unsigned)READ_BUF_SIZE,
(ep-left))) {
jk_log(l, JK_LOG_DEBUG, read_fully says -1\n);
return -1;
}
ep-current = 0;
247a264,268
this_time = (ep-left (len - rdlen)) ? ep-left : (len-rdlen);
memcpy(buf+rdlen, (ep-readbuf)+ep-current, this_time);
ep-left -= this_time;
ep-current += this_time;
249c270
break;
---
break;
251c272,274
rdlen += this_time;
---
rdlen += this_time;
264c287
---
int just_got = 0;
270c293,297
if(read_fully_from_server(r, read_buf, len) 0) {
---
if((just_got = read_fully_from_server(ep, r, read_buf, len, l)) 0) {
if (ep-had_content_length == 0) {
ep-left_bytes_to_send = -1;
return JK_TRUE;
} else {
273c300,301
return JK_FALSE;
---
return JK_FALSE;
}
276c304,307
ep-left_bytes_to_send -= len;
---
if ((ep-had_content_length == 0) (just_got != len)) {
RE: cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/util/testHeader.java HttpRequest.java
MAX_SEND_BODY_SZ) {
@@ -622,7 +667,6 @@
Error reading request\n);
return JK_FALSE;
}
-
rc = ajp13_process_callback(msg, p, s, l);
if(JK_AJP13_END_RESPONSE == rc) {
return JK_TRUE;
@@ -681,6 +725,8 @@
if(ep) {
ep-sd = -1;
ep-reuse = JK_FALSE;
+ ep-left = 0;
+ ep-current = 0;
jk_open_pool(ep-pool, ep-buf, sizeof(ep-buf));
ep-worker = pThis-worker_private;
ep-endpoint.endpoint_private = ep;
--- mod_jk.orig Tue Aug 28 07:09:33 2001
+++ mod_jk.cTue Aug 28 07:10:29 2001
@@ -221,6 +221,7 @@
unsigned l,
unsigned *a)
{
+
if(s s-ws_private b a) {
apache_private_data_t *p = s-ws_private;
if(!p-read_body_started) {
@@ -232,10 +233,11 @@
}
if(p-read_body_started) {
-*a = ap_get_client_block(p-r, b, l);
+*a = (unsigned) ap_get_client_block(p-r, b, l);
return JK_TRUE;
}
}
+
return JK_FALSE;
}
-Original Message-
From: Keith Wannamaker [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, August 28, 2001 8:29 AM
To: [EMAIL PROTECTED]
Subject: RE: cvs commit:
jakarta-tomcat/src/share/org/apache/tomcat/util/testHeader.java
HttpRequest.java
Heh, you beat me to it. I'd like to compare notes.
Can you resend the diff with -u -b?
Keith
| -Original Message-
| From: Schreibman, David [mailto:[EMAIL PROTECTED]]
| Sent: Tuesday, August 28, 2001 11:17 AM
| To: '[EMAIL PROTECTED]'
| Subject: RE: cvs commit:
| jakarta-tomcat/src/share/org/apache/tomcat/util/testHeader.java
| HttpRequest.java
|
|
| For whatever it's worth, here are some changes I made to the 3.2.2 code
base
| to add support for chunked requests. I just did the work a few days ago
and
| am still in the process of moving them to 3.3. Still, since the topic
came
RE: cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/util/t estHeader.java HttpRequest.java
Since I'm going to need support for chunked requests in 3.3 anyway, I'm going ahead with the port of my 3.2.2 changes. I hope to have it in a couple of days. Questions : - Does the java part need to know that the incoming data came in CHUNKED ? The Java side can figure it out if the Content-Length is not set. Still, the Content-Length might be set even when the transfer was chunked. Not sure how much value would be added in knowing this explicitly. - Should we add others HTTP/1.1 commands like Range, Accept-Ranges, CONNECT ? I suppose these could be helpful but I haven't thought too much about it. In general, it seems like a good idea to leverage as much as possible from the transport. -David -Original Message- From: Schreibman, David [mailto:[EMAIL PROTECTED]] Sent: Tuesday, August 28, 2001 5:17 PM To: '[EMAIL PROTECTED]' Subject: RE: cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/util/t estHeader.java HttpRequest.java For whatever it's worth, here are some changes I made to the 3.2.2 code base to add support for chunked requests. I just did the work a few days ago and am still in the process of moving them to 3.3. Still, since the topic came up now I thought it would be helpful to share my approach. I have been running some heavy stress tests on this and have not seen any problems yet. It would be great to run the changes through some unit tests as well. You may have noticed that mod_jk in TC 3.3 is different from the one in TC 3.2. Also Ajp13 in Tomcat 3.3 (java) is also different since using directly InputStream. And mod_jk in jakarta-tomcat-connectors is also very different since there was some refactoring. From what I saw it seems you're on the right way, and I'm waiting to see your port to TC 3.3. Or if you like, I could try to port it to both 3.3 and J-T-C. I've got many questions here and some refactory should be done on that part of the code later, I don't like very much the way the communication is done. May be something to rewrite completly to Ajp14, adding others new commands (CHUNKED-DATA). The goal will be to have a simpler (and so fastest) way to do the transfert. Questions : - Does the java part need to know that the incoming data came in CHUNKED ? - Should we add others HTTP/1.1 commands like Range, Accept-Ranges, CONNECT ? What do you think about that ?
