Costin Manolache wrote:
What about finally creating tomcat-modules or tomcat-addons ( or any other
name ),
for stuff that is (more or less) tomcat version independent, or at least
works for
multiple recent versions, and can be released independently ?
This way the cluster stuff would have a
Costin Manolache wrote:
By modules/ I mean mostly release units - so maybe a build.xml to create
build and package the module, some readme, manifest, etc. Tomcat normal
release wouldn't include the module, but it can be released independently,
maybe
for multiple versions of tomcat.
Look,
Costin Manolache wrote:
I don't see the benefit of having things like cluster support in the tomcat
release -
if someone does want a cluster, they can easily download an additional
jar -
setting
up a cluster involves a lot of work, we won't make it much simpler by
bundling the jar with
Costin Manolache wrote:
Of course - all stuff must compile at least - but I don't think it's a
reasonable
requirement to have all modules or other things that are not part of tomcat
tested in order to do a release.
But in that case, they could not be the part of the Tomcat code.
If you
Costin Manolache wrote:
On 6/19/06, Mladen Turk [EMAIL PROTECTED] wrote:
I agree - it's good to have a single codebase !
But I strongly disagree that we should have one big bloated release that
includes
everything in the codebase.
Look, all that I'm saying is that the code that is
inside
William A. Rowe, Jr. wrote:
Mladen, maybe you aught to have deleted the @author tag while you were
at it :)
Right. It seems so :)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL
Hi all,
IMO this is mostly Costin related, because he has something
inside the sandbox :)
Now my question is, could the current sandbox content be
moved to the /sandbox/abc so I (or someone else)
can create a /sandbox/xyz ?
Right now the sandbox is not the 'sandbox' but rather
the Tomcat6Sanbox
Rainer Jung wrote:
Hi Mladen,
Costins README.txt inside the sandbox already suggested:
I know, I read the README, but the content inside does
not follow the README. That's the point :)
Regards,
Mladen.
-
To unsubscribe,
Rainer Jung wrote:
-static int JK_METHOD maintain_workers(jk_worker_t *p, jk_logger_t *l)
+static int JK_METHOD maintain_workers(jk_worker_t *p, time_t now,
jk_logger_t *l)
{
unsigned int i = 0;
jk_uint64_t curmax = 0;
long delta;
-time_t now = time(NULL);
-
[EMAIL PROTECTED] wrote:
I'm not seeing the windows problems, I used to have many problems on
windows using jdk1.4, but since 1.5 I have no problems at all. I do have a
brand new machine, so maybe there is some windows patch on it that I
didn't have before, other than that I can't think of
Costin Manolache wrote:
You mean to remove the 'single tree', and only have components ? I can live
with this,
but I don't think it's the best idea - and I haven't seen any reasons for
that.
The idea of the sandbox is that you can try things in it - including the
single source tree :-)
Rainer Jung wrote:
Hi,
I would like to start releasing mod_jk 1.2.16 this week.
Any comments?
+1
--
Mladen.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
William A. Rowe, Jr. wrote:
Someone might want to review the 2nd to last paragraph here;
http://www.apache.org/dist/tomcat/tomcat-5/v5.0.30/bin/
He he :)
Seems like old copy/paste policy is in place for years :)
Regards,
Mladen.
Rainer Jung wrote:
Hi,
As a result of 1) I propose to roll 1.2.17 as soon, as Mladen has done
4) (assuming it's just minor stuff).
Like said, lets postpone that for Monday.
The changes I made are mostly cosmetic, since I reverted
the reties patch. I need to make some testings
during the
You see how desperate I am when writing this on Sunday :)
Anyhow, we are pretty close to the new JK release that I
hope will be the most usable and stable whatsoever.
The things we agreed so many times before, but having
obviously too little resources to actually create are
the 1.3 branch (aka
Costin Manolache wrote:
What's the status with mod_proxy ?
It seems this kind of change would break backward compatibility, and if
this
happens - maybe it's better to fix the protocol marshalling limitations or
change it completely.
I hate the idea of patching an old and mostly broken
Jean-frederic Clere wrote:
Rainer Jung wrote:
It's called once a minute (at least if a request comes in) to be able to
clean up things not directly related to the actual request, like closing
idle connections.
Something to add to mod_proxy probably.
If you finish your maintenance module
Jean-frederic Clere wrote:
If you finish your maintenance module then it'll
be his responsibility to make a heartbeat independent
of the request, on the regular intervals.
Sure I need an extra program to make a real heartbeat but I still still
don't see how I could close a socket in a httpd
Filip Hanik - Dev Lists wrote:
This is a question for the user list, it might be better for you to take
the inquiries there, and you shouldn't need to hack tomcat for something
like this.
Simply create a filter, that wraps your HttpServletRequest in a
HttpServletRequestWrapper,
worst case
Henri Gomez wrote:
What the status of mod_jk 1.2.17 ?
It would be usefull to get some binaries to help users check against
their platform, for instance win32.
http://www.apache.org/dist/tomcat/tomcat-connectors/jk/binaries/win32/
Wait for a while until synced.
Regards,
Mladen.
Rainer Jung wrote:
Hi Mladen,
would you mind putting it on
http://tomcat.apache.org/dev/dist/
first?
Nope. There is no version/platform directory
structure inside.
Regards,
Mladen.
-
To unsubscribe, e-mail: [EMAIL
William A. Rowe, Jr. wrote:
IF 1.2.17 sources aren't at www. then, well, the binaries don't belong
there either.
Simply used the current method.
Was not aware of the new repo inside tomcat.
Should I delete them or what?
Regards,
Mladen.
Rainer Jung wrote:
Be careful:
I understand Henri problem report as getsockopt complaining about the
*last* argument. So it has been introduced between 1.2.15 and 1.2.16:
r386629 | pero | 2006-03-17 13:36:04 +0100 (Fri,
Henri Gomez wrote:
Well on iSeries the C compiler is very strict about these kind of
typecast so the socklen_t should be used (and the build works with
it).
Can you check the current head?
I committed the fix.
--
Mladen.
-
Rainer Jung wrote:
Then let Peter try it on Mac OS X, if he only gets a warning or a real
error.
Sure, but since
http://www.hmug.org/man/2/getsockopt.php
says that the OS/X uses socklen_t as well, we should be fine.
--
Mladen.
Henri Gomez wrote:
Good, so we're ready for a 1.2.18 release ?
Sure if the Rainer still has the energy
for another run :)
Regards,
Mladen.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL
Remy Maucherat wrote:
[EMAIL PROTECTED] wrote:
Author: mturk
Date: Tue Jul 18 08:38:14 2006
New Revision: 423119
URL: http://svn.apache.org/viewvc?rev=423119view=rev
Log:
Add svn:eol-style:native.
We'll probably need to do that for the entire repository.
-1. This will screw up diffs, which
Rainer Jung wrote:
Maybe we need to set everything to native, checkout, convert those that
have the wrong endings and commit?
No need for co/commit.
svn propset will convert current line endings to the virtual
one I suppose, and then each client depending on the platform
will have correct
Henri Gomez wrote:
Well a new show stopper for 1.2.18 ;(
Why it would be?
JK 1.2.18 is still not tagged.
--
Mladen.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Henri Gomez wrote:
Well a new show stopper for 1.2.18 ;(
Committed a fix that allows to have a
worker.name.recover_time lower then 60 seconds.
Previously the minimum value was 60 seconds, and
now is 1 second.
The default is still the same (60 seconds)
Regards,
Mladen.
Rainer Jung wrote:
6) We could make the interval configurable, but there is a real danger
of users thinking, that a low recovery interval, like 10 seconds would
make things better, whereas it is very likely, that it would make there
whole system kind of oscillate.
Well, I don't wish to
Rainer Jung wrote:
No, I think it's not:
1) This is not a regression, it was always implemented like that.
Right, and the reason it was never changed was because
no one gave any reason to change it.
Like said, 60 seconds recover timeout was probably used
since someone thought it should be
Rainer Jung wrote:
Mladen Turk wrote:
Anyhow, why would 60 second be optimal value?
It could as well be 90, 100, 180, etc...
Increasing is something totally different. I just want to avoid people
ending with a system that changes error/ok states with a high frequency,
so that the whole
Rainer Jung wrote:
I'm OK with your change.
I think we should try to educate the users via doc, that they need to be
careful when lowering these values to very small numbers. I don't know,
if that's the right term, but the system needs some damping to keep it
from switching very frequently
Hi,
I have created a branch that shows the difference between
current trunk and the new one wit correctly set
svn:eol-style and svn:executable
For example the
java/org/apache/catalina/Context.java when checked
out on linux has DOS line endings with those ugly ^M.
The same file with
Rainer Jung wrote:
To find out, why this is so: did you get the same VStudio complains for
1.2.16 or 17? I tought you built those?
I would suggest to just repack the zip, since there is no change in
repository and no official release yet.
Well, it's just packing, and its RM responsibility
Rainer Jung wrote:
To find out, why this is so: did you get the same VStudio complains for
1.2.16 or 17? I tought you built those?
I would suggest to just repack the zip, since there is no change in
repository and no official release yet.
OK.
I have used your zip file and simply run
the
Hi,
Anyone has a working copy of InstallShield
and is able to build the the .msi?
Inside iis/installer/bin one needs to put
the isapi_redirect.dll and run the
isapi-redirector-win32-msi.ism
Bill, IIRC you have one for building
httpd? Any chance you create this build?
I had mine IS 10, but the
If anyone wonders what all those SVN commit messages are about,
they are about moving the /sandbox to the /sandbox/tomcat-lite
I choose the name, but I suppose Costing might have other ideas,
so a simple 'svn mv tomcat-lite what-ever-name' should do the trick.
The problems was because the /path/*
Hi,
First of all I wish to nominate myself as a greatest spamer.
A simple SVN lock/unlock happens to send couple of thousand
emails before I realized that the email is send for each
file in the trunk.
Sorry if that made problems with you mail boxes.
Anyhow, hope no one will in the future make
Jim Jagielski wrote:
I'm assuming this the the reason for the slew of svn lock messages :)
Right :(
Any chance to suppress that in future?
If someone else accidentally hits the svn lock
on the trunk the same will happen again.
Regards,
Mladen.
Cesar wrote:
LA PUTA QUE TE PARIO HIJO DE PUTA, DEJATE DE ENVIAR BASURAA
At least try to swear on English :)
- Original Message - From: [EMAIL PROTECTED]
To: tomcat-dev@jakarta.apache.org
Sent: Thursday, July 20, 2006 10:03 AM
Subject: svn unlock:
Yoav Shapira wrote:
Hi,
On 7/20/06, Costin Manolache [EMAIL PROTECTED] wrote:
The svn messages are quite horrible IMO. Is there any way to suppress
them
in future ?
So all in all, let's treat today as the unusual event it was in terms
of volume of SVN messages, and keep things the same
Paul Querna wrote:
If you think svn is correct in sending lock/unlock/proppatch mails for
each individual file ( without at least agreggating them ) - then
It was done separately BECAUSE it was not done in a SINGLE ATOMIC COMMIT.
THIS IS CAUSED BY USER ERROR, AND NOT BY A PROBLEM WITH
Mladen Turk wrote:
Paul Querna wrote:
THIS IS CAUSED BY USER ERROR, AND NOT BY A PROBLEM WITH SUBVERSION OR
OUR CONFIGURATION.
Then you might put that somewhere inside www.apache.org/dev
One note:
Sorry, seems it was caused by the Tortoise SVN client.
It has an option to 'Get Lock
Trent Nelson wrote:
Mladen Turk wrote:
Just out of interest, is there any motivation to switch to Nullsoft's
Installer for future mod_jk/isapi_redirect releases? Given that
tomcat's win32 installer uses this, and it's free, I would think that
would be a better option than InstallShield
William A. Rowe, Jr. wrote:
Mladen Turk wrote:
Nullsoft lacks advanced IIS virtual directory
creation/deletion. I suppose it can be done with
multiple .vbs scripts.
EWWW - no :) They are keys.
No, they are not. Neither are filters :)
--
Mladen
Rainer Jung wrote:
Apache Tomcat Connectors 1.2.18 is:
[X] Stable - no major issues, no regressions
[ ] Beta - at least one significant issue -- tell us what it is
[ ] Alpha - multiple significant issues -- tell us what they are
BTW, excellent job Rainer!
--
Mladen.
Hi all,
Here is the config that IMHO each committer using
TortoiseSVN should set up.
It will resolve the things that were needed to be done for
the TC6 because they were added to the svn repo without
proper default properties.
So:
1. Right click on any Windows folder
2. Select
Mladen Turk wrote:
Hi all,
Here is the config that IMHO each committer using
TortoiseSVN should set up.
It will resolve the things that were needed to be done for
the TC6 because they were added to the svn repo without
proper default properties.
So:
1. Right click on any Windows folder
2
Jean-frederic Clere wrote:
Hi,
Does it make sense we register the AJP port to IANA?
No.
It has numerous limitations that makes it almost
unusable in anything but webserver-servlet-engine
communication. And even that is limited by the
8K message. We should persuade a next generation
binary
Jim Jagielski wrote:
I and other have run into issues where the socket
between Apache and Tomcat (due to a in-between firewall)
isn't closed as it should be... I'm digging further into
this as far as why the timeout isn't being honored, but
it got me thinking that a no reuse option might be
Remy Maucherat wrote:
Maybe JIRA should be used for TC 6 ?
++1
Further more, I would like to have that
all across tomcat.apache.org, not only
for TC6.
--
Mladen.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional
Filip Hanik - Dev Lists wrote:
I was gonna suggest a
worker.workername.reuse=True|False
This is a very minor, non intrusive change since jk_ajp_*.c already has
a struct that has a reuse flag, and it respects it, the code currently
hard codes it to true.
It (or at least it should) favors
Jim Jagielski wrote:
Makes no sense to me.
Yeah, the recommendation for people who are
hit by this is either (1) avoid AJP or (2)
set MaxRequestsPerChild (in httpd) to 1
See my reply about AJP13_END_RESPONSE reuse flag.
The Tomcat should be responsible for deciding
if the connection
Filip Hanik - Dev Lists wrote:
cool, I will cut the release
Can you hold that up till Monday?
I would like to test and cut the tcnative
in front so that installer uses new binaries.
Regards,
Mladen.
-
To unsubscribe,
Filip Hanik - Dev Lists wrote:
Mladen Turk wrote:
See my reply about AJP13_END_RESPONSE reuse flag.
it works fine, connections close
So, is it working or not?
You've send two contradictory posts to this thread :)
Regards,
Mladen
Jim Jagielski wrote:
On Aug 18, 2006, at 12:40 PM, Mladen Turk wrote:
The Tomcat should be responsible for deciding
if the connection will be reused or not.
This doesn't match, iirc, how the whole cache_timeout
(or connection_pool_timeout) is done within mod_jk...
Basically, what's needed
Peter Rossbach wrote:
+1, and we can move the other parts later. Give new source a chance with
a better bug system :-)
I agree. The transition of other components if ever done
would be a great thing to have, but its not mandatory for
having TC6 in JIRA.
If someone has a knowledge and itch
Rainer Jung wrote:
I still don't have a consistent idea what happened around the firewall:
It is a very simple:
1. There are firewalls that will cut the connection
between mod_jk and Tomcat without sending FIN.
You can not do anything with that, cause they
simply exist, and I don't
Filip Hanik - Dev Lists wrote:
Rainer Jung wrote:
Mladen Turk schrieb:
The patch the Jim provided, gives us the functionality of turning off
the keep alive from the clients (httpd in this case) perspective.
I do not agree, although its a hack and easy fix for
the problem itself
Jim Jagielski wrote:
I'd like to propose that I commit the patch, and then we
add in the additional awareness of keepalives from
the TCP as well as AJP PoVs.
Sound OK?
Sure. Think Rainer already committed your patch.
--
Mladen.
Hi,
There is one serious bug in 1.2.18 that makes
it unusable for IIS if there is a missing optional
directive (rewrite_rule_file).
Since we had already lots of commits fixing various
problems, 1.2.19 is something we should cut pretty
soon.
Any comments or pending work?
I would like that we
Rainer Jung wrote:
I would then make a snapshot available on dev, such that interested
parties can compile and check, and could start a formal release process
a week later.
I know, that new features impose new risk, on the other hand the release
process does also consume some energy, so
Rainer Jung wrote:
OK, so
- what's the show stopper: the rewrite windows things?
If yes, I would suggest to release this one patch without *any* of the
changes I did last week, because I hope, that this release would need no
changes.
Can you update the changelog.xml so we can see what
has
Henri Gomez wrote:
I'll make a build on our Linux PPC box and make some tests.
Stay tuned
BTW, a windows binary will be usefull also
I'll made them later today.
Rainer,
can you make some tomcat-connectors-1.2.19-dev.tar.gz?
Regards,
Mladen.
Rainer Jung wrote:
I don't want to make it available under /dev/dist, since it's a little
early. If a couple of people give a little feedback, I would feel more
comfortable.
You can put tarball inside your http://people.apache.org/~rjung/
It's much easier to handle tarball then doing svn
Henri Gomez wrote:
BTW, a windows binary will be usefull also
http://people.apache.org/~mturk/jk1219/
Done some bug fixes to be able to compile,
so they are in sync with trunk.
Regards,
Mladen.
-
To unsubscribe, e-mail:
Rainer Jung wrote:
Hi all,
Mladen and I applied some minor but partly important fixes. The result
is available from trunk, but also as a tarball from
http://people.apache.org/~rjung/mod_jk-1.2.19-438031/
There is one problem(?) with apache 1.3/Win32.
With Apache 1.3.34 logging is fine, but
Mark Thomas wrote:
URL: http://svn.apache.org/viewvc?rev=438898view=rev
Log:
I'm not an native English speaker, but the
'Changes with' compared with 'Changes in' or
'Changes from' sound more reasonable to me.
As a native speaker - at least of the British version ;) - Changes
in is the best of
Yoav Shapira wrote:
Hey,
We need to submit a quarterly report to the Board this month.
+1
I would like to copy the connectors/jni to tc6.0.x/native
that is already present as the placeholder.
Well, except the java part, cause it is within
tc6.0.x/java/org/apache/tomcat/jni already.
Further
Anyone has any idea why /examples or /examples/ returns 404
while we have /examples listed under Miscellaneous?
IMHO it should show the directory listing like on 4.1.x.
The /examples/jsp and examples/servlets works however.
Regards,
Mladen.
Filip Hanik - Dev Lists wrote:
With a recent fix to APR, I'd like to move forward to 5.5.19 and skip
5.5.18. One of the reasons we wanted 5.5.18 was because of an APR fix,
now when it is completed, we can get that and the rest of the stuff into
it.
If I don't hear any objections, I'll tag
Remy Maucherat wrote:
the other option is of course to roll back the listener back to 1.1.3
Yes, it's either actually release the new native source bundle, or
rollback the listener. IMO, it's better to rollback, since I am not
aware of any API breakage, and I think the listener should
Filip Hanik - Dev Lists wrote:
You should do a 1.1.4 release here, though:
http://www.apache.org/dist/tomcat/tomcat-connectors/native/
are the native releases never voted on?
No. They are part of Tomcat tags although we have version to be
loosely coupled. We don't have a separate product
Filip Hanik - Dev Lists wrote:
Ok, with the latest mishap of the native versions, we'll make another
attempt.
I will tag 5.5.20 on Monday, 4pm CST (22.00 GMT)
OK. I'll try to refactor the APR listener
so it uses the 'minimum API' (1.1.3) version without
breaking, and issuing a note if the
Remy Maucherat wrote:
OK. I'll try to refactor the APR listener
so it uses the 'minimum API' (1.1.3) version without
breaking, and issuing a note if the version
is less then 'recommended' (1.1.4).
This is useless (and possibly even dangerous) because the recommended
version may change in the
Remy Maucherat wrote:
I still don't see much usefulness. 1.1.4 doesn't contain any serious
fixes over 1.1.3, but causes a warning.
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jni/native/src/network.c?r1=412388r2=415547diff_format=h
It doesn't set/restore the timeout for each socket
Filip Hanik - Dev Lists wrote:
Don't see what's the problem with something like that.
Regards,
Mladen.
I'm against such change to, not because of usefulness or not, we're
trying to cut a stable release, if you want to do it, do for the next
tomcat release.
Then use 1.1.4 if you wish a
Hi,
Seems we had a pretty long test window.
Can we schedule the release by the end of this week?
Rainer, are you still willing to act as the RM for 1.2.19?
Regards,
Mladen.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For
David Rees wrote:
Ok, I'm pretty sure this is a real bug (though not a new one, mod_jk
back to 1.2.15 behaves the same).
This not an bug.
I'm using this config in Apache:
JkMount /*.jsp tomcatlb
LocationMatch /.*;jsessionid=.*
JkMount tomcatlb
/LocationMatch
Have you tried?
David Rees wrote:
Have you tried?
LocationMatch /.*;jsessionid=.*
SetHandler jakarta-servlet
/LocationMatch
The worker used will be the first one in
worker.list if you explicitly set the handler.
So what do you do when you have multiple virtualhosts mapped to
different workers?
Please
Rainer Jung wrote:
Hi,
The source distribution can be downloaded from:
http://tomcat.apache.org/dev/dist/tomcat-connectors/jk/source/jk-1.2.19/
The binaries are at:
http://www.apache.org/dist/tomcat/tomcat-connectors/jk/binaries/win32/jk-1.2.19/
Peter Huber wrote:
Hi y'all
Recently I was assigned to the following task:
But the Problem is that it does not work from arbitrary client. I tracked
down the problem: It is a hardcoded limit of 8 KB transmission buffer both
in isapi_redirect.dll and in the AJP 1.3 protocol implementation.
Peter Huber wrote:
Thanks for the quick response. Is there any release date fixed for the
components?
http://people.apache.org/~fhanik/v5.5.20-beta/bin/
http://www.apache.org/dist/tomcat/tomcat-connectors/jk/binaries/win32/jk-1.2.19/
The VOTE is in progress, so next thought.
Regards,
On 02/28/2010 11:18 PM, Rainer Jung wrote:
On 27.02.2010 12:14, Mladen Turk wrote:
Apache Tomcat Connectors 1.2.30 is:
[X] Stable - no major issues, no regressions
[ ] Beta - at least one significant issue -- tell us what it is
[ ] Alpha - multiple significant issues -- tell us what
On 02/27/2010 12:14 PM, Mladen Turk wrote:
With my vote
Apache Tomcat Connectors 1.2.30 is:
[X] Stable - no major issues, no regressions
we have collected required three binding votes
so I'll proceed with copying to dist and
making announcement.
Regards
--
^TM
On 02/27/2010 01:02 PM, Konstantin Kolinko wrote:
If withdrawing needs a vote, here is my +1.
We have collected required three binding votes
so I'll proceed and remove 1.2.29 from dist and arch,
update the site and make a notice of that with
1.2.30 announcement
Regards
--
^TM
On 02/28/2010 11:57 PM, Rainer Jung wrote:
One addition: the combination of the a+c mode and fflush() shows the
problem. As soon as I remove one of the two, perforemance is fine.
What 'c' flag does is to actually call _commit (FlushFileBuffers)
on fflush(). Without that the fflush is called
The Apache Tomcat team announces the immediate availability of
Apache Tomcat Connectors 1.2.30 stable.
Apache Tomcat Connectors 1.2.30 concentrates mainly on bug fixes.
Please refer to the change log for the list of changes:
http://tomcat.apache.org/connectors-doc/miscellaneous/changelog.html
On 02/24/2010 11:56 AM, jean-frederic clere wrote:
The candidates binaries are available here:
http://people.apache.org/~jfclere/tomcat-6/v6.0.25/
If the release is postponed I'd like to add the
legacy renegotiation support from trunk.
It requires tomcat-native 1.2.21 release first
with
Hi,
I backported mod_ssl's SSLInsecureRenegotiation option
and would like to TR 1.2.21 with compiled OpenSSL 0.9.8m
that should fully solve the CVE-2009-3555.
ABI is extended to allow checking the OpenSSL feature
supported, so usage would require 1.2.21.
Comments?
Regards
--
^TM
On 03/02/2010 01:17 PM, Remy Maucherat wrote:
On Tue, 2010-03-02 at 09:19 +, mt...@apache.org wrote:
Author: mturk
Date: Tue Mar 2 09:19:45 2010
New Revision: 917931
URL: http://svn.apache.org/viewvc?rev=917931view=rev
Log:
With unsafe reneg, minimum required is 1.2.21 caused by API
On 03/02/2010 05:43 PM, jean-frederic clere wrote:
On 03/02/2010 09:51 AM, mt...@apache.org wrote:
Author: mturk
Date: Tue Mar 2 08:51:46 2010
New Revision: 917921
URL: http://svn.apache.org/viewvc?rev=917921view=rev
Log:
Add unafe legacy renegotiation support
How does that interacts with
On 03/02/2010 05:58 PM, jean-frederic clere wrote:
How does that interacts with
http://svn.apache.org/viewvc?rev=881179view=rev ?
The same way as in mod_ssl
Yes but won't it be possible to allow client initiated renegotiation
with 0.9.8m?
According to the OpenSSL docs:
If the option
On 03/03/2010 08:33 AM, jean-frederic clere wrote:
Stable [3]
Broken [2]
So we go for a 6.0.26. Please commit the stuff voted in STATUS.txt
And few ones that need votes :)
E.g the trivial exception throwing fix for APR connector on shutdown.
Regards
--
^TM
On 03/02/2010 05:58 PM, jean-frederic clere wrote:
On 03/02/2010 05:47 PM, Mladen Turk wrote:
On 03/02/2010 05:43 PM, jean-frederic clere wrote:
On 03/02/2010 09:51 AM, mt...@apache.org wrote:
Author: mturk
Date: Tue Mar 2 08:51:46 2010
New Revision: 917921
URL: http://svn.apache.org/viewvc
On 03/03/2010 01:19 PM, Mladen Turk wrote:
On 03/02/2010 05:58 PM, jean-frederic clere wrote:
On 03/02/2010 05:47 PM, Mladen Turk wrote:
On 03/02/2010 05:43 PM, jean-frederic clere wrote:
On 03/02/2010 09:51 AM, mt...@apache.org wrote:
Author: mturk
Date: Tue Mar 2 08:51:46 2010
New Revision
On 03/04/2010 12:48 PM, Rainer Jung wrote:
On 02.03.2010 10:14, mt...@apache.org wrote:
Author: mturk
Date: Tue Mar 2 09:14:44 2010
New Revision: 917928
URL: http://svn.apache.org/viewvc?rev=917928view=rev
Log:
Port SSLInsecureRenegotiation from mod_ssl
Modified:
On 03/07/2010 09:17 PM, t...@apache.org wrote:
Author: timw
--- tomcat/jk/trunk/native/apache-2.0/mod_jk.rc (added)
+++ tomcat/jk/trunk/native/apache-2.0/mod_jk.rc Sun Mar 7 20:17:04 2010
@@ -0,0 +1,97 @@
+// Microsoft Visual C++ generated resource script.
+//
Nice but this should be hand
401 - 500 of 1171 matches
Mail list logo
