Re: Time to organise svn - Take 3

[jean-frederic clere]

Mark Thomas wrote:
> Mark Thomas wrote:
>> svn cp
>> https://svn.apache.org/repos/asf/tomcat/tc6.0.x/tags/TOMCAT_6_0_15
>> https://svn.apache.org/repos/asf/tomcat/tc6.1.0/trunk
>>
>> https://svn.apache.org/repos/asf/tomcat/tc6.0.x/tags/TOMCAT_6_0_15
>> https://svn.apache.org/repos/asf/tomcat/trunk
>>
>> Changes to .../trunk with be CTR
>> Changes to .../6.1.x/trunk will be RTC
> 
> As per the previously published plan, I will create tomcat/tc6.1.x/trunk
> and tomcat/trunk from the 6.0.15 tag. I plan to do this sometime on Friday
> afternoon GMT.

Why Friday? Shouldn't we wait until 6.0.15 (or 6.0.15 + n) is voted stable?

Cheers

Jean-Frederic

> Any commits to 6.0.x/trunk between now and then I will apply
> using CTR to trunk.
> 
> Mark
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Time to organise svn - Take 3

[Mark Thomas]

jean-frederic clere wrote:
> Why Friday? Shouldn't we wait until 6.0.15 (or 6.0.15 + n) is voted stable?

We can do if that is the preference. My motivation is that I am keen to get
back to a CTR codebase asap as I find only having RTC a real pain.

Mark


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Time to organise svn - Take 3

[Peter Rossbach]

Good point

+1
Peter


Am 01.11.2007 um 09:51 schrieb jean-frederic clere:


Mark Thomas wrote:

Mark Thomas wrote:

svn cp
https://svn.apache.org/repos/asf/tomcat/tc6.0.x/tags/TOMCAT_6_0_15
https://svn.apache.org/repos/asf/tomcat/tc6.1.0/trunk

https://svn.apache.org/repos/asf/tomcat/tc6.0.x/tags/TOMCAT_6_0_15
https://svn.apache.org/repos/asf/tomcat/trunk

Changes to .../trunk with be CTR
Changes to .../6.1.x/trunk will be RTC


As per the previously published plan, I will create tomcat/tc6.1.x/ 
trunk
and tomcat/trunk from the 6.0.15 tag. I plan to do this sometime  
on Friday

afternoon GMT.


Why Friday? Shouldn't we wait until 6.0.15 (or 6.0.15 + n) is voted  
stable?


Cheers

Jean-Frederic


Any commits to 6.0.x/trunk between now and then I will apply
using CTR to trunk.

Mark


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 43588] - Tomcat uses hardcoded 127.0.0.1 for localhost

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=43588





--- Additional Comments From [EMAIL PROTECTED]  2007-11-01 04:46 ---

(In reply to comment #10)
> (In reply to comment #9)
> Instead of doing a refactor, and if no solution is best, why not just add a 
> new
> property "org.apache.tomcat.localhost.ip" that defaults to "127.0.0.1" that
> whoever starts tomcat is able to override?
> Not an automagic solution, but will address the original issue and will not
> create any new security issues

+1 - That still requires slight refactoring, but it sounds like a worthy idea to
me. ;)



-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Time to organise svn - Take 3

[Filip Hanik - Dev Lists]

Mark Thomas wrote:

jean-frederic clere wrote:
  

Why Friday? Shouldn't we wait until 6.0.15 (or 6.0.15 + n) is voted stable?



We can do if that is the preference. My motivation is that I am keen to get
back to a CTR codebase asap as I find only having RTC a real pain.
  

he he, I think everyone does, however two months ago you said
"I don't see a need for a separate 6.0.x and 6.1.x development at this 
point. I have yet to see a convincing technical argument that there is 
something sufficiently new and/or different to justify this overhead."


has anything changed since before when we had trunk and 6.0.x, to the 
point where we have more resources and more todos to maintain 6.0.x, 
6.1.x and trunk? This is one more branch than we used to have.


wouldn't it be better to hold of on the 6.1.x until there is a feature 
set for that release, and only have trunk. Otherwise we will have two 
6.0.x branches, just one is named 6.1.x but there is nothing different 
with them



Filip

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Time to organise svn - Take 3

[jean-frederic clere]

Filip Hanik - Dev Lists wrote:
> Mark Thomas wrote:
>> jean-frederic clere wrote:
>>  
>>> Why Friday? Shouldn't we wait until 6.0.15 (or 6.0.15 + n) is voted
>>> stable?
>>> 
>>
>> We can do if that is the preference. My motivation is that I am keen
>> to get
>> back to a CTR codebase asap as I find only having RTC a real pain.
>>   
> he he, I think everyone does, however two months ago you said
> "I don't see a need for a separate 6.0.x and 6.1.x development at this
> point. I have yet to see a convincing technical argument that there is
> something sufficiently new and/or different to justify this overhead."
> 
> has anything changed since before when we had trunk and 6.0.x, to the
> point where we have more resources and more todos to maintain 6.0.x,
> 6.1.x and trunk? This is one more branch than we used to have.
> 
> wouldn't it be better to hold of on the 6.1.x until there is a feature
> set for that release, and only have trunk. Otherwise we will have two
> 6.0.x branches, just one is named 6.1.x but there is nothing different
> with them

Yep. I also prefer to have only trunk based on 6.0.15 I don't think we
need 6.1.x for the moment. We should be able to make proposals for
tc6.0.x back porting using commits from trunk for a while.

Additional I think we should also create/prepare a ROADMAP in/for this
trunk to discuss what the new features we want to put inside.

Cheers

Jean-Frederic

> 
> 
> Filip
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: JK 1.2.26 ?

[Rainer Jung]

Hi Mitchell,

my personal schedule suggests fixing the open things in the week
beginning at November, 19th,
and then producing a public testing tarball at the end of that week or
the weekend around November 25. If the tests go fine, this usually means
we'll have a production tarball around Dec. 2, and then a voting period
of about 3 days, after which we officially announce the release.

Needed fixes are especially (just a quick shot):

- broken failover with reply_timeout
- JkEnvVar and virtual hosts
- Empty Virtual hosts (testing)

Any special fix you are interested in?
Would you be able to test a pre relase tarball?

Regards,

Rainer

MARX, MITCHELL, ATTSI schrieb:
>  
> Is there a 1.2.26 release on the horizon? (been 7 of "10 weeks"
> mentioned below) 
> 
> -Original Message-
> From: Rainer Jung [mailto:[EMAIL PROTECTED] 
> Sent: Tuesday, September 11, 2007 11:56 AM
> To: Tomcat Developers List
> Subject: Re: JK 1.2.26 ?
> 
> Henri Gomez wrote:
>> 2007/9/11, Rainer Jung <[EMAIL PROTECTED]>:
>>> Hi Henri,
>>>
>>> 1.2.25 is still pretty young :)
>> Yes
>>
>>> There are 2 new bugs for 1.2.25 that I'm aware of:
>>>
>>> - BZ 43287 (already fixed)
>>> - BZ 43229 (still needs to be fixed, should be fixed in next release)
>>>
>>> Version 1.2.25 is now 1 month old. So a reasonable target release
> date
>>> would be in about 10 weeks?
>>>
>>> Do you have anything special in mind or the need for earlier fixes?
>> Get an up to date release for i5/OS build check :)
> 
> Like
> 
> http://people.apache.org/~rjung/mod_jk-dev/tomcat-connectors-1.2.26-dev-
> 574630-src.tar.gz
> 
> (not a release, but up to date and release like, so should be OK for a 
> build check).
> 
> Regards,
> 
> Rainer

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [Bug 43753] New: - JkEnvVar and Limit of content length HTTP request POST

[Rainer Jung]

Hi Ian,

I didn't have time to go into it, but thanks for the detailed report. We
will fix this before 1.2.26. In case you have a patch to propose,
that'll be a good starting point.

Regards,

Rainer

Ian Ward Comfort schrieb:
> On Oct 23, 2007, at 2:51 AM, Ian Ward Comfort wrote:
>> On Oct 22, 2007, at 11:24 PM, Mladen Turk wrote:
 By adding some additional instrumentation to the code, I can see
 that each AJP packet is constructed with ((1 + 17) * 13) = 234
 envvar attributes -- the whole set of attributes is appended 18
 times in succession.  (Often this overflows the default maximum
 packet size.)
>>>
>>> Can you use JkLogLevel debug and attach the packet dumps as well as
>>> the the config?
> 
>> [1] http://rescomp.stanford.edu/~icomfort/jk/logging.patch
>> [2] http://rescomp.stanford.edu/~icomfort/jk/httpd.conf
>> [3] http://rescomp.stanford.edu/~icomfort/jk/workers.properties
>> [4] http://rescomp.stanford.edu/~icomfort/jk/mod_jk_log
>> [5] http://rescomp.stanford.edu/~icomfort/jk/ajp.dump
> 
> On Oct 31, 2007, at 8:11 AM, [EMAIL PROTECTED] wrote:
>> http://issues.apache.org/bugzilla/show_bug.cgi?id=43753
>>
>>Summary: JkEnvVar and Limit of content length HTTP request
>> POST
>>Product: Tomcat 6
>>Version: 6.0.10
> 
>>  Component: Connectors
>> AssignedTo: [EMAIL PROTECTED]
>> ReportedBy: [EMAIL PROTECTED]
> 
>> In the httpd.conf Apache 2.0, JkEnvVar is assigned to SERVER_NAME
>> When I add a virtualhost with a new ServerName, I have immediately an
>> HTTP error :
>>
>> Error 413 Request entity too large! The POST method does not allow the
>> data transmitted, or the data volume exceeds the capacity limit.
>>
>> I suppose that error is linked to the number of declaration ServerName
>> (60)
> 
> These sound like the same issue to me.  Has anyone had a chance to look
> at the code?
> 
> I could take a stab at a patch quickly, but I'd certainly want someone
> more familiar with the codebase to review it.
> 
> -- 
> Ian Ward Comfort <[EMAIL PROTECTED]>
> System Administrator, Student Computing, Stanford University

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Rebuilding isapi_redirect.dll

[Dan Burton]

Tim - 

One of my colleagues got the build working on his machine.  I still
couldn't get it working on mine, but at least we've got our new DLL now,
which seems to work like a charm.

Thanks for your help.

-Dan

-Original Message-
From: Tim Whittington [mailto:[EMAIL PROTECTED] 
Sent: Sunday, October 28, 2007 15:15
To: 'Tomcat Developers List'
Subject: RE: Rebuilding isapi_redirect.dll

The errors you're getting are classic Runtime Library mismatches -
everything you're linking together needs to be compiled with the same
setting (you've got the right location).
If you're getting these errors in a single project (e.g. with no other
libraries etc.), then you need to do a Clean/Rebuild to clean out the
object files compiled with the old setting.

If you're still getting problems, seek help from the one of the VC
newsgroups.

The project I provided builds out of the box on a clean machine with
VC2005, so if it's failing for you it may be something wrong with your
environment (I couldn't begin to guess what that is though).

The VC runtime re-distributable files are usually in your VC install
directory (something like C:\Program Files\Microsoft Visual Studio
8\VC\redist), and a quick Google should locate the installers for them.

tim 

-Original Message-
From: Dan Burton [mailto:[EMAIL PROTECTED] 
Sent: Sunday, 28 October 2007 10:36 a.m.
To: Tomcat Developers List; [EMAIL PROTECTED]
Subject: RE: Rebuilding isapi_redirect.dll

Tim -

Thanks very much for the response and the project file.  Unfortunately,
this doesn't seem to get me any further.  The DLL that gets built
behaves
the same as the one I was building before.  Are you referring to the
settings under project properties -> Configuration Properties -> C/C++
->
Code Generation -> Runtime Library? It's set to "Multi-threaded Debug
DLL
(/MDd)".  Is that right?  I also tried setting it to just
"Multi-threaded
(/MT)", but then I see the following errors when I try to build:

1>MSVCRTD.lib(MSVCR80D.dll) : error LNK2005: _memmove already defined in
LIBCMT.lib(memmove.obj)
1>MSVCRTD.lib(MSVCR80D.dll) : error LNK2005: _strncmp already defined in
LIBCMT.lib(strncmp.obj)

Also, not sure if this is related, but I also see the following warning
(even when the build succeeds):

3>LINK : warning LNK4098: defaultlib 'MSVCRTD' conflicts with use of
other libs; use /NODEFAULTLIB:library

I tried setting this via the project properties under Configuration
Properties -> Linker -> Input -> Ignore Specific Library = "library",
but
I still see the warning.  The command line as shown in the properties
panel shows /NODEFAULTLIB:"library" (with the quotes).
Should that matter?

Would another course be to install the VC8 runtime you mentioned on the
IIS server machine?  How would I go about doing that?  I apologize in
advance if this is a dumb question.  I'm mostly a Java guy, and have
very
little experience building things with Visual Studio.

Also, I've noticed that even with the release version of the DLL, even
though I'm setting the log level to 'debug' or 'trace', it only
generates
a log file when it has a problem loading the workers.properties file
(e.g.
when I intentionally point it to the wrong path).  It doesn't generate a
log file at all when things are running normally.  It behaves this way
whether I use the registry keys for the bootstrap config or if I use the
isapi_redirect.properties file.  I was hoping I might be able to get
some
more info about what's going wrong through the log, but my built version
of the DLL doesn't log anything regardless of the configuration.

Thanks again for any help,

-Dan

-Original Message-
From: Tim Whittington [mailto:[EMAIL PROTECTED]
Sent: Saturday, October 27, 2007 01:38
To: 'Tomcat Developers List'
Subject: RE: Rebuilding isapi_redirect.dll

The errors sound like what you get when you build with VC2005 with the
DLL
C runtime, but don't install the VC8 runtime on the IIS server.
Changing your runtime settings (to Multithread) should fix that.

I've attached the project I use to build the ISAPI DLL - it might help.

tim

-Original Message-
From: Dan Burton [mailto:[EMAIL PROTECTED]
Sent: Saturday, 27 October 2007 9:35 a.m.
To: dev@tomcat.apache.org
Subject: Rebuilding isapi_redirect.dll

Hi all,

 

We've run into the issue as described in this bug:
http://issues.apache.org/bugzilla/show_bug.cgi?id=42003  I'm trying to
rebuild the dll myself using Visual Studio to incorporate this change,
but
the dll I build doesn't seem to work at all when I use it in IIS (all
users just get a 500 error instead of actually making it through into
the
app hosted in Tomcat).  We've got the 1.2.25 release version of the dll
in
there now, and it works fine (except for this bug, which affects users
who
have inordinately many group memberships).

 

Also, I can't figure out how to get the Visual Studio project to build a
'release' version, as opposed to a 'debug' version, and as a result, my
dll is about twice the size of th

RE: JK 1.2.26 ?

[Dan Burton]

Rainer - 

This bug in the AJP protocol / isapi_redirect.dll is one we had to roll
our own patch for recently, and it looks like it might have gotten left
behind under the "Tomcat 5" product.

http://issues.apache.org/bugzilla/show_bug.cgi?id=42003

This should be a relatively small but impactful change, and if it could
get taken care of for a 1.2.26 release, that would be fantastic.

The necessary code changes are in a comment on the issue, but I don't
have enough C mojo to conjure proper unit tests for the fix.  Also, as
I'm new to this community, I'm not too familiar with the process for
making fixes like this.  I'm happy to help out in whatever way makes
sense.  In particular, I can test out a pre-release version of the DLL
in our environment (as we have particular cases where this bug rears its
head), if that's helpful.

Thanks,

-Dan


-Original Message-
From: Rainer Jung [mailto:[EMAIL PROTECTED] 
Sent: Thursday, November 01, 2007 09:30
To: Tomcat Developers List
Subject: Re: JK 1.2.26 ?

Hi Mitchell,

my personal schedule suggests fixing the open things in the week
beginning at November, 19th,
and then producing a public testing tarball at the end of that week or
the weekend around November 25. If the tests go fine, this usually means
we'll have a production tarball around Dec. 2, and then a voting period
of about 3 days, after which we officially announce the release.

Needed fixes are especially (just a quick shot):

- broken failover with reply_timeout
- JkEnvVar and virtual hosts
- Empty Virtual hosts (testing)

Any special fix you are interested in?
Would you be able to test a pre relase tarball?

Regards,

Rainer

MARX, MITCHELL, ATTSI schrieb:
>  
> Is there a 1.2.26 release on the horizon? (been 7 of "10 weeks"
> mentioned below) 
> 
> -Original Message-
> From: Rainer Jung [mailto:[EMAIL PROTECTED] 
> Sent: Tuesday, September 11, 2007 11:56 AM
> To: Tomcat Developers List
> Subject: Re: JK 1.2.26 ?
> 
> Henri Gomez wrote:
>> 2007/9/11, Rainer Jung <[EMAIL PROTECTED]>:
>>> Hi Henri,
>>>
>>> 1.2.25 is still pretty young :)
>> Yes
>>
>>> There are 2 new bugs for 1.2.25 that I'm aware of:
>>>
>>> - BZ 43287 (already fixed)
>>> - BZ 43229 (still needs to be fixed, should be fixed in next
release)
>>>
>>> Version 1.2.25 is now 1 month old. So a reasonable target release
> date
>>> would be in about 10 weeks?
>>>
>>> Do you have anything special in mind or the need for earlier fixes?
>> Get an up to date release for i5/OS build check :)
> 
> Like
> 
>
http://people.apache.org/~rjung/mod_jk-dev/tomcat-connectors-1.2.26-dev-
> 574630-src.tar.gz
> 
> (not a release, but up to date and release like, so should be OK for a

> build check).
> 
> Regards,
> 
> Rainer

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: New tag

[Rainer Jung]

Hi Peter,

did you read pages from inside the download files, or only follow the
link on the automatically generated download page?

The latter link points to the public Tomcat docs, so always will show
the latest released docs.

Inside the downloads, the changelog looks OK (apart from the missing
committer names for 12 entries (not nice, but not critical), the status
file is indeed totally outdated (already w.r.t. TC 5.5), but that's no
regression.

Regards,

Rainer

Peter Rossbach schrieb:
> Hi,
> 
> I read the status and changelog reference and think the are not reflect
> the 6.0.15 status!
> Peter
> 
> 
> Am 01.11.2007 um 02:58 schrieb Rémy Maucherat:
> 
>> On Mon, 2007-10-29 at 23:26 +0100, Rémy Maucherat wrote:
>>> Hi,
>>>
>>> As the issue list seems relatively empty, I would like to tag 6.0.15
>>> soon, probably late tomorrow.
>>
>> The binaries are available here:
>> http://people.apache.org/~remm/tomcat-6/v6.0.15/
>>
>> Rémy
>>
>>
>>
>> -
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
> 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 43588] - Tomcat uses hardcoded 127.0.0.1 for localhost

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=43588





--- Additional Comments From [EMAIL PROTECTED]  2007-11-01 08:48 ---
(In reply to comment #8)
> InetAddress.getLocalHost().getHostAddress() does not necessarily return 
> localhost - it (can and usually) returns the IP address that other folks can 
> see.
> 
> This means that the shutdown listener by default would listen on a publicly 
> addressable location - which means now ANYONE by default can shutdown tomcat 
> instead of someone who has access to the machine. 
> 

For all the connectors:
The correct way is doing InetAddress.getLocalHost().getHostAddress()
we are not trying to get the IP of "localhost" here, we are trying to just get
one of the interfaces that Tomcat listens to so that we can release the accept
thread. 

What I would suggest, use InetAddress.getLocalHost().getHostAddress() wherever
we need to access a port that is listening on 0.0.0.0, and file a separate
bugzilla item for the other locations

Filip

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Time to organise svn - Take 3

[Rémy Maucherat]

On Thu, 2007-11-01 at 10:03 +, Mark Thomas wrote:
> jean-frederic clere wrote:
> > Why Friday? Shouldn't we wait until 6.0.15 (or 6.0.15 + n) is voted
> stable?
> 
> We can do if that is the preference. My motivation is that I am keen
> to get
> back to a CTR codebase asap as I find only having RTC a real pain.

Yes, this is why I had proposed less stringent process, inspired from
but not equivalent to the one from httpd (then my vote got hijacked).

Rémy



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 43647] - Content-Type changes unexpectedly from text/html to text/plain

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=43647


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED




--- Additional Comments From [EMAIL PROTECTED]  2007-11-01 10:45 ---
we checked out the latest build from svn, installed it and the problem appears
to be resolved.  thanks for the help everyone.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 43647] - Content-Type changes unexpectedly from text/html to text/plain

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=43647





--- Additional Comments From [EMAIL PROTECTED]  2007-11-01 11:09 ---
Oliver: any chance you can check, if this solution fixes your problem as well.
>From the comments here i'm not totally convinced, that your problem and Dave's
are the same.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Time to organise svn - Take 3

[William A. Rowe, Jr.]

jean-frederic clere wrote:

Mark Thomas wrote:

Mark Thomas wrote:

svn cp
https://svn.apache.org/repos/asf/tomcat/tc6.0.x/tags/TOMCAT_6_0_15
https://svn.apache.org/repos/asf/tomcat/tc6.1.0/trunk

https://svn.apache.org/repos/asf/tomcat/tc6.0.x/tags/TOMCAT_6_0_15
https://svn.apache.org/repos/asf/tomcat/trunk

Changes to .../trunk with be CTR
Changes to .../6.1.x/trunk will be RTC

As per the previously published plan, I will create tomcat/tc6.1.x/trunk
and tomcat/trunk from the 6.0.15 tag. I plan to do this sometime on Friday
afternoon GMT.


Why Friday? Shouldn't we wait until 6.0.15 (or 6.0.15 + n) is voted stable?


Contrawise, why wait, and why a tag?  Usually most efforts (in order to
preserve history) branch from trunk or branches, whereas tags/* reflect
an endpoint (end of history).  Simply branch from 6.0.x unless there are
dirty secrets buried in there :)

Bill

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

HTTPS from remote client

[banderson]

I have a self-signed certificate (generated with keytool -genkey -alias
tomcat -keyalg RSA) and modified my server.xml file to uncomment the
connector on port 8443.  After restarting tomcat, I can access
https://localhost:8443 no problem, but when I try to reach it from a remote
computer, it times out.  Please let me know what I am missing.
-- 
View this message in context: 
http://www.nabble.com/HTTPS-from-remote-client-tf4733722.html#a13536181
Sent from the Tomcat - Dev mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 43775] New: - The tomcat6.exe in source download in tar.gz is broken (ok in zip)

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=43775

   Summary: The tomcat6.exe in source download in tar.gz is broken
(ok in zip)
   Product: Tomcat 6
   Version: 6.0.14
  Platform: Other
   URL: http://tomcat.apache.org
OS/Version: Linux
Status: NEW
  Severity: normal
  Priority: P2
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Hi,

I observed that following files in the source download apache-tomcat-6.0.14-
src.tar.gz 

   apache-tomcat-6.0.14-src/res/procrun/tomcat6.exe
   apache-tomcat-6.0.14-src/res/procrun/tomcat6w.exe

do not work.  However, the same files in apache-tomcat-6.0.14-src.zip do work 
properly.

On Linux I expended the zip file in apache-tomcat-6.0.14-src-zip and tar.gz in 
apache-tomcat-6.0.14-src then diffed the content:

bash-3.1$ diff -bBr --brief apache-tomcat-6.0.14-src apache-tomcat-6.0.14-src-
zip
Files apache-tomcat-6.0.14-src/native/connector/os/win32/logmessages.bin and 
apache-tomcat-6.0.14-src-zip/native/connector/os/win32/logmessages.bin differ
Files apache-tomcat-6.0.14-src/res/procrun/amd64/tomcat6.exe and apache-tomcat-
6.0.14-src-zip/res/procrun/amd64/tomcat6.exe differ
Files apache-tomcat-6.0.14-src/res/procrun/amd64/tomcat6w.exe and apache-
tomcat-6.0.14-src-zip/res/procrun/amd64/tomcat6w.exe differ
Files apache-tomcat-6.0.14-src/res/procrun/ia64/tomcat6.exe and apache-tomcat-
6.0.14-src-zip/res/procrun/ia64/tomcat6.exe differ
Files apache-tomcat-6.0.14-src/res/procrun/ia64/tomcat6w.exe and apache-tomcat-
6.0.14-src-zip/res/procrun/ia64/tomcat6w.exe differ
Files apache-tomcat-6.0.14-src/res/procrun/tomcat6.exe and apache-tomcat-
6.0.14-src-zip/res/procrun/tomcat6.exe differ
Files apache-tomcat-6.0.14-src/res/procrun/tomcat6w.exe and apache-tomcat-
6.0.14-src-zip/res/procrun/tomcat6w.exe differ
Files apache-tomcat-6.0.14-
src/webapps/docs/architecture/requestProcess/requestProcess.pdf and apache-
tomcat-6.0.14-src-
zip/webapps/docs/architecture/requestProcess/requestProcess.pdf differ
Files apache-tomcat-6.0.14-
src/webapps/docs/architecture/startup/serverStartup.pdf and apache-tomcat-
6.0.14-src-zip/webapps/docs/architecture/startup/serverStartup.pdf differ
Files apache-tomcat-6.0.14-src/webapps/docs/tribes/leader-election-initiate-
election.dia and apache-tomcat-6.0.14-src-zip/webapps/docs/tribes/leader-
election-initiate-election.dia differ
Files apache-tomcat-6.0.14-src/webapps/docs/tribes/leader-election-message-
arrives.dia and apache-tomcat-6.0.14-src-zip/webapps/docs/tribes/leader-
election-message-arrives.dia differ

You will also observe that the 2 pdf in the tar.gz will not open without an 
error whereas the same files in the zip will open properly.

I wonder if the problem starts in the dist.xml Ant script 



The exclude list should probably exclude also: pdf and exe (also .dia 
and .bin?)

What do you think?

Kind Regards,
Fred

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Time to organise svn - Take 3

[Filip Hanik - Dev Lists]

William A. Rowe, Jr. wrote:

jean-frederic clere wrote:

Mark Thomas wrote:

Mark Thomas wrote:

svn cp
https://svn.apache.org/repos/asf/tomcat/tc6.0.x/tags/TOMCAT_6_0_15
https://svn.apache.org/repos/asf/tomcat/tc6.1.0/trunk

https://svn.apache.org/repos/asf/tomcat/tc6.0.x/tags/TOMCAT_6_0_15
https://svn.apache.org/repos/asf/tomcat/trunk

Changes to .../trunk with be CTR
Changes to .../6.1.x/trunk will be RTC
As per the previously published plan, I will create 
tomcat/tc6.1.x/trunk
and tomcat/trunk from the 6.0.15 tag. I plan to do this sometime on 
Friday

afternoon GMT.


Why Friday? Shouldn't we wait until 6.0.15 (or 6.0.15 + n) is voted 
stable?


Contrawise, why wait, and why a tag?  Usually most efforts (in order to
preserve history) branch from trunk or branches, whereas tags/* reflect
an endpoint (end of history).  Simply branch from 6.0.x unless there are
dirty secrets buried in there :)
one reason we would wait, is cause there are no ongoing efforts. at 
least none that are documented, and as Mark said two months ago,
"I don't see a need for a separate 6.0.x and 6.1.x development at this 
point. I have yet to see a convincing technical argument that there is 
something sufficiently new and/or different to justify this overhead."


we still haven't documented what this "ongoing effort would be" nor have 
we agreed on it.
From what it sounds like right now, and the technical argument and the 
reason to get a trunk, would be to have more liberty adding in fixes and 
patches,and then have an easier way to propose it back to be a fix in 6.0.


Filip




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [Bug 43753] New: - JkEnvVar and Limit of content length HTTP request POST

[Ian Ward Comfort]

On Nov 1, 2007, at 7:33 AM, Rainer Jung wrote:
I didn't have time to go into it, but thanks for the detailed  
report. We will fix this before 1.2.26.


Great, I'm glad to hear it.


In case you have a patch to propose, that'll be a good starting point.


Here's one attempt at a patch, which fixes the problem in my limited  
testing.  It modifies the code path as little as possible, since all  
I know about the intended behavior is what I've gleaned from a  
cursory audit.


Beware, though, that this patch changes the semantics of the  
was_initialized flag somewhat.  This code sets it for all  
jk_server_conf_t objects, even those for virtual hosts, on whom  
init_jk() is never called.  This should be safe since it seems that  
the only other use of the flag is to check whether wc_close() must be  
run, and I think that function is (must be?) idempotent.


Even if this is all correct, it might be better to add another flag  
to jk_server_conf_t to indicate that environment-variable and options  
initialization has occurred.


--- apache-2.0/mod_jk.c 2007-08-02 05:10:48.0 -0700
+++ apache-2.0/mod_jk.c 2007-11-01 17:35:01.0 -0700
@@ -2819,7 +2819,6 @@
 conf = (jk_server_conf_t *)ap_get_module_config(s- 
>module_config,

 &jk_module);
 if (!conf->was_initialized) {
-conf->was_initialized = JK_TRUE;
 /* step through the servers and open each jk logfile
  * and do additional post config initialization.
  */
@@ -2828,7 +2827,8 @@

 &jk_module);

 if (open_jklog(srv, pconf))
 return HTTP_INTERNAL_SERVER_ERROR;
-if (sconf) {
+if (sconf && !sconf->was_initialized) {
+conf->was_initialized = JK_TRUE;
 sconf->options &= ~sconf->exclude_options;
 if (!uri_worker_map_alloc(&(sconf->uw_map),
   sconf- 
>uri_to_context, sconf->log))


--
Ian Ward Comfort <[EMAIL PROTECTED]>
System Administrator, Student Computing, Stanford University


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

VirtualHost inheritance (was Re: [Bug 43753] ...)

[Ian Ward Comfort]

On Nov 1, 2007, at 8:14 PM, Ian Ward Comfort wrote:
Here's one attempt at a patch, which fixes the problem in my  
limited testing.  It modifies the code path as little as possible,  
since all I know about the intended behavior is what I've gleaned  
from a cursory audit.


In working on this bug I discovered a discrepancy (or perhaps just a  
confusing ambiguity?) between mod_jk's behavior and its documentation  
regarding VirtualHosts.


The docs specify that the default for JkMountCopy is "off", that is,  
that JkMounts from a main server are by default not inherited by its  
child VirtualHosts.  But this is only true if there are mod_jk  
directives within the VirtualHost container -- if there are no such  
directives, JkMounts are inherited and it is as if JkMountCopy were  
"on".  The cause of this behavior is just what was underlying the  
JkEnvVar bug; namely that when a VirtualHost has no mod_jk directives  
then the server_rec objects for the main server and the virtual host  
share a single jk_server_conf_t object.


I don't know if this is intended behavior, or a bug in mod_jk, or  
even a bug in Apache, but something seems amiss.  Thoughts?


--
Ian Ward Comfort <[EMAIL PROTECTED]>
System Administrator, Student Computing, Stanford University


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: VirtualHost inheritance (was Re: [Bug 43753] ...)

[Mladen Turk]

Ian Ward Comfort wrote:


I don't know if this is intended behavior, or a bug in mod_jk, or even a 
bug in Apache, but something seems amiss.  Thoughts?




Your patch won't work.
The real problem is in the initialization for vhosts where
when there is *any* Jk directive the create_jk_config is called
while where there isn't the clone_jk_config is called.

clone_jk_config is bogus, and doesn't behave like it should
(copy only the basic data and no mounts)

Regards,
Mladen

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 43647] - Content-Type changes unexpectedly from text/html to text/plain

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=43647





--- Additional Comments From [EMAIL PROTECTED]  2007-11-02 00:34 ---
Thank all of you for your efforts.

This might sound silly but I'm a little confused about what to build from svn. 
Should I build Tomcat or mod_jk? I would appreciate if someone could paste the 
svn-URL in question. Thank you.

I'm confident I can build from svn and do a test in the next couple days.


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: VirtualHost inheritance (was Re: [Bug 43753] ...)

[Ian Ward Comfort]

On Nov 2, 2007, at 12:44 AM, Ian Ward Comfort wrote:
I can't seem to find the repository location anywhere on the  
connectors page either...


Ah, found it on the Tomcat pages.

--
Ian Ward Comfort <[EMAIL PROTECTED]>
System Administrator, Student Computing, Stanford University


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: VirtualHost inheritance (was Re: [Bug 43753] ...)

[Ian Ward Comfort]

On Nov 2, 2007, at 12:32 AM, Mladen Turk wrote:

Ian Ward Comfort wrote:
I don't know if this is intended behavior, or a bug in mod_jk, or  
even a bug in Apache, but something seems amiss.  Thoughts?


Your patch won't work.


No, not for this larger issue.


The real problem is in the initialization for vhosts where
when there is *any* Jk directive the create_jk_config is called
while where there isn't the clone_jk_config is called.

clone_jk_config is bogus, and doesn't behave like it should
(copy only the basic data and no mounts)


Was this function introduced since 1.2.25?  I don't see  
clone_jk_config anywhere in my source tree.  I can't seem to find the  
repository location anywhere on the connectors page either...


--
Ian Ward Comfort <[EMAIL PROTECTED]>
System Administrator, Student Computing, Stanford University


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: VirtualHost inheritance (was Re: [Bug 43753] ...)

[Ian Ward Comfort]

On Nov 2, 2007, at 12:18 AM, Mladen Turk wrote:

Ian Ward Comfort wrote:
I don't know if this is intended behavior, or a bug in mod_jk, or  
even a bug in Apache, but something seems amiss.  Thoughts?


Right, this is bug indeed.
If there is no Jk... directives the vhost conf is wrongly
configured (seems that merge_jk_config is not evaluated)

I'll check your patch, although it looks suspicious.


I agree. :)

Anyway, even if it doesn't break anything, the patch certainly  
doesn't fix this underlying issue.


--
Ian Ward Comfort <[EMAIL PROTECTED]>
System Administrator, Student Computing, Stanford University


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: VirtualHost inheritance (was Re: [Bug 43753] ...)

[Mladen Turk]

Ian Ward Comfort wrote:


I don't know if this is intended behavior, or a bug in mod_jk, or even a 
bug in Apache, but something seems amiss.  Thoughts?




Right, this is bug indeed.
If there is no Jk... directives the vhost conf is wrongly
configured (seems that merge_jk_config is not evaluated)

I'll check your patch, although it looks suspicious.

Regards,
Mladen

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]