Hi everyone.
I ran into bug #6299 today (two server-side includes fail with buffering
on), did some debugging, and found the cause of it.
I have no doubt that a bunch of other bugs in bugzilla are caused by the
same issue.
Basically, the class and its helper classes have a pretty serious
Remy Maucherat wrote:
Implementing the SingleThreadedServlet interface will not help thi
Are you sure ?
(I didn't look at the code at all, so I'm just wondering)
Otherwise, it would be a really cheap way to make it work.
Thanks for looking into it anyway.
Implementing
I'll be done with the SSI rewrite tomorrow.
I'd like to get the community's advice on a number of issues:
1-I changed the names of the files from Ssi... to SSI... This seems to
be more consistent with the naming scheme of other files, and made
things easier for me since I did a gradual
Dan Sandberg wrote:
I'll be done with the SSI rewrite tomorrow.
I'd like to get the community's advice on a number of issues:
1-I changed the names of the files from Ssi... to SSI... This seems to
be more consistent with the naming scheme of other files, and made
things easier for me
Please note that the example uses a PrintWriter, and not a
BufferedWriter. Looking at the source of PrintWriter, all of the
println() methods write the data to the underlying OutputStream -
characters are not buffered Writer level. If there is any buffering,
it occurs in the
Hi everyone.
Here are more changes to the SSI code.
I have a test case ( comparing SSI behavior to Apache by using .shtml
files in different tomcat webapps / apache directories ) which I have
not included because I'm not sure where to put manual test cases like
this. If there is an
I think Pier's conerns are quite reasonable. Let me bring up a few
points that I think are central to the debate:
A. Security. This is the most important concern in allowing new
commiters. If they purposely or accidently introduce security issues,
this tarnishes the Tomcat name. Code
Perhaps Bill had the same problem when he tried to submit my code.
The code I posted on this list had the file named SSIServlet.java ( not
SsiServlet.java ) and the web.xml file called it SSIServlet.java.
Bill changed those both to SsiServlet, perhaps because of the problems
you are having.
Granting that I'm not as experienced with open-source collaboration as
the rest of you are, my intuition is that the easier it is for people to
make changes to the code-base ( assuming their contributions are
reviewed ) the faster the code-base will improve and bugs will be
eliminated.
I would hate to be the cause of a totally messed up
release...
Thanks,
Dan
Dan Sandberg wrote:
Hi Remy.
I filed a bug report about this a week ago at:
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9559 ( which was
marked invalid )
Apparently this is a long-standing issue, as I
Yes, this is true. Also, a request to /foo which becomes /foo/index.jsp
would also screw up relative links.
I believe the following behavior would do what people want 99% of the
time while still not screwing up the scenario you mentioned or the one I
mentioned above (forgive the pythonic
The spec says that for each welcome file you must check 'whether a
resource in the WAR is mapped to that request URI. The web container
must send the request to the first resource in the WAR that matches. '
This is somewhat ambiguous--do they mean resource like getResource(...)
or do you
Ok, but this changes the bahavior of Tomcat, so this has the potential to
break things.
Also, the new spec clarifies it a bit, and requires to be able to do welcome
files on non-existing paths, but which map to something (so getResource is
not a good test). Since everything maps to the default
I tried to commit some changes relating to the SSI regression tests, and
got the message below.
Can someone fix this or tell me what I have to do to fix this?
Thanks,
-Dan
In directory .:
Message: cvs [server aborted]: correct above errors first!
Message: Parser Error: ' Access denied:
Good call. I had been using /cvs/cvspublic
Thanks,
Dan
Pier Fumagalli wrote:
Dan Sandberg [EMAIL PROTECTED] wrote:
I tried to commit some changes relating to the SSI regression tests, and
got the message below.
Can someone fix this or tell me what I have to do to fix this?
Thanks
that SSI on head was blown away for changes to an older
version. Any chance we can nicely merge the two good versions into
one more good version?
-Paul Speed
Dan Sandberg wrote:
Hi everyone.
Here are more changes to the SSI code.
I have a test case ( comparing SSI behavior to Apache by using
was the only thing I thought I was missing.
I'm curious: How could I have checked out an older version accidently?
Wouldn't I have had to explicitly specify a date or tag or something?
... This is all quite depressing ...
-Dan
Paul Speed wrote:
Dan Sandberg wrote:
Yes, let's merge them
@oogie tmp]$ cvs --version
Concurrent Versions System (CVS) 1.11.1p1 (client/server)
I tried the same thing on Solaris, and had the same problem.
Any idea? Am I doing something stupid?
-Dan
Dan Sandberg wrote:
Yes, let's merge them together. How do I get to the code that you
fixed? Were
be sufficiently late enough.
Hope it works,
-Paul
Dan Sandberg wrote:
I'm trying to checkout an old version of tomcat with the following command:
[dan@oogie tmp]$ cvs co -D 4 months ago jakarta-tomcat-4.0
And I'm getting the following error:
Core dumped; preserving /tmp/cvs-serv41751
work. You could also add the files back from the
Attic, since it's a completely different directory.
- Original Message -
From: Dan Sandberg [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED]
Sent: Monday, July 01, 2002 4:25 PM
Subject: Re: [PATCH] Re: SSI Servlet has big
How? I'm not running any CVS commands. You need admin access to delete
the #cvs.wfl or #cvs.lock files, which I don't have.
If there's a way for me to fix this, please let me know.
-Dan
Remy Maucherat wrote:
Trying to tag the CVS with 4.1.7 ...
cvs server: [03:59:27] waiting for
the two SSI implementations together.
-Dan
Dan Sandberg wrote:
How? I'm not running any CVS commands. You need admin access to
delete the #cvs.wfl or #cvs.lock files, which I don't have.
If there's a way for me to fix this, please let me know.
-Dan
Remy Maucherat wrote:
Trying to tag
Hi Paul.
That class is specific to the server-side include code, so the server
doesn't need to know anything about the writeTo method.
Basically, the ServletOutputStreamWrapper is used so that we can capture
the result of Tomcat processing a page, so that we may include the
contents of one
place was to
try to find a good way of overriding the write(int) method of
OutputStream in a server context. Is there another class which extends
ServletOutputStream and would give me a more real world example?
On Tue, 2002-11-12 at 00:03, Dan Sandberg wrote:
Hi Paul.
That class is specific
I've been a bad boy by not taking care of this. This is just the kind
of encouragement I need to movitate my guilty butt. I'll work on it
tonight and with any luck commit it tomorrow.
Which branch do I commit this to? And if the answer is the 4.x branch,
who/how does it get forward-ported?
What's the story with the servlets-ssi.renametojar hack?
Are the classloader issues that necessitated this going to be fixed in
Tomcat 5? Will they be backported to Tomcat 4?
If this won't be fixed in Tomcat 5, than we can split servlets-ssi into
the insecure part ( which can run exec ) and
Create a separate minimal JSR 154 only distribution of Tomcat 4.x:
+1 [ ]
0 [ ]
-1 [x]
[I will quickly change to a +1 if the minimal change I suggest is made. Others prob. will as well]
Explanation:
Beginners want ease of use over minimality because they want to get
started. They can't
27 matches
Mail list logo
