Added some missing HTTP response lines which weren't in my 3.2 tree.
At least 423 is needed for Webdav.
--- LocalStrings.properties.old Wed Nov 29 20:47:44 2000
+++ LocalStrings.properties Wed Dec 13 05:57:52 2000
@@ -66,9 +66,15 @@
sc.415=Unsupported Media Type
sc.416=Requested Range Not
Hi, two separate issues.
First, I believe this is a renegate ap_kill_timeout;
the timeout is 'refreshed' almost immediately afterwards.
http://www.apache.org/~keith/patch.txt
Second, I have been debugging the following scenario
with mod_jserv and Tomcat:
Browser sends a large request body.
Hi,
I'd like to extend mod_jk to let servlets be RFC 1867 compliant.
Specifically, when transmitting a (large) body of a request
on the ajp connection:
a) mod_jk should be prepared to receive a response from
the servlet at any time during the send of the body; and
b) mod_jk should consume
Hi, Dan, thanks for your informative response.
|File Upload was badly broken with mod_jk/ajp13 in both 3.2 and 3.x
|-- some basic bugs have been fixed in both of those repositories,
|but have not yet been released. Just so you know.
I am working with source from jakarta-tomcat cvs head, but
Hi,
I'm developing patches to add webdav support to ajpv13 in
jakarta-tomcat, and I'm interesting in expediting this code
to a release. If I got it in next week, could it be a
canidate to go out with 3.2, or would you prefer to wait
until 3.3?
Keith
-Original Message-
From: Marc
This is a patch against cvs head to add support to ajpv13
for webdav methods:
http://www.apache.org/~keith/jk/webdav1.txt
Also, this is a patch against cvs head to update the win32
project files to reflect the new directory structure:
http://www.apache.org/~keith/jk/win32.txt
I'd be happy to
This is a patch against cvs head to autogenerate ajpv13
support for Apache, if the ajpv13 module has been loaded.
Also, update server.xml to show ajpv13 support.
http://www.apache.org/~keith/jk/config.txt
Keith
-
To
This patch enables ajpv13 http status text
http://www.apache.org/~keith/jk/status.txt
Keith
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
In 3.2 I don't think this is possible without changing code.
Try searching for ApacheConfig.
In 3.3, the auto-gen classes are now modules to be specified
in server.xml as ContextInterceptors. Currently only Apache is enabled,
and can be disabled by modifying server.xml.
Keith
-Original
This patch corrects the MS VC include directory in the new
3.3 directory structure:
http://www.apache.org/~keith/jk/dsp.txt
Keith
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
This is a patch to ajpv13 in TC 3.3. Only a single read()
call is used to read a packet. When the packet is large
(i.e. uploading files), depending on the subsystem, it
may take multiple read() calls to read the declared packet
length.
Patch: http://www.apache.org/~keith/jk/read/ajp13.txt
Message-
From: Keith Wannamaker [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, January 31, 2001 4:15 PM
To: [EMAIL PROTECTED]
Subject: RE: Problem with mod_jk and ajp13
Hi Peter, this may be related to a problem that was fixed recently
in CVS. Please try a nightly 3.3 build:
http
With all the changes to mod_jk, I'd like to post these binaries
to the jakarta site:
builds/jakarta-tomcat/native-3.3/linux/i386/mod_jk.so and
... /win32/i386/mod_jk.dll
Any objections? These connectors won't be build nightly, but
they will allow people to use the
Sure, just fetch cvs head before you build to pick up
all the fixes. Send them to me or let me know where
I can get them.
Keith
-Original Message-
From: Mike Anderson [mailto:[EMAIL PROTECTED]]
Sent: Friday, February 02, 2001 2:02 PM
To: [EMAIL PROTECTED]
Subject: Re: Posting 3.3
No, this is absolutely necessary so bugs in dev builds don't get reported
as 3.2.1 bugs. "3.2.2-dev" would also be acceptable, but the version
should not remain at 3.2.1.
Keith
-Original Message-
From: Marc Saegesser [mailto:[EMAIL PROTECTED]]
Sent: Thursday, February 08, 2001 11:04 AM
I regularly use ajpv13 to upload files 2mb, using cvs head
of jakarta-tomcat.
Keith
-Original Message-
From: kenneth topp [mailto:[EMAIL PROTECTED]]
Sent: Thursday, February 08, 2001 6:43 PM
To: [EMAIL PROTECTED]
Subject: RE: [PROPOSAL] Tomcat 3.2.2 Release Plan
Henri,
Can you add
Cvs head jakarta-tomcat is 3.3. There is a branch for 3.2.
Keith
-Original Message-
From: kenneth topp [mailto:[EMAIL PROTECTED]]
Sent: Thursday, February 08, 2001 8:26 PM
To: [EMAIL PROTECTED]
Subject: RE: [PROPOSAL] Tomcat 3.2.2 Release Plan
Keith,
Is head 3.2.x or 3.3x?
Thanks,
the subversion after a release.
It is irrelevant if the new development ever goes golden or not.
It is an unarguably bad thing for multiple copies of code floating
around in public to have the same version number.
Keith
-Original Message-
From: Keith Wannamaker [mailto:[EMAIL PROTECTED
Apache Vhosts can be mapped to directories with
http://httpd.apache.org/docs/mod/mod_vhost_alias.html
This eliminates having to restart the server for changes -
just change the directory structure.
Keith
-Original Message-
From: Jino Lee [mailto:[EMAIL PROTECTED]]
Sent: Wednesday,
Maybe add them to the
/builds/jakarta-tomcat/native-3.3/linux tree?
Keith
-Original Message-
From: GOMEZ Henri [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, February 21, 2001 6:00 AM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: INFO on mod_jk and RPMs
Direct linux binary :
I committed that fix a few months ago; I thought I
got both methods but must not have. I will investigate.
Keith
| -Original Message-
| From: kevin seguin [mailto:[EMAIL PROTECTED]]
| Sent: Thursday, May 17, 2001 7:22 AM
| To: [EMAIL PROTECTED]
| Cc: [EMAIL PROTECTED]
| Subject: Re:
+1
Keith
| -Original Message-
| VOTE:
|
| [ ] +1 REMOVE: Apache 2.0 mod_jk should be removed from
|jakarta-tomcat for Tomcat 3.3
| [ ] -1 KEEP: Apache 2.0 mod_jk should be kept in
|jakarta-tomcat for Tomcat 3.3
I just finished merging all the chunked encoding
support for ajp13 into j-t-c and was about to checkin.
I'll hold off until we decide about this:
| Henri - could we undo the ajp13.c changes, for example by copying the
| current ajp13 from j-t and re-doing the autoconf changes ? Having
Keith
Oops, yep, that fix only went into the _32 branch.
3.3 still uses r-uri.
IIRC the thread never reached a consensus, except that
a proxy is free to decode and encode requests, so
encode(r-uri) might be permissible, but r-unparsed_uri
is the only way to preserve the encoding.
Keith
|
Then we need to be sure to encode r-uri in the main branch
and to change r-unparsed_uri to encode(r-uri) in the 3.2
branch. I am swamped now and will put it on a long todo
list.. if anyone beats me to it.
Keith
| -Original Message-
| From: [EMAIL PROTECTED] [mailto:[EMAIL
Hi Henri et all,
I'd like to sync tomcat_32, jakarta-tomcat, and
j-t-c with the same code-- that is, using r-uri
in all cases, but re-encoding it with
ap_escape_uri. This seemed to be the consensus
a month or two ago in the discussions, as proxies
do the same thing (decode, then re-encode).
| -Original Message-
| What about that patch which allways set ContentLength
| but try to get others datas only in contentLength is set
| and not -1
|
|
| --- Ajp13.java.orig Mon Sep 17 11:16:05 2001
| +++ Ajp13.javaMon Sep 17 11:16:30 2001
| @@ -411,8 +411,8 @@
|
I'm not sure I understand why the session id was not
also showing up with r-unparsed_uri. I'm doing some
experimenting now..
Keith
|/login/login.vm%3bjsessionid=q95pbsuof1
| Probably not. It's a side of effect of the last change which was
| to use s-req_uri = ap_escape_uri(r-pool, r-uri);.
Are you using mod_jk?
| -Original Message-
| From: Bill Barker [mailto:[EMAIL PROTECTED]]
| Sent: Wednesday, September 26, 2001 1:17 PM
| To: [EMAIL PROTECTED]
| Subject: Re: TC 3.3: getRequestURI()
|
|
| I don't get this with RC1. From tomcat-log with debugging enabled for
Hi Bill, would you resubmit a patch that makes use of either
Apache or jk's pools? ie ap_strdup or jk_pool_strdup.
That would be a better way to solve the problem. Apache
modules should and do avoid os memory-allocation routines
like the plague. I think uw_map-p would be ok, but please
do some
I'm +1 for this. It is the best solution.
Keith
| -Original Message-
| From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
|
| 3. Revert to the use of uri ( i.e. the decoded uri ), and
| change the getRequestURI ( the facade ) to generated a
| 'canonical' encoding.
| Problems:
I was afraid of that... guess os memory allocation it is, then.
Keith
| It looked to me like
| uw_map-p wasn't suitable for per-request allocations (i.e. it would just
| eat memory until the server was re-started), and since this is in common, I
| couldn't use ap_strdup since that breaks all
Henri, I do not think this will be useful
or necessary with the planned changes. I'd
be -1.
r-uri will be used, making the mod_rewrite
folks happy, and the facade will encode the
uri, which implements the spec correctly.
Does this plan break something, the reason
you want to add an Option?
What whould happen in 3.3 if ForwardEscapedURI was chosen?
Wouldn't the facade escape it again?
Keith
| -Original Message-
| From: GOMEZ Henri [mailto:[EMAIL PROTECTED]]
| Sent: Monday, October 01, 2001 10:10 AM
| To: [EMAIL PROTECTED]
| Subject: RE: Volunteers for: - RE: TC 3.3:
Why can't we implement the 3.3 collaborative solution in 4.0 ?
That would maintain compatibility.
I just hate to provide an option which could result
in wrong (double escaped) behavior. At the least,
it's one more variable to debug, at worst, it will
generate erroneous bug reports. I'd
I thought you were talking about the mod_jk in the TC3.3
branch. If you're talking j-t-c only, then I don't mind an
Option, as long as it defaults to the 3.3 behavior.
Keith
| -Original Message-
| From: GOMEZ Henri [mailto:[EMAIL PROTECTED]]
| Sent: Monday, October 01, 2001 11:24 AM
|
I thought what we decided to do was use
s-uri = r-uri (a URI decoded already in Apache)
and in the facade, re-encode it. So
JK_OPT_FWDURICOMPAT should be the default.
| -Original Message-
| + * We use JkOptions to determine which method to be used
| + *
| + *
It would be nice also to display the command that is used
to initialize the jk web config files, jkconf or whatever.
Keith
| -Original Message-
| From: Jeff Turner [mailto:[EMAIL PROTECTED]]
| Sent: Sunday, October 21, 2001 2:44 AM
| To: [EMAIL PROTECTED]
| Subject: [PATCH][3.3]
I think there may be a problem with resource loading in TC3.3.
If I add a property file to the app class path by setting
org.apache.tomcat.apps.classpath, then the call to
ResourceBundle.getBundle(foo) doesn't find it. Nor does
it get located if I place the said property file in
Hi Costin,
Yes, I verified that this does indeed do the trick.
Wonder if Sun is going to fix ResourceBundle to handle this?
Hope so! At any rate, thanks for the tip.
Keith
| -Original Message-
| From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
| Sent: Monday, November 26, 2001 6:49
I've been debugging a socket problem in ajpv12 (NT) where bits
are being written by Tomcat to the socket (back to mod_jk), but
jk's read fails with a SHUTDOWN. It's as if the bits don't
quite make it onto the wire, and the socket closure is a hard close.
I thought the point of so_linger was to
this solves the problem, but at least the fix is now
documented for posterity.
Keith
| -Original Message-
| From: Keith Wannamaker [mailto:[EMAIL PROTECTED]]
| Sent: Wednesday, December 12, 2001 2:59 PM
| To: [EMAIL PROTECTED]
| Subject: ajpv12 socket closure
|
|
| I've been debugging a socket
A 4.x person might want to take a look to make sure this
doesn't happen there, too. The performance and stability
of Netscape is like night and day with this...
Keith
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Thursday, December 20, 2001 2:57 PM
To:
The 2.2 servlet spec errata says the uri from
HttpServletRequest.getRequestURI() should remain encoded.
[http://java.sun.com/products/servlet/errata_042700.html]
Tomcat 3.2 standalone handles this correctly, but the
mod_jk connector does not.
The connector uses the decoded uri from Apache
There is a lingering bug in (at least) Sun's JDK
that causes SimpleDateFormat to occasionaly throw a
StringIndexOutOfBoundsException instead of a
ParseException.
http://developer.java.sun.com/developer/bugParade/bugs/4212077.html
(Requires a cookie; thanks, Sun)
Some rogue client out there is
Is there a known problem with jsp filenames containing '_'?
The Jasper in jakarta-tomcat head compiles 'foo_bar.jsp' to
'foo_0005fbar.jsp' for me. Clearly there is some escaping
gone awry, but surely I'm not the first to encounter this?
I'm digging into it now...
Keith
'_'.
Keith
| -Original Message-
| From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
| Sent: Tuesday, July 10, 2001 10:19 PM
| To: [EMAIL PROTECTED]
| Subject: Re: '_' - 0x5f and Jasper
|
|
| On Sat, 7 Jul 2001, Keith Wannamaker wrote:
|
| Is there a known problem with jsp filenames
When the String - MessageByte change was made
to Request (rev 1.70), setRequestUri was tossed.
We were using that in a custom inteceptor to
do some simplistic URL rewriting.
I can't tell from the logs or archives if it was
replaced? Does anyone have a problem with me
adding a messagebytes
| -Original Message-
| From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
| Sent: Wednesday, August 08, 2001 11:16 AM
| To: [EMAIL PROTECTED]
| Subject: Re: TC 3.3 = m3 Request.setRequestUri
|
|
| Hi Keith,
|
| After String-MessageByte, instead of storing the request
| info as String,
Somethings not quite right in SimpleMapper with
respect to default containers. If I set up a
default conainer, the note on the global container
is set OK. But the way it works now is that
PrefixMapper returns a null container for a
URL that is not mapped, which ends the request.
What I can't
Hi David,
Unfortunately there are people who were breaking because
we didn't follow the spec. The better way to fix it is
to create an inverse function for
ap_parse_uri(request_rec *r, const char *uri) [http_protocol.c]
in mod_jk... one that would 'unparse' the munged
r-uri rewrite and use it
| This breaks query strings.
|
| r-uri contains only the path portion of the URL. r-unparsed_uri
| contains the URL in its virgin format - as sent by the client.
No, I don't believe this is quite right.
getRequestURI() in a servlet should return
r-unparsed_uri minus a query string.
Setting
Costin's right.. seems like the problem encountered
was that there was no way to recreate the encoding
(or lack thereof) on the original uri. So the
kludge/solution was to use the unparsed uri and
chop off the query string.
Keith
| -Original Message-
| From: [EMAIL PROTECTED]
Try ap_escape_uri
Keith
|
| s-req_uri = ap_encode_uri(r-pool, r-uri);
|
| David, or anyone else interested too, would you
| try this with some corner test cases and see if
| it lives up to expectation?
|
| I gave it a shot and it compiled fine, but got this error at runtime:
|
|
|
|
| On Tue, Aug 14, 2001 at 11:49:43PM -0400, Keith Wannamaker wrote:
| Try ap_escape_uri
|
| That does the trick.
|
| Here's the patch which gets things working again, thanks for all the help.
| Hopefully this will get applied soon. Is there any 3.2.4 release planned to
| fix the small number
I want to be able to support chunked encoding through ajpv13
in TC 3.3. Apache decodes the body for us, it is only a matter
of making the distinction between an unknown content-length
an a zero content-length. Costin I'd like to tweak what
you did here.. do you have an opinion on the matter?
| -Original Message-
| I suppose you're talking about chunked encoding on the input ?
Yep.
| The current mechanism is not the best - we shouldn't use Content-Length,
| but let the connector signal the end of the stream.
Yes, exactly. Both request and the facade input stream take an
Hi John,
I did not need to do this to build tc4 out of the box.
What was the build error? Is your build.properties pointing
to jndi OK? If you do an ant -verbose, does ${jndi.home}
get set correctly? TC4 will automatically include
${jndi.home}/lib/jndi.jar (see catalina/build.xml:28)
Keith
| This has nothing to do with tomcat accepting Chunked encoding on the
| request - we did few fixes but this hasn't been tested yet, I believe
| there are few changes in mod_jk we still have to do.
|
Almost done...
Keith
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:
|
Hi, David, Colin, et al.,
| 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.
|
| The fix in Ajp13 ( java side ) should be already in, and any _small_
| fix in the java side is ok.
| | - 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
Could this ever happen or am I doing something silly?
Keith
Index: src/share/org/apache/tomcat/startup/EmbededTomcat.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/startup/EmbededTomcat.java,
v
retrieving
When I run a debugger (which is now running the
embedded tomcat), I point straight to the
build/tomcat/classes tree rather than have a lib
directory. This way I don't have to rebuild the
jars every time I make a change. I would have
thought this would be a common procedure?
Keith
|
This patch enables chunked input through mod_jk:
http://www.apache.org/~keith/jk/
I think they are rather minor changes.
Please review, discuss, and throw everything you have
at it. If Larry approves I will commit this (or an
approved version) to tc 3.3. In addition, I would port
it to the
I don't know, the 99 just looked pretty stale.
Feel free to change it... Keith
| -Original Message-
| From: Christopher Cain [mailto:[EMAIL PROTECTED]]
| Sent: Sunday, September 02, 2001 2:19 PM
| To: [EMAIL PROTECTED]
| Subject: Re: cvs commit: jakarta-tomcat/src/webpages index.html
|
Greetings,
There is a bug in ByteChunk.indexOf which manifests itself
in the safe url parsing. That is, BC.indexOf returns an
offset relative to the start of the byte buffer, rather
than the internal starting point.
So, when safe url checks for indexOf('%'), depending on the
length of the
I haven't heard from any 4.0 folks -- any interest
in me doing something similar for that tree?
Keith
| -Original Message-
| From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
| Sent: Thursday, April 18, 2002 8:58 AM
| To: [EMAIL PROTECTED]
| Subject: cvs commit:
Costin, et al, if you folks know of a faster way to check for this,
by all means
-Keith
| -Original Message-
| From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
| Sent: Tuesday, April 23, 2002 2:50 PM
| To: [EMAIL PROTECTED]
| Subject: cvs commit:
|
Hey folks,
There seems to be a threading issue introduced between
3.3 and current 3.3.2-dev head. When running the code
under heavy load with four tcp endpoints (2 http10, ajp12,
ajp13) eventually one of the http connectors disappears
from thread dumps. In going through diffs the most
Remember last week when I mentioned the thread problem in 3.3-head?
In PoolTcpEndpoint, when there is a SocketException, we log a
non-fatal error message. The problem began when Remy pointed
the string manager to an empty bundle. StringManager.getString
will return a null rather than throw a
This is why-- in PoolThreadEndpoint, a new thread is
started only when a socket is accepted. Since the npe
happened before this, the whole thing shut down without
running another thread.
So, we need to wrap for Throwable, and I think the best
place to do it is around the accept in PTE.runIt.
I've written some ant tools that allow builds to populate
the Tomcat work directories with precompiled JSPs. I'm
trying to decide a home for them, if any, and was thinking
of a new package org.apache.tomcat.ant .. any other
preference?
code is @ http://apache.org/~keith/
Keith
--
To
:[EMAIL PROTECTED]]
| Sent: Wednesday, May 15, 2002 7:06 PM
| To: Tomcat Developers List
| Subject: Re: ant tools for 3.3
|
|
| On Wed, 15 May 2002, Keith Wannamaker wrote:
|
| I've written some ant tools that allow builds to populate
| the Tomcat work directories with precompiled JSPs. I'm
Yes, put build/tomcat/ant/tomcat-ant.jar in your classpath
and do something like:
property name=jspc value=org.apache.tomcat.ant.Tomcat3Precompiler /
taskdef resource=ant.properties /
target name=jsp
jspc srcdir=/foo/jsps
destdir=tomcat_work_path/webapps/foo
uriroot=/foo/jsps
It's already checked in to Tomcat, so the jar is created
when you do a build.
Keith
| -Original Message-
| From: GOMEZ Henri [mailto:[EMAIL PROTECTED]]
| Sent: Friday, May 17, 2002 8:26 AM
| To: Tomcat Developers List
| Subject: RE: cvs commit: jakarta-tomcat RELEASE-NOTES-3.3.2.txt
|
No, for a Tomcat which has already been installed,
you should use the JspC tomcat option to precompile
JSPs.
What I did is to create an Ant task with the same
functionality as the already-present JspC option,
for use in build environments.
Keith
| -Original Message-
| From: Jason
I agree that's why I wrote the task :-)
Maybe I misuderstood Jason,.. thought he wanted to use
the ant tool post-installation-- tomcat recompile would
be a better option in that case, IMO. But, of course,
the ant tool can be used, if ant is available.
Keith
| -Original Message-
|
You've got it. I thought you were talking post-install, but,
again, if Ant's available you can use the task whenever you
wanted to.
Keith
| -Original Message-
| From: Jason Corley [mailto:[EMAIL PROTECTED]]
| Sent: Friday, May 17, 2002 9:50 AM
| To: Tomcat Developers List
| Subject:
Ah, I thought the JspC task had been around longer.
I agree. The build should now ignore that task unless
an appropriate version of Ant is installed.
Keith
| -Original Message-
| From: Ignacio J. Ortega [mailto:[EMAIL PROTECTED]]
| Sent: Saturday, May 18, 2002 12:03 PM
| To: 'Keith
FYI The ant jspc testcases are failing with head of j-t-j/jasper2:
Using Jasper in jakarta-tomcat/
[wannamak@piper jsp]$ java org.apache.jasper.JspC -v
-d /usr/local/cvs/jakarta-ant/src/etc/testcases/taskdefs/optional/jsp/java
+1
Keith
| -Original Message-
| From: Remy Maucherat [mailto:[EMAIL PROTECTED]]
| Sent: Tuesday, May 21, 2002 9:33 PM
| To: [EMAIL PROTECTED]
| Subject: [VOTE] New committer: Denis Benoit
|
|
| I'd like to propose Denis Benoit Denis.Benoit at fbn.ca as a committer on
| the Tomcat
Hmm, you might try taking xerces out the CLASSPATH property
if there is already one in {ant.home}/lib
I would guess there are two copies of an XML provider in
your classpath.. are you using JDK1.4? I did a google on
this error and apparently it comes up a lot.
Keith
| -Original
When using CC2 with TC 3.3.2, every request sets both
the content-length and the transfer-encoding, which
is not only wrong, but can confuse some clients.
Content-Length: 9
Transfer-Encoding: chunked
The 4.0 org.apache.catalina.connector.http.HttpConnector
does not have this problem. Any quick
Greetings,
I brought this up in November. Remy and I have a disagreement
on how important fixing this bug is. I want to see if there is
a quorum of other committers who understand the problem and think
it should be fixed prior to the next stable build release of 4.1.
The immediate problem is
Hey Bill, thanks for the input. I am all ears if you can think of
a better way to fix this in 4.1. Rather than forward-porting this
fix to 5.0, I will look at better ways of doing it there since you
indicate they exist.
I think this is the way to go for 4.1 since it will fix both the
most and
Remy,
The fix corrects the bug, which is that credentials are shared
between webapps. As I've asked before, if there is a better way
to correct it, I'm all for it. There are a lot of bugs that have
been in the code for a long time, it doesn't mean they aren't bugs.
The behavior bothers me, and
Hi Joseph,
Try checking out jakarta-tomcat-4.0 and jakarta-tomcat-connectors
with tag TOMCAT_4_1_22 or TOMCAT_4_1_18. The failure is due to a
recent checkin that broke the build. If you extract the fifteen or
so project dependencies into one separate dir, then point your
build.properties to
Hi Bill,
I had closed the bug because Remy told me it was already
fixed in 5.0. I guess it wasn't. If you do any more work
on it you should indicate the bug which is 14616.
Keith
| -Original Message-
| From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
| Sent: Thursday, March 13, 2003
Hi Al, well of course production code is in CVS too. Just use
the appropriate tag when checking out. There might have been
something funny about your tarball, and you can eliminate this
possibility by pulling straight from CVS.
Keith
| -Original Message-
| From: Al [mailto:[EMAIL
Hi Mark, you can start the vm with -Djavax.net.debug=all to get
under the hood of jsse and see why the handshake is failing.
You may also need to do some conversion as described here:
http://www.comu.de/docs/tomcat_ssl.htm.
Keith
| -Original Message-
| From: [EMAIL PROTECTED]
| ballot
| [ ] Alpha
| [ ] Beta
| [X] Stable (GA)
| /ballot
|
Keith
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Hi Remy, * does map to the default context. Can you think of any special
downstream handling that we should do for '*'?
Keith
| -Original Message-
| From: Remy Maucherat [mailto:[EMAIL PROTECTED]
| Sent: Thursday, July 03, 2003 2:50 AM
| To: Tomcat Developers List
| Subject: Re: cvs
Hi Bill, I am partial to handling it in the default servlet.
I agree the root context can't speak definitively for all
contexts, but I think it has a better chance of knowing a
proper response than the connector.
Keith
| -Original Message-
| From: Bill Barker [mailto:[EMAIL PROTECTED]
|
Tomcat 4.x has a problem -- it challenges for auth
prior to any redirects. This is wrong because it causes
most browsers to cache auth info for the entire domain
when hitting top-level directories.
For example:
WRONG way:
GET /foo - 401
GET /foo with auth
= /;
+return(false);
if ((pattern == null) || (pattern.length() == 0))
pattern = /;
I'll apply this fix if someone more versed in 4.x approves it.
Keith
| -Original Message-
| From: Keith Wannamaker [mailto:[EMAIL PROTECTED]]
| Sent: Wednesday, July 03, 2002 7:34 PM
|
| [X] I don't want the API's split into separate repo's
| [ ] I don't care
| [ ] I want the API's split into separate repo's.
|
TC 4 has too many external module dependencies as it is.
Keith
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
I'm using http11 on a busy site with more or less Tomcat 3.3 head
(3.3.2-dev). I set up the connector with ServerSoTimeout=5000,
SoTimeout=5000, maxThreads 100, maxSpare 50, minSpare 20.
This yields severe performance problems after only a short time in
service. On reverting back to http10, the
Same box, same app, same test, with Tomcat 4.0.6's http10 and 11 adaptor:
coyote/http1137rq/sec, 406kb/sec
http10 30rq/sec, 181kb/sec
I've always held that 3.3 was more lean and mean than 4.0 but
now I'm wondering if this is just indicating some basic architectural
differences.
between the tests.
I'm still investigating, but it may be easier for us to
move to 4.0.
Keith
| -Original Message-
| From: Remy Maucherat [mailto:remm;apache.org]
| Sent: Thursday, November 07, 2002 2:22 AM
| To: Tomcat Developers List
| Subject: Re: Coyote/Http11 under load
|
|
| Keith
1 - 100 of 150 matches
Mail list logo
