Re: Improving mod_jk URI forwarding

2007-05-20 Thread Mladen Turk
Rainer Jung wrote: Before I answer, let me first ask a question: What's wrong withg my suggestion? Or even better: use the encoding done with mod_proxy_ajp? Because it doesn't solve the real problem. Original URI: /myapp/%252e%252e/otherapp/danger JkMount /myapp/* Apache httpd will corr

Re: Improving mod_jk URI forwarding

2007-05-20 Thread Mladen Turk
Bill Barker wrote: Now the reverse proxy should have the ability to modify the URI (in the sense of mod_rewrite). If we accept, that mod_rewrite in httpd 1.3-2.2 is only able to operate on the decoded URI, we have no chance of making this interoperable with forwarding the original undecoded U

Re: Announcing releases of tomcat native

2007-05-23 Thread Mladen Turk
Yoav Shapira wrote: Hi, On 5/22/07, William L. Thomson Jr. <[EMAIL PROTECTED]> wrote: If possible when new versions of Tomcat native be announced on list? Seems Tomcat 6.0.13 requires 1.1.10. First I became aware of it, was when user reported the problem. Granted I should have discovered it bef

Re: Announcing releases of tomcat native

2007-05-23 Thread Mladen Turk
William L. Thomson Jr. wrote: On Wed, 2007-05-23 at 13:19 +0200, Mladen Turk wrote: For 6.0.13 the required version is 1.1.8 and recommended is 1.1.10 and that is clearly printed whenever Tomcat is started. I'm not sure what more is needed. According to the bug report, it required 1.1.10

Automatic detection of CPU/JVM for Win32/Win64

2007-05-24 Thread Mladen Turk
Hi, I've committed to the trunk the modified service.bat that automatically detects the host CPU (x86, amd64, ia64) and whether the JVM is 64 bit or not. So it automatically picks tomcat6.exe, amd64/tomcat6.exe depending on the above rules. However it requires that the .zip distro contains those

Re: mod_jk build: threading detection broken

2007-05-30 Thread Mladen Turk
Rainer Jung wrote: I suggest, that we build against httpd 2.x always thread-safe, at least unless the existing flag -enable-prefork is used and document this behaviour. +1 Regards, Mladen. - To unsubscribe, e-mail: [EMA

Re: svn commit: r543419 - /tomcat/connectors/trunk/jk/native/common/jk_util.c

2007-06-01 Thread Mladen Turk
[EMAIL PROTECTED] wrote: Correct pthread_t casting in jk_gettid(). Needed at least on Mac OS X, shouldn't hurt on other platforms. -int tid = (int)(t & 0x); +int tid = ((int)t) & 0x; Since thread id is a pointer, think it can even be rounded to the sizeof t Something like ((int

Re: svn commit: r544137 - /tomcat/connectors/trunk/jk/native/common/jk_uri_worker_map.c

2007-06-04 Thread Mladen Turk
Jean-Frederic wrote: On Mon, 2007-06-04 at 12:08 +, [EMAIL PROTECTED] wrote: Author: mturk Date: Mon Jun 4 05:08:33 2007 New Revision: 544137 URL: http://svn.apache.org/viewvc?view=rev&rev=544137 Log: Add simple URI normalizer that can deal with things like %252e%252e. This is mostly copy

Re: svn commit: r544137 - /tomcat/connectors/trunk/jk/native/common/jk_uri_worker_map.c

2007-06-04 Thread Mladen Turk
William A. Rowe, Jr. wrote: [EMAIL PROTECTED] wrote: Author: mturk Date: Mon Jun 4 05:08:33 2007 New Revision: 544137 URL: http://svn.apache.org/viewvc?view=rev&rev=544137 Log: Add simple URI normalizer that can deal with things like %252e%252e. This is mostly copy/paste from the IIS module

Re: svn commit: r544137 - /tomcat/connectors/trunk/jk/native/common/jk_uri_worker_map.c

2007-06-05 Thread Mladen Turk
Mark Thomas wrote: >> mod_jk 1.2.23 (with default passing r->unparsed_uri) will return 404 >> from Tomcat becasue it will pass the original uri, not the one Httpd >> already unfolded) > This is correct and provides consistent behaviour for direct to Tomcat > access and access via mod_jk. > It is

Re: svn commit: r544137 - /tomcat/connectors/trunk/jk/native/common/jk_uri_worker_map.c

2007-06-06 Thread Mladen Turk
Mark Thomas wrote: Did I mention that uri is *not* decoded twice? You did and I still don't agree. The root cause of CVE-2007-1860 was a double decoding. Once in httpd/mod_jk and once in Tomcat. Why do you don't agree? Please provide a use case and confirm your statements are legitimate.

Re: svn commit: r544137 - /tomcat/connectors/trunk/jk/native/common/jk_uri_worker_map.c

2007-06-06 Thread Mladen Turk
Remy Maucherat wrote: Mark Thomas wrote: As I see it, we have two options: a) Prevent Tomcat from decoding the uri a second time at step 7 above b) Re-encode the uri in mod_jk between steps 5 and 6 I think: - it's the proxy which should have options for adapting to what the proxied server do

Re: svn commit: r544137 - /tomcat/connectors/trunk/jk/native/common/jk_uri_worker_map.c

2007-06-06 Thread Mladen Turk
Mark Thomas wrote: Single ajp13 worker jkMount /jsp-examples/* worker1 A simple 'hello world' html file was created at (directories created where required): /jsp-examples/%2e%2e/servlets-examples/index.html Test 1: Tomcat only http://localhost:8080/jsp-examples/%252e%252e/servlets-examples/i

Re: svn commit: r546531 - in /tomcat/connectors/trunk/jk/native: apache-1.3/mod_jk.c apache-2.0/mod_jk.c common/jk_global.h common/jk_url.c common/jk_url.h common/list.mk.in

2007-06-12 Thread Mladen Turk
Jean-Frederic wrote: >>> Add ForwardURIProxy to the URl handling option. >>> common/jk_url.c is just a porting of the routines >>> from proxy_util.c (Apache httpd). >> After quite a few discussions, I think this should be the only mode available for URI handling, as the two others are broken. >>

Re: svn commit: r546531 - in /tomcat/connectors/trunk/jk/native: apache-1.3/mod_jk.c apache-2.0/mod_jk.c common/jk_global.h common/jk_url.c common/jk_url.h common/list.mk.in

2007-06-13 Thread Mladen Turk
Remy Maucherat wrote: Mladen Turk wrote: Why? Let's stop a bit and test things before. Jean-Frédéric proposes implementing the same behavior as mod_proxy, so I don't see how this can be a bad thing. First of all I didn't said it's a bad thing or anything like that. We ne

Re: JK3 roadmap?

2007-06-27 Thread Mladen Turk
jean-frederic clere wrote: I have noted that nothing has happened in tomcat/connectors/trunk/jk3. Nearly 2 months without real road map nor clear specifications, what is wrong? I don't think anything is wrong. We are waiting for the list of requirements, and any suggestion from yours or anyb

Re: svn commit: r550789 - /tomcat/connectors/trunk/jk/native/common/jk_lb_worker.c

2007-06-28 Thread Mladen Turk
Remy Maucherat wrote: Remy Maucherat wrote: [EMAIL PROTECTED] wrote: Author: mturk Date: Tue Jun 26 05:28:00 2007 New Revision: 550789 URL: http://svn.apache.org/viewvc?view=rev&rev=550789 Log: Do not pass session id if it is zero length. For now only log those attempts. We should consider re

Re: svn commit: r551809 - /tomcat/connectors/trunk/jk/native/common/jk_msg_buff.c

2007-06-29 Thread Mladen Turk
jean-frederic clere wrote: /* We checked for space !! */ -strncpy((char *)msg->buf + msg->len, param, len + 1); /* including \0 */ +memcpy(msg->buf + msg->len, param, len + 1); /* including \0 */ Why do you remove the (char *)? Cause memcpy uses void* so no need for cas

Re: Feature request /Discussion: JK loadbalancer improvements for high load

2007-07-05 Thread Mladen Turk
Yefym Dmukh wrote: Actually the following was happening: the LB sends requests and gets the session sticky, continuously sending the upcoming requests to the same cluster node. At the certain period of time the JVM started the major garbage collection (full gc) and spent, mentioned above, 20

Re: Feature request /Discussion: JK loadbalancer improvements for high load

2007-07-05 Thread Mladen Turk
Yefym Dmukh wrote: Actually the following was happening: the LB sends requests and gets the session sticky, continuously sending the upcoming requests to the same cluster node. At the certain period of time the JVM started the major garbage collection (full gc) and spent, mentioned above, 20

Re: Feature request /Discussion: JK loadbalancer improvements for high load

2007-07-05 Thread Mladen Turk
Yefym Dmukh wrote: You have oxymoron here. With session stickiness you are willingly tear down the load balancer correctness because you don't wish/can have session replication. Generally you are right, but the ideal world is not the reality: we use apache my faces implementation of jsf where t

Re: Removing the examples (JSP/servlet) in TC Binaries

2007-07-09 Thread Mladen Turk
jean-frederic clere wrote: Hi, The examples (servlet and JSP) have caused a list of security issues. I think we should remove them from the Tomcat binary packages (6.0 and 5.x at least). Any comments? If the examples are broken, then we have serious problems, either with examples or with th

Re: Tomcat supporting PHP

2007-07-16 Thread Mladen Turk
Joe Nathan wrote: Henri Gomez wrote: Do you want a 100% Java PHP engine or just a simple native to Java bridge ? I mean PHP scripts are processed as JSP are handled inside Tomcat without installing any other things as built-in features. Imagine if Tomcat can handle JSP, PHP, even ASP scrip

Re: Tagging JK 1.2.24

2007-07-27 Thread Mladen Turk
+1 Rainer Jung wrote: Hi, we had exactly 10 downloads of our quality check tarball since the announcement yesterday. Three of the testers reported back positively (one of them via direct mail), no reports were negative. Since I received already a lot of positive feedback from the preceding

Re: [VOTE] Releasing Tomcat Connectors 1.2.24

2007-07-27 Thread Mladen Turk
Apache Tomcat Connectors 1.2.24 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 Regards, Mladen --

Serious regression in JK 1.2.24

2007-08-01 Thread Mladen Turk
Hi, We have a problem with 1.2.24 that luckily is not security leak, but it is security related. The problem is that 401 from Tomcat without body (a standard HTTP_UNAUTHORIZED) is treated as 401, meaning that Apache is returning 401 page instead passing 401 to the client. I already patched the

Re: svn commit: r562022 - in /tomcat/connectors/trunk/jk: native/apache-1.3/mod_jk.c native/apache-2.0/mod_jk.c xdocs/miscellaneous/changelog.xml

2007-08-02 Thread Mladen Turk
Rainer Jung wrote: Hi Mladen, I don't full yunderstand this fix. From your other mail i though it's a regression, but the code in this region is the same at least since 1.2.18 (more than a year). So I have the impression, that this is not a regression. You can try 1.2.23 (it works). 1.2.24

Re: svn commit: r562022 - in /tomcat/connectors/trunk/jk: native/apache-1.3/mod_jk.c native/apache-2.0/mod_jk.c xdocs/miscellaneous/changelog.xml

2007-08-02 Thread Mladen Turk
Rainer Jung wrote: OK, I'll go into it. I think I would propose a slightly different patch, but I'll investigate, why 23 and 24 are different. The reason why I started to pose querstions is, that I found it a little strange to make an exception for exactly one status code. My impression is:

Re: svn commit: r562090 - in /tomcat/connectors/trunk/jk/native: apache-1.3/mod_jk.c apache-2.0/mod_jk.c

2007-08-02 Thread Mladen Turk
[EMAIL PROTECTED] wrote: Author: rjung Date: Thu Aug 2 05:10:48 2007 New Revision: 562090 URL: http://svn.apache.org/viewvc?view=rev&rev=562090 Log: Revert the quickfix r562022. It looks like we found the real problem with r562085. Perfect. The fix makes login working once again. Regards, M

Re: mod_jk 1.2.24 withdrawal?

2007-08-02 Thread Mladen Turk
although it doesn't use it. More generally, we need to check which way we should use shm for nsapi on which platform. I think the nsapi and general platforms considerations should not be done before 1.2.25, but everything else looks OK to me. Regards, Rainer Mladen Turk wrote: [EMAIL PROTE

Re: [VOTE] Releasing Tomcat Connectors 1.2.25

2007-08-07 Thread Mladen Turk
Rainer Jung wrote: Apache Tomcat Connectors 1.2.25 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 --

Re: svn commit: r571006 - /tomcat/connectors/trunk/ajp/

2007-08-29 Thread Mladen Turk
[EMAIL PROTECTED] wrote: Author: markt Date: Wed Aug 29 18:14:11 2007 New Revision: 571006 URL: http://svn.apache.org/viewvc?rev=571006&view=rev Log: Remove source for mod_proxy_ajp that moved to httpd some time ago. Why the hell did you do that? You could copy it to some sandbox or something

Re: svn commit: r571006 - /tomcat/connectors/trunk/ajp/

2007-08-29 Thread Mladen Turk
William A. Rowe, Jr. wrote: Mladen Turk wrote: You could copy it to some sandbox or something, since there is lots of usable code in there like console mode httpd API client for testing modules, etc. It's trivial to svn cp -r 571005 https://svn.apache.org/repos/asf/tomcat/connectors/trun

Re: svn commit: r571175 - in /tomcat/connectors/trunk/jk: native/common/jk_ajp_common.c xdocs/miscellaneous/changelog.xml

2007-08-30 Thread Mladen Turk
[EMAIL PROTECTED] wrote: Match header names exactly against pre defined constants. p += 6; -if (memcmp(p, "CHARSET", 7) == 0) +if (strcmp(p, "CHARSET") == 0) Someone would say that this is over engineering :) memcmp *is always* faster

Re: svn commit: r571175 - in /tomcat/connectors/trunk/jk: native/common/jk_ajp_common.c xdocs/miscellaneous/changelog.xml

2007-08-30 Thread Mladen Turk
Mladen Turk wrote: [EMAIL PROTECTED] wrote: Match header names exactly against pre defined constants. p += 6; -if (memcmp(p, "CHARSET", 7) == 0) +if (strcmp(p, "CHARSET") == 0) Someone would say that this

Re: svn commit: r571175 - in /tomcat/connectors/trunk/jk: native/common/jk_ajp_common.c xdocs/miscellaneous/changelog.xml

2007-08-30 Thread Mladen Turk
Rainer Jung wrote: No problem, better safe than sorry. Right. It seems I always forget the ingenuity of the users that wish to extent the http spec :) However, I think that we can still use the memcmp with "xxx\0". That would still be faster then figuring out the EOL with strcmp? Regards, Ml

Re: svn commit: r571175 - in /tomcat/connectors/trunk/jk: native/common/jk_ajp_common.c xdocs/miscellaneous/changelog.xml

2007-08-30 Thread Mladen Turk
Rainer Jung wrote: But the header could be shorter than the constant string. So there was a second problem with the old code, we eventually compared potentially uninitialized memory to string constants. Strictly speaking the result was not defined. Sorry, but you get that wrong. At the be

Re: svn commit: r571175 - in /tomcat/connectors/trunk/jk: native/common/jk_ajp_common.c xdocs/miscellaneous/changelog.xml

2007-08-30 Thread Mladen Turk
Rainer Jung wrote: Yes Mladen, I know. But we never really use len :) I know, that we can do it with memcmp, but then you, me or someone else has to add a couple of if(len>=...) before each memcmp(). Go ahead if you like to. Look, we have a local header[16] on which we copy toupper, and th

Re: svn commit: r571175 - in /tomcat/connectors/trunk/jk: native/common/jk_ajp_common.c xdocs/miscellaneous/changelog.xml

2007-08-30 Thread Mladen Turk
Rainer Jung wrote: +/* Always do memcmp including the final \0-termination character. + */ switch (header[0]) { case 'A': -if (memcmp(p, "CCEPT", 5) == 0) { +if (memcmp(p, "CCEPT", 6) == 0) { Right, but like said this should be a >if (m

Re: Connectors cleanup

2007-09-02 Thread Mladen Turk
Mark Thomas wrote: Hi, Following on from my previous over eager attempt to clean up the duplicate code in connectors I would like to propose the following - remove connectors/trunk/ajp/CHANGES - remove connectors/trunk/ajp/proxy - move connectors/trunk/ajp/ajplib to connectors/trunk/ajplib Tho

Draft for September 2007 Board report

2007-09-02 Thread Mladen Turk
ose of the current code inside Tomcat 6 trunk, and the majority of developers have agreed to put the trunk into the sandbox. Community - After last quarter's new committers and PMC members, there were no changes the committership nor PMC membership this time. Mladen Turk was

Re: svn commit: r572181 - in /tomcat/connectors/trunk/jk/native/common: jk_ajp12_worker.c jk_ajp_common.c jk_jni_worker.c jk_status.c

2007-09-02 Thread Mladen Turk
[EMAIL PROTECTED] wrote: Author: rjung Date: Sun Sep 2 15:50:40 2007 New Revision: 572181 URL: http://svn.apache.org/viewvc?rev=572181&view=rev Log: - Document return codes of the service() method for all worker types (lb still missing). Below is for jk_ajp_common.c: - Document return codes o

Re: svn commit: r572181 - in /tomcat/connectors/trunk/jk/native/common: jk_ajp12_worker.c jk_ajp_common.c jk_jni_worker.c jk_status.c

2007-09-03 Thread Mladen Turk
Rainer Jung wrote: Hi Mladen, I'm fine with rolling back and committing in steps. No need to do that. Let's just take more care in the future. It'll be much easier to follow the commits thought. Regards, Mladen - To unsubscr

Re: Connectors cleanup

2007-09-03 Thread Mladen Turk
Mark Thomas wrote: Mladen Turk wrote: I propose we create connectors/sanbox and move the trunk/ajp/* code in there. ajp/proxy code can be removed of course. Could we just move it to tomcat/sandbox as that already exists? We need connectors/sandbox anyway, so IMHO it's a good initial r

Re: [VOTE] Make released versions RTC

2007-09-06 Thread Mladen Turk
Henri Gomez wrote: Well what's the consensus on Java projects, like Xerces, Xalan or Lucene ? It doesn't mater how other project do things. It's irrelevant. We had CTR policy till now and it was working. Now we have a new situation with different developers POVs, and cause of that, this requir

Re: [VOTE] Make released versions RTC

2007-09-06 Thread Mladen Turk
Yoav Shapira wrote: Hi, On 9/6/07, Mladen Turk <[EMAIL PROTECTED]> wrote: Do we need it? Yes, if we wish to survive as a project. It's pain in the ass, I know, but IMHO it's also the only way to get some sense in this chaos. I disagree. I think the current CTR policy has

Re: [VOTE] Make released versions RTC

2007-09-06 Thread Mladen Turk
Remy Maucherat wrote: To give an idea, "tis" could mean: - API changing patches (any protected or above signature change) - code changes in the critical path (for example, code which gets executed on each HTTP request) Fine. - any other commit for which a committer asks for the RTC procedure

Re: Old CVS repository of Tomcat

2007-09-07 Thread Mladen Turk
Beat Fluri wrote: Hi, As a member of the Software Engineering group of the University Zurich, Switzerland, I'm investigating the evolution of software systems. For this, I'd like to use Tomcat as a case study. Unfortunately, our tools are limited to CVS and not yet fully adapted to Subversion

Re: svn commit: r575332 - in /tomcat/tc6.0.x/trunk: java/org/apache/naming/resources/FileDirContext.java webapps/docs/changelog.xml

2007-09-14 Thread Mladen Turk
Bill Barker wrote: Now, I'd prefer that TC is just the Servlet/JSP container that it is meant to be, and not try to add on proprietary features. But that is just me ;). You are not the only one ;) Seems we have lost the clear vision of the project somewhere in the flame wars. It has beco

Re: svn commit: r575332 - in /tomcat/tc6.0.x/trunk: java/org/apache/naming/resources/FileDirContext.java webapps/docs/changelog.xml

2007-09-15 Thread Mladen Turk
Filip Hanik - Dev Lists wrote: Mladen Turk wrote: This simply has to stop. taking trunk away, this turn of events is expected. I wish everyone would have thought of that before we got caught up in the personal, and not what is important, trunk debate. I did, as well others did (I hope

Re: Review model take 2

2007-09-19 Thread Mladen Turk
+1 as well. Seems we have come to some sort of conclusion. (At least the proposal holds the majority of votes) I'll left this tread for a day or two and then create an official proposal draft we can vote on. If thats accepted, I'll create needed documents like STATUS, ROADMAP containing that draf

Re: [VOTE] Back to ASF Basics (Was: Re: Review model take 2)

2007-09-22 Thread Mladen Turk
Jim Jagielski wrote: [X] +1. Yes, the above works and addresses my concerns as well as the problems which started this whole thing. [ ] 0. Whatever. [ ] -1. The above does not work for the following reasons: If voted (and it looks it will) we should put them s

Re: Tomcat Export Notification Requirements

2007-09-25 Thread Mladen Turk
William A. Rowe, Jr. wrote: Hey folks, as you provide the bindings to the JSSE, even though you don't ship the JSSE .jars - we still need Tomcat in compliance with the federal export notification policies. I know you did some work on this in the past, but please see http://www.apache.org/dev/c

Re: Tomcat Export Notification Requirements

2007-09-26 Thread Mladen Turk
William A. Rowe, Jr. wrote: it's sort of a closed loop problem. Update the info, allow the usual one hour after updating from minotaur to sync, and then shoot out the notice referencing the list of notices sent :) Can we get an example email that needs to be send and an email address? The pa

Re: Tomcat Export Notification Requirements

2007-09-26 Thread Mladen Turk
William A. Rowe, Jr. wrote: Mladen Turk wrote: William A. Rowe, Jr. wrote: it's sort of a closed loop problem. Update the info, allow the usual one hour after updating from minotaur to sync, and then shoot out the notice referencing the list of notices sent :) Can we get an example

Re: mod_jk 1.2.25, JkEnvVar evaluated too many times

2007-10-22 Thread Mladen Turk
Ian Ward Comfort wrote: (I've heard this list is a good place to discuss mod_jk code; please redirect me and accept my apologies if it is not.) No, this is correct place :) containers. By adding some additional instrumentation to the code, I can see that each AJP packet is constructed with

Re: tcnative-1 and windows vista pro 32 bits

2007-10-26 Thread Mladen Turk
Henri Gomez wrote: Here is the dump You should know by now that apache mailing doesn't allow large attachments, zip files, etc... :) Put a link somewhere Regards, Mladen - To unsubscribe, e-mail: [EMAIL PROTECTED] For addit

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

2007-11-01 Thread 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 ca

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

2007-11-01 Thread 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)

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

2007-11-02 Thread Mladen Turk
Rainer Jung wrote: Hi, be careful: OK :) I also added an option JkMountCopyAll, OK, but clone is called when there is no "JkMountCopy All" defined if (sconf && sconf->was_initialized == JK_TRUE && jk_mount_copy_all == JK_FALSE) { clone_jk_config So if there is *no* module direct

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

2007-11-02 Thread Mladen Turk
Ian Ward Comfort wrote: 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? Yes, I was talking about trunk not 1.2.25 Regards, Mladen ---

Re: [VOTE] Release build 6.0.15

2007-11-06 Thread Mladen Turk
According to the release process, the 6.0.15 tag is: [ ] Broken [ ] Alpha [ ] Beta [X] Stable Thumbs up for Linux, win32 and win64! Regards, Mladen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail:

Re: svn commit: r593943 - /tomcat/connectors/trunk/jk/native/apache-2.0/mod_jk.c

2007-11-11 Thread Mladen Turk
[EMAIL PROTECTED] wrote: Author: rjung Date: Sun Nov 11 11:22:23 2007 New Revision: 593943 URL: http://svn.apache.org/viewvc?rev=593943&view=rev Log: Undo revision 593927. This produced a mem leak for vhosts with private JkMounts. No idea why. Because uw_map is now allocated *only* if uri_to_

Re: svn commit: r593943 - /tomcat/connectors/trunk/jk/native/apache-2.0/mod_jk.c

2007-11-12 Thread Mladen Turk
Rainer Jung wrote: P.S.: I hope the other changes are fine with you? They look OK, but I'll double check, just in case ;) Cheers, Mladen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PR

Re: svn commit: r596747 - /tomcat/connectors/trunk/jk/native/common/jk_util.c

2007-11-20 Thread Mladen Turk
Rainer Jung wrote: But I'm open. If we remove the const, we also need to remove it for the log_fmt (got as compiler warning also there, but don't have the line number at hand). Which would you prefer? Do you see a problem with the const, like wrong compiler optimization or so? Yes, that

Re: svn commit: r596747 - /tomcat/connectors/trunk/jk/native/common/jk_util.c

2007-11-20 Thread Mladen Turk
Mladen Turk wrote: Rainer Jung wrote: But I'm open. If we remove the const, we also need to remove it for the log_fmt (got as compiler warning also there, but don't have the line number at hand). Which would you prefer? Do you see a problem with the const, like wrong compiler op

Re: svn commit: r596747 - /tomcat/connectors/trunk/jk/native/common/jk_util.c

2007-11-20 Thread Mladen Turk
[EMAIL PROTECTED] wrote: Author: rjung Date: Tue Nov 20 09:29:26 2007 New Revision: 596747 URL: http://svn.apache.org/viewvc?rev=596747&view=rev Log: Add comments to explain timestamp formatting for sub seconds resolution. Furthermore increased the accepted format length a bit. Before we accept

Re: svn commit: r596761 - in /tomcat/tc6.0.x/trunk: ./ java/org/apache/catalina/core/ java/org/apache/catalina/startup/ java/org/apache/tomcat/util/net/ res/

2007-11-20 Thread Mladen Turk
[EMAIL PROTECTED] wrote: Author: jim Modified: tomcat/tc6.0.x/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java URL: http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java?rev=596761&r1=596760&r2=596761&view=diff =

Re: Tomcat Monitor Configuration

2007-11-20 Thread Mladen Turk
RafaQuiM wrote: Hello, I'm having problems using the TomcatMonitor (tomcat4w.exe) when trying to access a WinXp net file from a Servlet due to the console uses the SYTEM user (user.name property) as credentials. Does anybody know how to configure tomcatMonitor in order to use the logged user?

Re: FW: Delays in mod_jk

2007-11-28 Thread Mladen Turk
jean-frederic clere wrote: JBPAPP-366 is http://svn.apache.org/viewvc?rev=589062&view=rev that was a bug in the JAVA part not in mod_jk. Right, however the idea to call the Socket.shutdown in a separate thread is very good since it's blocking call. The only problem is how to close bunch of th

Re: A high school student is taking on the task of moving our FAQ to the wiki

2007-11-28 Thread Mladen Turk
Yoav Shapira wrote: Hi, One of the tasks we put out for the Google Highly Open Participation contest (http://code.google.com/opensource/ghop/2007-8/) is Tim's idea, to move our FAQ from static files to the wiki. A student, Gianluca Varisco, is taking on that task. He has just started work. Th

Re: svn commit: r599767 - /tomcat/connectors/trunk/jk/native/common/jk_ajp_common.c

2007-11-30 Thread Mladen Turk
[EMAIL PROTECTED] wrote: Author: rjung Date: Fri Nov 30 02:26:42 2007 New Revision: 599767 URL: http://svn.apache.org/viewvc?rev=599767&view=rev Log: Complete half-baked r599743. Care about signedness and apply reverse order to the relevant loop to. Modified: tomcat/connectors/trunk/jk/nati

Re: svn commit: r599743 - in /tomcat/connectors/trunk/jk: native/common/jk_ajp_common.c xdocs/miscellaneous/changelog.xml

2007-11-30 Thread Mladen Turk
[EMAIL PROTECTED] wrote: Author: rjung Date: Fri Nov 30 00:52:17 2007 New Revision: 599743 URL: http://svn.apache.org/viewvc?rev=599743&view=rev Log: Maintain idle connections in decreasing (LRU) slot order. Modified: tomcat/connectors/trunk/jk/native/common/jk_ajp_common.c tomcat/conne

Re: Fwd: Tomcat Dependency Graph

2007-12-01 Thread Mladen Turk
Sergey Vidyuk wrote: Hi Tomcat Developers! I'm contributor in the Apache Software Foundation's GHOP Contest and working on issue 19(http://code.google.com/p/google-highly-open-participation-asf/issues/detail?id=19) Excellent! I've plan to write scripts that generate tomcat dependency for jar

Re: svn commit: r603400 - /tomcat/connectors/trunk/jk/native/common/jk_connect.c

2007-12-11 Thread Mladen Turk
[EMAIL PROTECTED] wrote: Log: Add function description comments and switch return values of jk_is_socket_connected() from 0/1 to JK_FALSE/JK_TRUE. -return nr == 0 ? 0 : 1; +return nr == JK_FALSE ? JK_FALSE : JK_TRUE; int nr; if (ioctl(sock, FIONREAD,

Re: svn commit: r603637 - /tomcat/connectors/trunk/jk/native/common/jk_ajp_common.c

2007-12-12 Thread Mladen Turk
[EMAIL PROTECTED] wrote: Author: rjung Date: Wed Dec 12 07:10:32 2007 New Revision: 603637 URL: http://svn.apache.org/viewvc?rev=603637&view=rev Log: Slightly rearange ajp_next_connection(). int rc; ajp_worker_t *aw = ae->worker; -jk_sock_t sock; +/* Close previous socket

Re: svn commit: r603637 - /tomcat/connectors/trunk/jk/native/common/jk_ajp_common.c

2007-12-12 Thread Mladen Turk
Rainer Jung wrote: Hmm, I'm almost sure this is wrong. It makes race condition in threaded servers. shutdown is blocking call. Any particular reason why you changed that? The shutdown is done on the socket belonging to the endpoint, so it is not in concurrent use (the endpoint got it's socket

Re: svn commit: r604267 - /tomcat/connectors/trunk/jk/native/common/jk_ajp_common.c

2007-12-15 Thread Mladen Turk
[EMAIL PROTECTED] wrote: Author: rjung int ajp_connect_to_endpoint(ajp_endpoint_t * ae, jk_logger_t *l) { @@ -841,7 +861,7 @@ if (!IS_VALID_SOCKET(ae->sd)) { ae->last_errno = errno; -jk_log(l, JK_LOG_INFO, +jk_log(l, JK_LOG_ERROR, "Failed opening

Re: [VOTE] Releasing Tomcat Connectors 1.2.26

2007-12-24 Thread Mladen Turk
Rainer Jung wrote: Apache Tomcat Connectors 1.2.26 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 Regards, Mladen -

Re: [ANN] Apache Tomcat JK 1.2.26 Web Server Connector released

2008-01-03 Thread Mladen Turk
Tim Whittington wrote: Binary builds of 1.2.26 for various platforms are available now from http://sourceforge.net/projects/timsjk/ These include builds of a patched IIS 5/6 ISAPI Redirector that support HTTP 1.1 chunked encoding (and thus keep-alives on dynamic content). Hi Tim, Can you crea

Re: [ANN] Apache Tomcat JK 1.2.26 Web Server Connector released

2008-01-03 Thread Mladen Turk
Rainer Jung wrote: Just in case there's any synergy between them: related to chunked encoding for IIS there are two BZ entries/patches: Yes, I'm aware of all the history ;) I still think this is too huge change for 1.2 code base, but if done via conditional compile, it might be a good foundati

Re: svn commit: r608842 - /tomcat/connectors/trunk/jni/native/build/tcnative.m4

2008-01-05 Thread Mladen Turk
[EMAIL PROTECTED] wrote: URL: http://svn.apache.org/viewvc?rev=608842&view=rev Log: Correct syntax of linker flag for gcc. Modified: tomcat/connectors/trunk/jni/native/build/tcnative.m4 *linux*) -TCN_OPENSSL_LIBS="-L$use_openssl/lib --Wl,-rpath,$use_openssl/lib

Re: svn commit: r608842 - /tomcat/connectors/trunk/jni/native/build/tcnative.m4

2008-01-05 Thread Mladen Turk
Rainer Jung wrote: And those three are all correct and equivalent: -Wl,-rpath, -Wl,--rpath, -Wl,--rpath -Wl, Ok, so -Wl,-rpath, it is. Cool :) Cheers, Mladen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional comma

[TC6] Double AJP connector implementation

2006-10-25 Thread Mladen Turk
Hi, Beyond the fact that org.apache.jk.* provides a generator for the mod_jk.conf, is there any reason to have that connector in parallel with org.apache.coyote.ajp.* Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED]

Re: [TC6] Double AJP connector implementation

2006-10-26 Thread Mladen Turk
Remy Maucherat wrote: Filip Hanik - Dev Lists wrote: I don't have any preference either way, since we are pretty few active folks at the moment, the less code is usually better My plan was not to do that (org.apache.jk is not that huge) and keep people happy. Nevertheless, the Apache/IIS

Re: Strange tcnative version at tomcat60

2006-10-30 Thread Mladen Turk
Peter Rossbach wrote: Hi Malden, Must be tcnative at tomcat60 not an external svn link? I would like that we have the subset of connectors/jni inside tc6/native (only the parts that are used). The probable version will be 2.x while the version in connectors/jni will stay as 1.x for tc 5.5.x

Making connector defaault address as 0.0.0.0

2006-11-07 Thread Mladen Turk
Hi, With Native connector if the OS supports IPV6 the default address (null) is translated to "::", thus it only listens to the IPV6 addresses. In case the OS doesn't support IPV6 (hardly to be found nowadays), the null address is equivalent to the address="0.0.0.0". The same is for any Java conn

Re: Making connector defaault address as 0.0.0.0

2006-11-07 Thread Mladen Turk
Markus Schönhaber wrote: Mladen Turk wrote: BTW: why is this situation special wrt the native connector? Right, but that's not the case for all supported OS-es. Windows for sure (and Solaris I think) will refuse 127.0.0.1 when the address="::"

Re: Making connector defaault address as 0.0.0.0

2006-11-07 Thread Mladen Turk
Remy Maucherat wrote: Comments? As you say, 0.0.0.0 is ipv4 so it looks like a bad default value to me, while null means whatever the connector wants. Internally, it's up to the native layer to figure it out, I think. Sure, but the fact is that Java connectors will always use IPV4. APR c

Re: svn commit: r473346 - /tomcat/tc6.0.x/trunk/build.properties.default

2006-11-10 Thread Mladen Turk
Remy Maucherat wrote: [EMAIL PROTECTED] wrote: Author: mturk Date: Fri Nov 10 06:23:52 2006 New Revision: 473346 URL: http://svn.apache.org/viewvc?view=rev&rev=473346 Log: Add version control flags like in 5.5 No, it's to be added when building only, according to what the user is building.

Re: AJP flush packets?

2006-11-11 Thread Mladen Turk
Sven Köhler wrote: Hi, i see, you're developing Tomcat 6.0. Will Tomcat 6.0 send flush packets, when the flush()-method of the OutputStreams or the Writers are called? Yes. It's done in a way that is backward compatible. When out.flush() is called an empty data packet is sent. It's somethi

Re: AJP flush packets?

2006-11-13 Thread Mladen Turk
Sven Köhler wrote: i see, you're developing Tomcat 6.0. Will Tomcat 6.0 send flush packets, when the flush()-method of the OutputStreams or the Writers are called? Yes. It's done in a way that is backward compatible. When out.flush() is called an empty data packet is sent. Did it really need

Re: Tomcat 6.0.1 alpha

2006-11-17 Thread Mladen Turk
William A. Rowe, Jr. wrote: Guys - something got broken again in your release process against ASF policy... I don't see three +1's for any of the recent postings to your downloads page. +1 -- Mladen - To unsubscribe, e-mail

Re: Tomcat 6.0.1 alpha

2006-11-17 Thread Mladen Turk
William A. Rowe, Jr. wrote: Guys - something got broken again in your release process against ASF policy... I don't see three +1's for any of the recent postings to your downloads page. Nothing got broken. Tomcat is probably one of the latest remaining projects where the developers and PMC st

Re: svn commit: r476817 - /tomcat/connectors/trunk/jk/native/common/jk_ajp_common.c

2006-11-19 Thread Mladen Turk
[EMAIL PROTECTED] wrote: URL: http://svn.apache.org/viewvc?view=rev&rev=476817 -if (ae->worker->socket_timeout > 0) { -if (!jk_is_socket_connected(ae->sd)) { +if (!jk_is_socket_connected(ae->sd)) { +1. That's possible because socket connect detection is not dependen

Re: [Proposal] Change in behaviour of uriworkermap.properties

2006-11-21 Thread Mladen Turk
Rainer Jung wrote: If you think you can do that in a simple way, then fine. But if it would require a lots of changes, then I think we should go with the more powerful solution as part of 1.3 branch, by using shared memory, web interface, etc. I just don't think that this is so important if yo

Re: [Proposal] Change in behaviour of uriworkermap.properties

2006-11-21 Thread Mladen Turk
Rainer Jung wrote: E.g. if one empties the uriworkermap.properties, reloading it does not change the internal mount list. Temporarily adding and later removing an entry will not remove the entry. That's the entire point. But this is not what a user expects from a change in a list. I know, bu

Re: Tagging plans for mod_jk 1.2.20

2006-11-22 Thread Mladen Turk
Rainer Jung wrote: Hi, I suggest to tag mod_jk 1.2.20 next weekend. There are a couple of additions to the status worker, and only small changes concerning the apache integration (env vars, JkOptions and virtual hosts) coming from me in the next days, but I would be ready to tag around saturd

Re: State of affairs for mod_jk 1.2.20

2006-11-24 Thread Mladen Turk
Rainer Jung wrote: For those who want to test: I committed far the most part of what I planned to improve. Thanks Rainer, the patches you made are really great! I think we'll have a best ever mod_jk. However I still have doubts about you patch: > @@ -1219,8 +1219,8 @@ > jk_log(l,

Re: svn commit: r478809 - /tomcat/connectors/trunk/jk/native/common/jk_lb_worker.c

2006-11-24 Thread Mladen Turk
Rainer Jung wrote: Hi Mladen, very nice idea making things easier for users. I like it. But dots are standard separation characters in host names and host names might not be totally uncommon as jvm routes. I know, that they can be symbolic, but we might break configs or deny using such a simple

<    1   2   3   4   5   6   7   8   9   10   >