JNDI Datasource HOW-TO

[荒浪一城]

Hi all.

The description concerning the setting of MySQL is old.
I hope the description that corresponds to version 5.x. :-D


Kazuki Aranami

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

DO NOT REPLY [Bug 39834] - JkLogLevel debug causes Segmentation fault

[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=39834





--- Additional Comments From [EMAIL PROTECTED]  2006-08-23 10:00 ---
Thank you for your quick reply.

> In case you want to discuss this further, please open another bugzilla.
I'll open another bugzilla if i can't resolve this problem after some our tests.

thansks,


-- 
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 40305] New: - The getSession() method returns invalid session.

[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=40305

   Summary: The getSession() method returns invalid session.
   Product: Tomcat 5
   Version: 5.5.17
  Platform: Other
OS/Version: Windows XP
Status: NEW
  Severity: normal
  Priority: P2
 Component: Catalina
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


I noticed that the counter "accessCount" of StandardSession is not synchronized 
to the session table of the Manager.
That cause a problem.

The Specification 2.4 says:
---
The session invalidation will not take effect until all servlets using that 
session have exited the service method.
---

The problem is:
1. First request creates a session.
2. Next request invokes getSession(false).
 In the Request#doGetSession() method,
2.1. The manager's findSession() method is called.
2.2. It is checked whether the session is valid by using the session's 
isValid() method.
 We assume that the current thread changes before StandardSession#access() 
is called. 
3. ManagerBase#processExpires() is called.
   In this timing, the session will be invalidated if the session is time-out,
   because the counter "accessCount" is 0.
4. StandardSession#access() is called with the former thread.
5. The getSession(false) method returns invalid session.

However, we were expecting Null or an valid session. 

I think that it is necessary to do some synchronous processing between 
accessCounter and the session table.

-- 
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: possible mod_jk "feature"

[Filip Hanik - Dev Lists]

Rainer Jung wrote:

Jim Jagielski schrieb:
  

In a nutshell, there are many cases where Apache httpd and
Tomcat are separated by a firewall, and, as such, there
isn't a one-to-one direct connection. The firewall
will close a connection but one side doesn't
know about it.



I would call this a broken firewall, right? This kind of behaviour is
expected to produce problems for nearl every communication (I don't say,
we shouldn't provide a workaround).
  
definitely not a broken firewall, works exactly like it should. it 
silently drops, that is how it avoids making itself vulnerable to DOS

Still: do you know, what happened in the actual problem case:

- which side of the communication has been shut down by the firewall,
Apache-FW or FW-Tomcat?

- did it reset it, do a full Fin-Ack... or did it just start to silently
drop packets?

- was keep_alive anbled for the worker? This is a standard socket
option, that is used to simulate traffic on a connection. The default
settings for many OSes are interval equals 7200 seconds, so that only
onc every 2 hours a TCP keep alive packet is being sent. Depending on
the FW admins idea about idleness, it might be enough to simply lower
the keep alive interval in the OS TCP configuration. Has this been tried?

  

As such, new requests create more
sockets until TC runs out of threads. mod_jk is
not recycling connections as it should, and



What do you mean by "not recycling"? I think this symptom hasn't been
reported until now.

  

setting the various params (eg: connection_pool_timeout)
does not solve the problem. It's similar to the old
Apache http lingering close problem.

http://www.mail-archive.com/tomcat-dev@jakarta.apache.org/msg75444.html
is one example of such problems, in which case you
responded and agreed that don't reuse is a last resort
solution.



I don't find lingering close in this message. The primary situation for
this user was the need to connect a lot of Apache threads to a tomcat.
In the meantim the APR connector got more stable, so that would be the
best choice for him. If he will still run out of threads on the tomcat
side, he will need to segment his setup into smaller cells. Trying to
"solve" this kind of situation by not reusing connections is really no
solution, but a broken system design.

  

I just think it would be nice to provide that last
resort :)



With this I agree. There is another possible solution:
we could add another parameter to the pool sizing, the max idle count.
This would be exactly analogous to the httpd and tomcat pool semantics.
Setting it to 0 would mean, that no connection will be put back into the
pool and instead all connections are being closed after a request. Comments?

  

-
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]


  



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

Re: possible mod_jk "feature"

[Rainer Jung]

I still don't have a consistent idea what happened around the firewall:

- silently dropping is not expected apart from a deny rule, but deny
will not be the rule that had been applied to the apache-tomcat connection.

- only shutting down one side of an established (!) connection seems broken

- no answers yet about using TCP keep-alive

- no comments on my suggestion to make the connection pool more
flexible: min pool size, max pool size and max connection number? this
will allow us to

  - temporarily connect although the pool is expired with a defined limit
  - configure for not reusing connections by setting max_idle to 0

I would find out, whether it's easy to do over the weekend, but I would
like to get some feedback on the idea.

- Anyone who can reproduce a real problem, when mod_jk shuts down a
connection? I reported, that with a recent mod_jk and TC 5.5.17 on
Solaris it's not a problem, and the TC code and the Java API doc suggest
it's no problem on any platform.

Regards

Rainer

Filip Hanik - Dev Lists schrieb:
> Rainer Jung wrote:
>> Jim Jagielski schrieb:
>>  
>>> In a nutshell, there are many cases where Apache httpd and
>>> Tomcat are separated by a firewall, and, as such, there
>>> isn't a one-to-one direct connection. The firewall
>>> will close a connection but one side doesn't
>>> know about it.
>>> 
>>
>> I would call this a broken firewall, right? This kind of behaviour is
>> expected to produce problems for nearl every communication (I don't say,
>> we shouldn't provide a workaround).
>>   
> definitely not a broken firewall, works exactly like it should. it
> silently drops, that is how it avoids making itself vulnerable to DOS
>> Still: do you know, what happened in the actual problem case:
>>
>> - which side of the communication has been shut down by the firewall,
>> Apache-FW or FW-Tomcat?
>>
>> - did it reset it, do a full Fin-Ack... or did it just start to silently
>> drop packets?
>>
>> - was keep_alive anbled for the worker? This is a standard socket
>> option, that is used to simulate traffic on a connection. The default
>> settings for many OSes are interval equals 7200 seconds, so that only
>> onc every 2 hours a TCP keep alive packet is being sent. Depending on
>> the FW admins idea about idleness, it might be enough to simply lower
>> the keep alive interval in the OS TCP configuration. Has this been tried?
>>
>>  
>>> As such, new requests create more
>>> sockets until TC runs out of threads. mod_jk is
>>> not recycling connections as it should, and
>>> 
>>
>> What do you mean by "not recycling"? I think this symptom hasn't been
>> reported until now.
>>
>>  
>>> setting the various params (eg: connection_pool_timeout)
>>> does not solve the problem. It's similar to the old
>>> Apache http lingering close problem.
>>>
>>> http://www.mail-archive.com/tomcat-dev@jakarta.apache.org/msg75444.html
>>> is one example of such problems, in which case you
>>> responded and agreed that don't reuse is a last resort
>>> solution.
>>> 
>>
>> I don't find lingering close in this message. The primary situation for
>> this user was the need to connect a lot of Apache threads to a tomcat.
>> In the meantim the APR connector got more stable, so that would be the
>> best choice for him. If he will still run out of threads on the tomcat
>> side, he will need to segment his setup into smaller cells. Trying to
>> "solve" this kind of situation by not reusing connections is really no
>> solution, but a broken system design.
>>
>>  
>>> I just think it would be nice to provide that last
>>> resort :)
>>> 
>>
>> With this I agree. There is another possible solution:
>> we could add another parameter to the pool sizing, the max idle count.
>> This would be exactly analogous to the httpd and tomcat pool semantics.
>> Setting it to 0 would mean, that no connection will be put back into the
>> pool and instead all connections are being closed after a request.
>> Comments?
>>
>>  
>>> -
>>> 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]
>>
>>
>>   
> 
> 
> -
> 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: possible mod_jk "feature"

[Mladen Turk]

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 care why they exist.
2. Only the Tomcat is affected cause mod_jk connects
   to it. With mod_jk if write() fails we reconnect,
   but Tomcat still waits on stream read() and
   disconnects on some systems after 240 secs,
   thus rising the thread count.
3. Up to 1.2.18 even the httpd restart could cause
   thread count to double in size.

So, having that, the only solution is to:
1. Set connectionTimeout in Tomcat that will always
   close the inactive connections
2. Use CPING/CPONG to detect disconnected sockets
   prior sending request.

Now, the advanced thing should set the reuse flag to
false according to the maxKeepAliveRequests in returned
AJP packet. This will cause both Keep-Alive to work
and graceful socket disconnection because both sides
will be closed.



- no comments on my suggestion to make the connection pool more
flexible: min pool size, max pool size and max connection number? this
will allow us to

  - temporarily connect although the pool is expired with a defined limit
  - configure for not reusing connections by setting max_idle to 0



We have that already in 1.2.18.

Regards,
Mladen.

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

Re: possible mod_jk "feature"

[Klaus Wagner]

Here my impressions of the situation from an serveradmin perspective.

On Wed, 2006-08-23 at 17:08 +0200, Rainer Jung wrote:
> I still don't have a consistent idea what happened around the firewall:
> 
> - silently dropping is not expected apart from a deny rule, but deny
> will not be the rule that had been applied to the apache-tomcat connection.

state keeping firewalls have timeouts. If the firewalltimeouts are lower
that keepalive timeouts there is a possibility that the firewall
invalidates the connection - afterwards it will drop any related packet.
Another possibility would be a firewall that is forgetting states which
would be clearly a bug.

> 
> - only shutting down one side of an established (!) connection seems broken

I don't think this is going to happen, but here is the reason why tomcat
is in the worse situation:

client ---request---> apache
apache tries to use the stale connection and realizes that this is
broken de facto immediately (socket error)

tomcat on the other hand is not really notified (execpt when the kernel
marks the connection as stale (timeout) AND tomcat tries to read from or
poll/select the connections state)

> - no answers yet about using TCP keep-alive

should help in most cases imho

regards Klaus


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

Re: possible mod_jk "feature"

[Rainer Jung]

Klaus Wagner schrieb:
> Here my impressions of the situation from an serveradmin perspective.
> 
> On Wed, 2006-08-23 at 17:08 +0200, Rainer Jung wrote:
>> I still don't have a consistent idea what happened around the firewall:
>>
>> - silently dropping is not expected apart from a deny rule, but deny
>> will not be the rule that had been applied to the apache-tomcat connection.
> 
> state keeping firewalls have timeouts. If the firewalltimeouts are lower
> that keepalive timeouts there is a possibility that the firewall
> invalidates the connection - afterwards it will drop any related packet.
> Another possibility would be a firewall that is forgetting states which
> would be clearly a bug.

OK, then the read side on tomcat will not detect the problem, because
there is no connection shutdown. Tomcat threads will still stay in read
and only the connectionTimeout will help. Stopping reuse sacrifices
performance and ressources (e.g. firewall ressources...), using correct
keepalive values for the TCP stack seems to be worth an investigation.

> 
>> - only shutting down one side of an established (!) connection seems broken
> 
> I don't think this is going to happen, but here is the reason why tomcat
> is in the worse situation:
> 
> client ---request---> apache
> apache tries to use the stale connection and realizes that this is
> broken de facto immediately (socket error)
> 
> tomcat on the other hand is not really notified (execpt when the kernel
> marks the connection as stale (timeout) AND tomcat tries to read from or
> poll/select the connections state)
> 
>> - no answers yet about using TCP keep-alive
> 
> should help in most cases imho

That's my expectation to. I assume noone tried it in the case in question.

> 
> regards Klaus
> 
> 
> -
> 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: possible mod_jk "feature"

[Rainer Jung]

Hi Mladen,

Mladen Turk schrieb:
> Rainer Jung wrote:
>> I still don't have a consistent idea what happened around the firewall:
>>
> 
> It is a very simple:

I don't think so, because no one was able to give the details. From a
"simple" perspective everything is clear, but only the details will give
an indication, what the correct way to respond is. See the mail by Klaus
Wagner and my response.

> 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 care why they exist.

I don't care too, but the fact, that they don't send a FIN is important.
Thanks.

> 2. Only the Tomcat is affected cause mod_jk connects
>to it. With mod_jk if write() fails we reconnect,
>but Tomcat still waits on stream read() and
>disconnects on some systems after 240 secs,
>thus rising the thread count.

Correct, in that case, no one shut down the connection. In case the
correction shuts down cleanly, I found no indication, that this will
still cause a problem on the tomcat side.

> 3. Up to 1.2.18 even the httpd restart could cause
>thread count to double in size.

OK, late thanks for your fix!

> So, having that, the only solution is to:

0. Configure your TCP stack according to the idle timeout restrictions
your network admins place on your network environment (TCP keepalive
interval)

or

> 1. Set connectionTimeout in Tomcat that will always
>close the inactive connections
> 2. Use CPING/CPONG to detect disconnected sockets
>prior sending request.
> Now, the advanced thing should set the reuse flag to
> false according to the maxKeepAliveRequests in returned
> AJP packet. This will cause both Keep-Alive to work
> and graceful socket disconnection because both sides
> will be closed.
> 
>> - no comments on my suggestion to make the connection pool more
>> flexible: min pool size, max pool size and max connection number? this
>> will allow us to
>>
>>   - temporarily connect although the pool is expired with a defined limit
>>   - configure for not reusing connections by setting max_idle to 0
>>
> 
> We have that already in 1.2.18.

No: I'm talking about max_idle, min_idle and max_connection. We have
connection_pool_size and conection_pool_minsize. They map as follows:

Compatibility situation:
min_idle=connection_pool_minsize
max_idle=max_connection=connection_pool_maxsize

But by giving max_connection a bigger value than max_idle, we would
allow additional connections in case the pool is exhausted, which will
not be pooled after end of their usage.

A special case would be minIdle=max_idle=0 and
max_connection=num_of_threads, which will lead to unpooled connections,
i.e. each connection will be destroyed after use.

The model is totally analogous to the httpd process model (maximum
processes and min and max spare processes) and to the tomcat thread
model for connection pools and thus should sound familiar to the users.

The connctions in the pool are those that are counted as idle.

> 
> Regards,
> Mladen.


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

Re: possible mod_jk "feature"

[Filip Hanik - Dev Lists]

having mod_jk rely on the AJP packet from Tomcat to close a socket or 
not, is like saying the IE browser can't close the socket unless Apache 
httpd says so.
The patch the Jim provided, gives us the functionality of turning off 
the keep alive from the "clients" (httpd in this case) perspective.


Filip

Rainer Jung wrote:

Hi Mladen,

Mladen Turk schrieb:
  

Rainer Jung wrote:


I still don't have a consistent idea what happened around the firewall:

  

It is a very simple:



I don't think so, because no one was able to give the details. From a
"simple" perspective everything is clear, but only the details will give
an indication, what the correct way to respond is. See the mail by Klaus
Wagner and my response.

  

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 care why they exist.



I don't care too, but the fact, that they don't send a FIN is important.
Thanks.

  

2. Only the Tomcat is affected cause mod_jk connects
   to it. With mod_jk if write() fails we reconnect,
   but Tomcat still waits on stream read() and
   disconnects on some systems after 240 secs,
   thus rising the thread count.



Correct, in that case, no one shut down the connection. In case the
correction shuts down cleanly, I found no indication, that this will
still cause a problem on the tomcat side.

  

3. Up to 1.2.18 even the httpd restart could cause
   thread count to double in size.



OK, late thanks for your fix!

  

So, having that, the only solution is to:



0. Configure your TCP stack according to the idle timeout restrictions
your network admins place on your network environment (TCP keepalive
interval)

or

  

1. Set connectionTimeout in Tomcat that will always
   close the inactive connections
2. Use CPING/CPONG to detect disconnected sockets
   prior sending request.
Now, the advanced thing should set the reuse flag to
false according to the maxKeepAliveRequests in returned
AJP packet. This will cause both Keep-Alive to work
and graceful socket disconnection because both sides
will be closed.



- no comments on my suggestion to make the connection pool more
flexible: min pool size, max pool size and max connection number? this
will allow us to

  - temporarily connect although the pool is expired with a defined limit
  - configure for not reusing connections by setting max_idle to 0

  

We have that already in 1.2.18.



No: I'm talking about max_idle, min_idle and max_connection. We have
connection_pool_size and conection_pool_minsize. They map as follows:

Compatibility situation:
min_idle=connection_pool_minsize
max_idle=max_connection=connection_pool_maxsize

But by giving max_connection a bigger value than max_idle, we would
allow additional connections in case the pool is exhausted, which will
not be pooled after end of their usage.

A special case would be minIdle=max_idle=0 and
max_connection=num_of_threads, which will lead to unpooled connections,
i.e. each connection will be destroyed after use.

The model is totally analogous to the httpd process model (maximum
processes and min and max spare processes) and to the tomcat thread
model for connection pools and thus should sound familiar to the users.

The connctions in the pool are those that are counted as idle.

  

Regards,
Mladen.




-
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]

svn commit: r434087 - in /tomcat/connectors/trunk/jk/native: apache-1.3/mod_jk.c apache-2.0/mod_jk.c common/jk_logger.h common/jk_util.c domino/jk_dsapi_plugin.c iis/jk_isapi_plugin.c isapi/jk_isapi_p

[rjung]

Author: rjung
Date: Wed Aug 23 10:22:00 2006
New Revision: 434087

URL: http://svn.apache.org/viewvc?rev=434087&view=rev
Log:
Change default log level from debug/undefined to info.

Modified:
tomcat/connectors/trunk/jk/native/apache-1.3/mod_jk.c
tomcat/connectors/trunk/jk/native/apache-2.0/mod_jk.c
tomcat/connectors/trunk/jk/native/common/jk_logger.h
tomcat/connectors/trunk/jk/native/common/jk_util.c
tomcat/connectors/trunk/jk/native/domino/jk_dsapi_plugin.c
tomcat/connectors/trunk/jk/native/iis/jk_isapi_plugin.c
tomcat/connectors/trunk/jk/native/isapi/jk_isapi_plugin.c
tomcat/connectors/trunk/jk/native/netscape/jk_nsapi_plugin.c

Modified: tomcat/connectors/trunk/jk/native/apache-1.3/mod_jk.c
URL: 
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/apache-1.3/mod_jk.c?rev=434087&r1=434086&r2=434087&view=diff
==
--- tomcat/connectors/trunk/jk/native/apache-1.3/mod_jk.c (original)
+++ tomcat/connectors/trunk/jk/native/apache-1.3/mod_jk.c Wed Aug 23 10:22:00 
2006
@@ -1874,7 +1874,7 @@
 c->mount_file = NULL;
 c->log_file = NULL;
 c->log_fd = -1;
-c->log_level = -1;
+c->log_level = JK_LOG_DEF_LEVEL;
 c->log = NULL;
 c->alias_dir = NULL;
 c->format_string = NULL;

Modified: tomcat/connectors/trunk/jk/native/apache-2.0/mod_jk.c
URL: 
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/apache-2.0/mod_jk.c?rev=434087&r1=434086&r2=434087&view=diff
==
--- tomcat/connectors/trunk/jk/native/apache-2.0/mod_jk.c (original)
+++ tomcat/connectors/trunk/jk/native/apache-2.0/mod_jk.c Wed Aug 23 10:22:00 
2006
@@ -2042,7 +2042,7 @@
 c->worker_file = NULL;
 c->mount_file = NULL;
 c->log_file = NULL;
-c->log_level = -1;
+c->log_level = JK_LOG_DEF_LEVEL;
 c->log = NULL;
 c->alias_dir = NULL;
 c->format_string = NULL;

Modified: tomcat/connectors/trunk/jk/native/common/jk_logger.h
URL: 
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/common/jk_logger.h?rev=434087&r1=434086&r2=434087&view=diff
==
--- tomcat/connectors/trunk/jk/native/common/jk_logger.h (original)
+++ tomcat/connectors/trunk/jk/native/common/jk_logger.h Wed Aug 23 10:22:00 
2006
@@ -60,6 +60,7 @@
 #define JK_LOG_ERROR_LEVEL   4
 #define JK_LOG_EMERG_LEVEL   5
 #define JK_LOG_REQUEST_LEVEL 6
+#define JK_LOG_DEF_LEVEL JK_LOG_INFO_LEVEL
 
 #define JK_LOG_TRACE_VERB   "trace"
 #define JK_LOG_DEBUG_VERB   "debug"
@@ -67,6 +68,7 @@
 #define JK_LOG_WARN_VERB"warn"
 #define JK_LOG_ERROR_VERB   "error"
 #define JK_LOG_EMERG_VERB   "emerg"
+#define JK_LOG_DEF_VERB JK_LOG_INFO_VERB
 
 #if defined(__GNUC__) || (defined(_MSC_VER) && (_MSC_VER > 1200))
 #define JK_LOG_TRACE   __FILE__,__LINE__,__FUNCTION__,JK_LOG_TRACE_LEVEL

Modified: tomcat/connectors/trunk/jk/native/common/jk_util.c
URL: 
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/common/jk_util.c?rev=434087&r1=434086&r2=434087&view=diff
==
--- tomcat/connectors/trunk/jk/native/common/jk_util.c (original)
+++ tomcat/connectors/trunk/jk/native/common/jk_util.c Wed Aug 23 10:22:00 2006
@@ -228,7 +228,7 @@
 return JK_LOG_EMERG_LEVEL;
 }
 
-return JK_LOG_INFO_LEVEL;
+return JK_LOG_DEF_LEVEL;
 }
 
 int jk_open_file_logger(jk_logger_t **l, const char *file, int level)

Modified: tomcat/connectors/trunk/jk/native/domino/jk_dsapi_plugin.c
URL: 
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/domino/jk_dsapi_plugin.c?rev=434087&r1=434086&r2=434087&view=diff
==
--- tomcat/connectors/trunk/jk/native/domino/jk_dsapi_plugin.c (original)
+++ tomcat/connectors/trunk/jk/native/domino/jk_dsapi_plugin.c Wed Aug 23 
10:22:00 2006
@@ -79,7 +79,7 @@
 static jk_uri_worker_map_t *uw_map = NULL;
 static jk_logger_t *logger = NULL;
 
-static int logLevel = JK_LOG_EMERG_LEVEL;
+static int logLevel = JK_LOG_DEF_LEVEL;
 static jk_pool_t cfgPool;
 
 static const char *logFile;
@@ -614,7 +614,7 @@
 GETVNB(JK_WORKER_FILE_TAG, workerFile);
 GETVNB(JK_MOUNT_FILE_TAG, workerMountFile);
 
-logLevel = (NULL == v) ? 0 : jk_parse_log_level(v);
+logLevel = (NULL == v) ? JK_LOG_DEF_LEVEL : jk_parse_log_level(v);
 
 tomcatStart = GETV(TOMCAT_START);
 tomcatStop = GETV(TOMCAT_STOP);

Modified: tomcat/connectors/trunk/jk/native/iis/jk_isapi_plugin.c
URL: 
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/iis/jk_isapi_plugin.c?rev=434087&r1=434086&r2=434087&view=diff
==
--- tomcat/connectors/trunk/jk/native/iis/jk_isapi_plugin.c (original)
+++ tomcat/connectors/trunk/jk/native/iis/jk_is

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

[rjung]

Author: rjung
Date: Wed Aug 23 10:26:01 2006
New Revision: 434089

URL: http://svn.apache.org/viewvc?rev=434089&view=rev
Log:
Fix typo in debug message.

Modified:
tomcat/connectors/trunk/jk/native/apache-1.3/mod_jk.c
tomcat/connectors/trunk/jk/native/apache-2.0/mod_jk.c

Modified: tomcat/connectors/trunk/jk/native/apache-1.3/mod_jk.c
URL: 
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/apache-1.3/mod_jk.c?rev=434089&r1=434088&r2=434089&view=diff
==
--- tomcat/connectors/trunk/jk/native/apache-1.3/mod_jk.c (original)
+++ tomcat/connectors/trunk/jk/native/apache-1.3/mod_jk.c Wed Aug 23 10:26:01 
2006
@@ -499,7 +499,7 @@
  */
 if (JK_IS_DEBUG_LEVEL(conf->log)) {
 jk_log(conf->log, JK_LOG_DEBUG,
-   "Service protocol=%s method=%s host=%s addrr=%s name=%s port=%d 
auth=%s user=%s laddr=%s raddr=%s",
+   "Service protocol=%s method=%s host=%s addr=%s name=%s port=%d 
auth=%s user=%s laddr=%s raddr=%s",
STRNULL_FOR_NULL(s->protocol),
STRNULL_FOR_NULL(s->method),
STRNULL_FOR_NULL(s->remote_host),

Modified: tomcat/connectors/trunk/jk/native/apache-2.0/mod_jk.c
URL: 
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/apache-2.0/mod_jk.c?rev=434089&r1=434088&r2=434089&view=diff
==
--- tomcat/connectors/trunk/jk/native/apache-2.0/mod_jk.c (original)
+++ tomcat/connectors/trunk/jk/native/apache-2.0/mod_jk.c Wed Aug 23 10:26:01 
2006
@@ -529,7 +529,7 @@
  */
 if (JK_IS_DEBUG_LEVEL(conf->log)) {
 jk_log(conf->log, JK_LOG_DEBUG,
-   "Service protocol=%s method=%s host=%s addrr=%s name=%s port=%d 
auth=%s user=%s laddr=%s raddr=%s",
+   "Service protocol=%s method=%s host=%s addr=%s name=%s port=%d 
auth=%s user=%s laddr=%s raddr=%s",
STRNULL_FOR_NULL(s->protocol),
STRNULL_FOR_NULL(s->method),
STRNULL_FOR_NULL(s->remote_host),



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

svn commit: r434096 - /tomcat/connectors/trunk/jk/native/common/jk_global.h

[rjung]

Author: rjung
Date: Wed Aug 23 10:40:03 2006
New Revision: 434096

URL: http://svn.apache.org/viewvc?rev=434096&view=rev
Log:
Addon for r434087 (default log level)

Modified:
tomcat/connectors/trunk/jk/native/common/jk_global.h

Modified: tomcat/connectors/trunk/jk/native/common/jk_global.h
URL: 
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/common/jk_global.h?rev=434096&r1=434095&r2=434096&view=diff
==
--- tomcat/connectors/trunk/jk/native/common/jk_global.h (original)
+++ tomcat/connectors/trunk/jk/native/common/jk_global.h Wed Aug 23 10:40:03 
2006
@@ -166,7 +166,6 @@
 #define JK_WORKER_NAME_TAG  ("worker")
 
 #define JK_WORKER_FILE_DEF  ("workers.properties")
-#define JK_LOG_LEVEL_DEF("emerg")
 
 #define JK_TRUE  (1)
 #define JK_FALSE (0)



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

svn commit: r434098 - /tomcat/connectors/trunk/jk/native/common/jk_service.h

[rjung]

Author: rjung
Date: Wed Aug 23 10:42:15 2006
New Revision: 434098

URL: http://svn.apache.org/viewvc?rev=434098&view=rev
Log:
Correct placement of comment.

Modified:
tomcat/connectors/trunk/jk/native/common/jk_service.h

Modified: tomcat/connectors/trunk/jk/native/common/jk_service.h
URL: 
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/common/jk_service.h?rev=434098&r1=434097&r2=434098&view=diff
==
--- tomcat/connectors/trunk/jk/native/common/jk_service.h (original)
+++ tomcat/connectors/trunk/jk/native/common/jk_service.h Wed Aug 23 10:42:15 
2006
@@ -200,11 +200,6 @@
and it'll work.
  */
 const char *secret;
-/*
- * Callbacks into the web server.  For each, the first argument is
- * essentially a 'this' pointer.  All return JK_TRUE on success
- * and JK_FALSE on failure.
- */
 
 /*
  * Area to get POST data for fail-over recovery in POST
@@ -225,6 +220,11 @@
  */
 jk_uri_worker_map_t *uw_map;
 
+/*
+ * Callbacks into the web server.  For each, the first argument is
+ * essentially a 'this' pointer.  All return JK_TRUE on success
+ * and JK_FALSE on failure.
+ */
 /*
  * Send the response headers to the browser.
  */



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

svn commit: r434110 - in /tomcat/connectors/trunk/jk/native/common: jk_lb_worker.c jk_lb_worker.h jk_util.c

[rjung]

Author: rjung
Date: Wed Aug 23 11:11:13 2006
New Revision: 434110

URL: http://svn.apache.org/viewvc?rev=434110&view=rev
Log:
Make constant naming more consistent, separate defaults from values.

Modified:
tomcat/connectors/trunk/jk/native/common/jk_lb_worker.c
tomcat/connectors/trunk/jk/native/common/jk_lb_worker.h
tomcat/connectors/trunk/jk/native/common/jk_util.c

Modified: tomcat/connectors/trunk/jk/native/common/jk_lb_worker.c
URL: 
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/common/jk_lb_worker.c?rev=434110&r1=434109&r2=434110&view=diff
==
--- tomcat/connectors/trunk/jk/native/common/jk_lb_worker.c (original)
+++ tomcat/connectors/trunk/jk/native/common/jk_lb_worker.c Wed Aug 23 11:11:13 
2006
@@ -102,7 +102,7 @@
 {
 unsigned int i = 0;
 JK_TRACE_ENTER(l);
-if (p->lbmethod != JK_LB_BYBUSYNESS) {
+if (p->lbmethod != JK_LB_METHOD_BUSYNESS) {
 for (i = 0; i < p->num_of_workers; i++) {
 p->lb_workers[i].s->lb_value = 0;
 }
@@ -272,7 +272,7 @@
 jk_uint64_t curmax = 0;
 
 JK_TRACE_ENTER(l);
-if (p->lbmethod != JK_LB_BYBUSYNESS) {
+if (p->lbmethod != JK_LB_METHOD_BUSYNESS) {
 for (i = 0; i < p->num_of_workers; i++) {
 p->lb_workers[i].s->lb_value >>= exponent;
 if (p->lb_workers[i].s->lb_value > curmax) {
@@ -664,9 +664,9 @@
 if (p->worker->s->busy > p->worker->s->max_busy)
 p->worker->s->max_busy = p->worker->s->busy;
 rec->s->busy++;
-if (p->worker->lbmethod == JK_LB_BYREQUESTS)
+if (p->worker->lbmethod == JK_LB_METHOD_REQUESTS)
 rec->s->lb_value += rec->s->lb_mult;
-else if (p->worker->lbmethod == JK_LB_BYBUSYNESS)
+else if (p->worker->lbmethod == JK_LB_METHOD_BUSYNESS)
 rec->s->lb_value += rec->s->lb_mult;
 if (rec->s->busy > rec->s->max_busy)
 rec->s->max_busy = rec->s->busy;
@@ -684,9 +684,9 @@
 /* Update partial reads and writes if any */
 rec->s->readed += rd;
 rec->s->transferred += wr;
-if (p->worker->lbmethod == JK_LB_BYTRAFFIC)
+if (p->worker->lbmethod == JK_LB_METHOD_TRAFFIC)
 rec->s->lb_value += (rd+wr)*rec->s->lb_mult;
-else if (p->worker->lbmethod == JK_LB_BYBUSYNESS)
+else if (p->worker->lbmethod == JK_LB_METHOD_BUSYNESS)
 if (rec->s->lb_value >= rec->s->lb_mult)
 rec->s->lb_value -= rec->s->lb_mult;
 else {

Modified: tomcat/connectors/trunk/jk/native/common/jk_lb_worker.h
URL: 
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/common/jk_lb_worker.h?rev=434110&r1=434109&r2=434110&view=diff
==
--- tomcat/connectors/trunk/jk/native/common/jk_lb_worker.h (original)
+++ tomcat/connectors/trunk/jk/native/common/jk_lb_worker.h Wed Aug 23 11:11:13 
2006
@@ -38,16 +38,20 @@
 #define JK_LB_WORKER_TYPE (5)
 #define JK_LB_DEF_DOMAIN_NAME ("unknown")
 
-#define JK_LB_BYREQUESTS  (0)
-#define JK_LB_BYTRAFFIC   (1)
-#define JK_LB_BYBUSYNESS  (2)
-#define JK_LB_METHOD_REQUESTS ("Request")
-#define JK_LB_METHOD_TRAFFIC  ("Traffic")
-#define JK_LB_METHOD_BUSYNESS ("Busyness")
-#define JK_LB_LOCK_DEFAULT (0)
-#define JK_LB_LOCK_PESSIMISTIC (1)
-#define JK_LB_LM_DEFAULT   ("Optimistic")
-#define JK_LB_LM_PESSIMISTIC   ("Pessimistic")
+#define JK_LB_METHOD_REQUESTS  (1)
+#define JK_LB_METHOD_TRAFFIC   (2)
+#define JK_LB_METHOD_BUSYNESS  (3)
+#define JK_LB_METHOD_DEF   (JK_LB_METHOD_BUSYNESS)
+#define JK_LB_METHOD_TEXT_REQUESTS ("Request")
+#define JK_LB_METHOD_TEXT_TRAFFIC  ("Traffic")
+#define JK_LB_METHOD_TEXT_BUSYNESS ("Busyness")
+#define JK_LB_METHOD_TEXT_DEF  (JK_LB_METHOD_TEXT_BUSYNESS)
+#define JK_LB_LOCK_OPTIMISTIC  (1)
+#define JK_LB_LOCK_PESSIMISTIC (2)
+#define JK_LB_LOCK_DEF (JK_LB_LOCK_DEF)
+#define JK_LB_LOCK_TEXT_OPTIMISTIC ("Optimistic")
+#define JK_LB_LOCK_TEXT_PESSIMISTIC("Pessimistic")
+#define JK_LB_LOCK_TEXT_DEF(JK_LB_LOCK_TEXT_OPTIMISTIC)
 
 /* Time to wait before retry. */
 #define WAIT_BEFORE_RECOVER   (60)
@@ -59,23 +63,23 @@
 #define JK_LB_DECAY_MULT (1)
 
 static const char *lb_locking_type[] = {
-JK_LB_LM_DEFAULT,
-JK_LB_LM_PESSIMISTIC,
 "unknown",
+JK_LB_LOCK_TEXT_OPTIMISTIC,
+JK_LB_LOCK_TEXT_PESSIMISTIC,
 NULL
 };
 
 static const char *lb_method_type[] = {
-JK_LB_METHOD_REQUESTS,
-JK_LB_METHOD_TRAFFIC,
-JK_LB_METHOD_BUSYNESS,
 "unknown",
+JK_LB_METH

svn commit: r434119 - in /tomcat/connectors/trunk/jk/native: apache-1.3/mod_jk.c apache-2.0/mod_jk.c common/jk_worker.c common/jk_worker.h

[rjung]

Author: rjung
Date: Wed Aug 23 11:26:56 2006
New Revision: 434119

URL: http://svn.apache.org/viewvc?rev=434119&view=rev
Log:
Change note names and symbols to make them more consistent.
Add a note with the worker type. More notes are to come.
Documentation of the notes is still missing but important.

Modified:
tomcat/connectors/trunk/jk/native/apache-1.3/mod_jk.c
tomcat/connectors/trunk/jk/native/apache-2.0/mod_jk.c
tomcat/connectors/trunk/jk/native/common/jk_worker.c
tomcat/connectors/trunk/jk/native/common/jk_worker.h

Modified: tomcat/connectors/trunk/jk/native/apache-1.3/mod_jk.c
URL: 
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/apache-1.3/mod_jk.c?rev=434119&r1=434118&r2=434119&view=diff
==
--- tomcat/connectors/trunk/jk/native/apache-1.3/mod_jk.c (original)
+++ tomcat/connectors/trunk/jk/native/apache-1.3/mod_jk.c Wed Aug 23 11:26:56 
2006
@@ -60,9 +60,10 @@
 #include "jk_ajp13.h"
 #include "jk_shm.h"
 
-#define JK_WORKER_ID("jakarta.worker")
+#define JK_NOTE_WORKER_NAME ("JK_WORKER_NAME")
+#define JK_NOTE_WORKER_TYPE ("JK_WORKER_TYPE")
+#define JK_NOTE_REQUEST_DURATION("JK_REQUEST_DURATION")
 #define JK_HANDLER  ("jakarta-servlet")
-#define JK_DURATION ("jakarta.worker.duration")
 #define JK_MAGIC_TYPE   ("application/x-jakarta-servlet")
 #define NULL_FOR_EMPTY(x)   ((x && !strlen(x)) ? NULL : x)
 #define STRNULL_FOR_NULL(x) ((x) ? (x) : "(null)")
@@ -1071,13 +1072,13 @@
 
 static const char *log_worker_name(request_rec * r, char *a)
 {
-return ap_table_get(r->notes, JK_WORKER_ID);
+return ap_table_get(r->notes, JK_NOTE_WORKER_NAME);
 }
 
 
 static const char *log_request_duration(request_rec * r, char *a)
 {
-return ap_table_get(r->notes, JK_DURATION);
+return ap_table_get(r->notes, JK_NOTE_REQUEST_DURATION);
 }
 
 static const char *log_request_line(request_rec * r, char *a)
@@ -1711,7 +1712,7 @@
 static int jk_handler(request_rec * r)
 {
 /* Retrieve the worker name stored by jk_translate() */
-const char *worker_name = ap_table_get(r->notes, JK_WORKER_ID);
+const char *worker_name = ap_table_get(r->notes, JK_NOTE_WORKER_NAME);
 int rc;
 
 if (r->proxyreq) {
@@ -1757,6 +1758,8 @@
 s.retries = worker->retries;
 s.ws_private = &private_data;
 s.pool = &private_data.p;
+ap_table_setn(r->notes, JK_NOTE_WORKER_TYPE,
+  wc_get_name_for_type(worker->type, l));
 #ifndef NO_GETTIMEOFDAY
 if (conf->format != NULL) {
 gettimeofday(&tv_begin, NULL);
@@ -1799,7 +1802,7 @@
 seconds = tv_end.tv_sec - tv_begin.tv_sec;
 duration =
 ap_psprintf(r->pool, "%.1ld.%.6ld", seconds, micro);
-ap_table_setn(r->notes, JK_DURATION, duration);
+ap_table_setn(r->notes, JK_NOTE_REQUEST_DURATION, 
duration);
 request_log_transaction(r, conf);
 }
 #endif
@@ -2203,7 +2206,7 @@
 
 if (worker) {
 r->handler = ap_pstrdup(r->pool, JK_HANDLER);
-ap_table_setn(r->notes, JK_WORKER_ID, worker);
+ap_table_setn(r->notes, JK_NOTE_WORKER_NAME, worker);
 }
 else if (conf->alias_dir != NULL) {
 /* Automatically map uri to a context static file */
@@ -2301,7 +2304,7 @@
 if (r->main) {
 jk_server_conf_t *conf = (jk_server_conf_t *)
 ap_get_module_config(r->server->module_config, &jk_module);
-char *worker = (char *)ap_table_get(r->notes, JK_WORKER_ID);
+char *worker = (char *)ap_table_get(r->notes, JK_NOTE_WORKER_NAME);
 
 /* Only if we have no worker and ForwardDirectories is set */
 if (!worker && (conf->options & JK_OPT_FWDDIRS)) {

Modified: tomcat/connectors/trunk/jk/native/apache-2.0/mod_jk.c
URL: 
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/apache-2.0/mod_jk.c?rev=434119&r1=434118&r2=434119&view=diff
==
--- tomcat/connectors/trunk/jk/native/apache-2.0/mod_jk.c (original)
+++ tomcat/connectors/trunk/jk/native/apache-2.0/mod_jk.c Wed Aug 23 11:26:56 
2006
@@ -108,9 +108,10 @@
 #include "jk_worker.h"
 #include "jk_shm.h"
 
-#define JK_WORKER_ID("jakarta.worker")
+#define JK_NOTE_WORKER_NAME ("JK_WORKER_NAME")
+#define JK_NOTE_WORKER_TYPE ("JK_WORKER_TYPE")
+#define JK_NOTE_REQUEST_DURATION("JK_REQUEST_DURATION")
 #define JK_HANDLER  ("jakarta-servlet")
-#define JK_DURATION ("jakarta.worker.duration")
 #define JK_MAGIC_TYPE   ("application/x-jakarta-servlet")
 #define NULL_FOR_EMPTY(x)   ((x && !strlen(x)) ? NULL : x)
 #define STRNULL_FOR_NULL(x) ((x) ? (x) : "(null)")
@@ -1095,13 +1096,13 @@
 
 static const char *log_wor

svn commit: r434122 - /tomcat/connectors/trunk/jk/native/common/jk_lb_worker.h

[rjung]

Author: rjung
Date: Wed Aug 23 11:45:30 2006
New Revision: 434122

URL: http://svn.apache.org/viewvc?rev=434122&view=rev
Log:
Fix r434110.

Modified:
tomcat/connectors/trunk/jk/native/common/jk_lb_worker.h

Modified: tomcat/connectors/trunk/jk/native/common/jk_lb_worker.h
URL: 
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/common/jk_lb_worker.h?rev=434122&r1=434121&r2=434122&view=diff
==
--- tomcat/connectors/trunk/jk/native/common/jk_lb_worker.h (original)
+++ tomcat/connectors/trunk/jk/native/common/jk_lb_worker.h Wed Aug 23 11:45:30 
2006
@@ -41,14 +41,14 @@
 #define JK_LB_METHOD_REQUESTS  (1)
 #define JK_LB_METHOD_TRAFFIC   (2)
 #define JK_LB_METHOD_BUSYNESS  (3)
-#define JK_LB_METHOD_DEF   (JK_LB_METHOD_BUSYNESS)
+#define JK_LB_METHOD_DEF   (JK_LB_METHOD_REQUESTS)
 #define JK_LB_METHOD_TEXT_REQUESTS ("Request")
 #define JK_LB_METHOD_TEXT_TRAFFIC  ("Traffic")
 #define JK_LB_METHOD_TEXT_BUSYNESS ("Busyness")
-#define JK_LB_METHOD_TEXT_DEF  (JK_LB_METHOD_TEXT_BUSYNESS)
+#define JK_LB_METHOD_TEXT_DEF  (JK_LB_METHOD_TEXT_REQUESTS)
 #define JK_LB_LOCK_OPTIMISTIC  (1)
 #define JK_LB_LOCK_PESSIMISTIC (2)
-#define JK_LB_LOCK_DEF (JK_LB_LOCK_DEF)
+#define JK_LB_LOCK_DEF (JK_LB_LOCK_OPTIMISTIC)
 #define JK_LB_LOCK_TEXT_OPTIMISTIC ("Optimistic")
 #define JK_LB_LOCK_TEXT_PESSIMISTIC("Pessimistic")
 #define JK_LB_LOCK_TEXT_DEF(JK_LB_LOCK_TEXT_OPTIMISTIC)



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

Re: possible mod_jk "feature"

[Mladen Turk]

Filip Hanik - Dev Lists wrote:
having mod_jk rely on the AJP packet from Tomcat to close a socket or 
not, is like saying the IE browser can't close the socket unless Apache 
httpd says so.


Quite opposite. Unlike http, ajp protocol is persistent,
and one side must (should) explicitly mark the graceful physical
connection closure. In other case the connection break is
considered as communication channel error, and must be treated
by the user as such (By that I mean checking the cause of
channel failure, etc).

One other similar thing is graceful socket closure, that
should be accompanied by the mod_jk sending extended
cping packet when the connection is going to be gracefully
closed by mod_jk, so that Tomcat can close its socket
gracefully without getting ConnectionClosedException.

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.

Regards,
Mladen.

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

Re: parameters in URL path segments

[James Berry]

Jean-Frederic, Bill, Remy,

I didn't get any response to this, but would really like to hear your  
thoughts on this issue of parameters within URL path segments, which  
tomcat current does not allow. Can you give me any feedback?


Thanks!

James

On Aug 21, 2006, at 8:42 PM, James Berry wrote:

On Aug 21, 2006, at 6:26 PM, James Berry wrote:


Guys,

Sorry to open up this subject again. I've just read the mails in  
this thread:


http://marc.theaimsgroup.com/?l=tomcat-dev&m=115344110306194&w=2
http://marc.theaimsgroup.com/?l=tomcat-dev&m=115346837428224&w=2

Though I can't say I paid particular attention to the jkmount  
situation (and so I can't testify as to how treatment of such  
parameters might affect that), I can say that I'd like to be able  
to use ;parameter=value in my path segments in a tomcat environment:


http://example.com/this;biz=bar;foo/that;v=1.1/whatever

To me, this looks completely valid per rfc 2396, 2616, and 3986,  
and it's a surprise to me that tomcat strips any path following  
the first such parameter.


I would like to see tomcat essentially ignore the fact that ';'  
exists in a path segment, and pass it on into the servlet  
unmodified to do with as it pleases.


In fact, I don't see any motivation for any special handling of  
semicolon vs any other of the other sub-delims characters, none of  
which tomcat does anything special with. Comma and Plus are allowed  
in path segments, for instance; why is semicolon treated  
differently? The more recent RFCs say that there is nothing special  
that the server/container should do with such a character when it  
appears in a path segment.


Obviously, of course, there would be places where it would be plain  
wrong to place such a parameter/character (if it didn't map to a  
servlet, or to a file, or...) but there are other places (in extra  
path segments in pathInfo, for instance) where the interpretation  
of such characters should NOT BE made by the server, but by the  
ultimate consumer of those bits. Therefore, the server should  
simply not place any special meaning on such characters in any path  
segment.




I'm inspired by the following paragraph in G.4 of rfc 2396:

Extensive testing of current client applications demonstrated that
   the majority of deployed systems do not use the ";" character to
   indicate trailing parameter information, and that the presence  
of a
   semicolon in a path segment does not affect the relative  
parsing of
   that segment.  Therefore, parameters have been removed as a  
separate

   component and may now appear in any path segment.  Their influence
   has been removed from the algorithm for resolving a relative URI
   reference.  The resolution examples in Appendix C have been  
modified

   to reflect this change.

And also by the following from rfc 3986:

   Aside from dot-segments in hierarchical paths, a path segment is
   considered opaque by the generic syntax.  URI producing  
applications

   often use the reserved characters allowed in a segment to delimit
   scheme-specific or dereference-handler-specific subcomponents.   
For
   example, the semicolon (";") and equals ("=") reserved  
characters are
   often used to delimit parameters and parameter values  
applicable to
   that segment.  The comma (",") reserved character is often used  
for
   similar purposes.  For example, one URI producer might use a  
segment

   such as "name;v=1.1" to indicate a reference to version 1.1 of
   "name", whereas another might use a segment such as "name,1.1" to
   indicate the same.  Parameter types may be defined by scheme- 
specific
   semantics, but in most cases the syntax of a parameter is  
specific to

   the implementation of the URI's dereferencing algorithm.
Note that the segment syntax in rfc 3986 explicitly allows sub- 
delims (through pchar), of which ';' is but one.


James



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

svn commit: r434128 - in /tomcat/connectors/trunk/jk/native: apache-1.3/mod_jk.c apache-2.0/mod_jk.c common/jk_service.h common/jk_util.c

[rjung]

Author: rjung
Date: Wed Aug 23 12:17:14 2006
New Revision: 434128

URL: http://svn.apache.org/viewvc?rev=434128&view=rev
Log:
Add another server hook add_log_items to be able to return textual
result tokens to include in server logging.

We will use this in the load balancer to return names of used balanced 
orkers and their state. It would be nice, if the other (non Apache) servers
also had hash like structures which could be filled by this hook.

Modified:
tomcat/connectors/trunk/jk/native/apache-1.3/mod_jk.c
tomcat/connectors/trunk/jk/native/apache-2.0/mod_jk.c
tomcat/connectors/trunk/jk/native/common/jk_service.h
tomcat/connectors/trunk/jk/native/common/jk_util.c

Modified: tomcat/connectors/trunk/jk/native/apache-1.3/mod_jk.c
URL: 
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/apache-1.3/mod_jk.c?rev=434128&r1=434127&r2=434128&view=diff
==
--- tomcat/connectors/trunk/jk/native/apache-1.3/mod_jk.c (original)
+++ tomcat/connectors/trunk/jk/native/apache-1.3/mod_jk.c Wed Aug 23 12:17:14 
2006
@@ -202,6 +202,12 @@
  void *b, unsigned l, unsigned *a);
 
 static int JK_METHOD ws_write(jk_ws_service_t *s, const void *b, unsigned l);
+
+static void JK_METHOD ws_add_log_items(jk_ws_service_t *s,
+   const char *const *log_names,
+   const char *const *log_values,
+   unsigned num_of_log_items);
+
 /* srevilak - new function prototypes */
 static void jk_server_cleanup(void *data);
 static void jk_generic_cleanup(server_rec * s);
@@ -381,6 +387,22 @@
 return JK_FALSE;
 }
 
+static void JK_METHOD ws_add_log_items(jk_ws_service_t *s,
+   const char *const *log_names,
+   const char *const *log_values,
+   unsigned num_of_log_items)
+{
+unsigned h;
+apache_private_data_t *p = s->ws_private;
+request_rec *r = p->r;
+
+for (h = 0; h < num_of_log_items; h++) {
+if (log_names[h] && log_values[h]) {
+ap_table_setn(r->notes, log_names[h], log_values[h]);
+}
+}
+}
+
 /* == */
 /* Utility functions  */
 /* == */
@@ -455,6 +477,7 @@
 s->read = ws_read;
 s->write = ws_write;
 s->flush = ws_flush;
+s->add_log_items = ws_add_log_items;
 
 /* Clear RECO status */
 s->reco_status = RECO_NONE;
@@ -2119,7 +2142,7 @@
 for (i = 0; i < jk_map_size(conf->automount); i++)
 {
 char *name = jk_map_name_at(conf->automount, i);
-   jk_log(conf->log, JK_LOG_DEBUG, "worker = %s and 
virtualhost = %s", name, map_get_string(conf->automount, name, NULL));
+jk_log(conf->log, JK_LOG_DEBUG, "worker = %s and virtualhost = 
%s", name, map_get_string(conf->automount, name, NULL));
 }
 }
 */

Modified: tomcat/connectors/trunk/jk/native/apache-2.0/mod_jk.c
URL: 
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/apache-2.0/mod_jk.c?rev=434128&r1=434127&r2=434128&view=diff
==
--- tomcat/connectors/trunk/jk/native/apache-2.0/mod_jk.c (original)
+++ tomcat/connectors/trunk/jk/native/apache-2.0/mod_jk.c Wed Aug 23 12:17:14 
2006
@@ -220,6 +220,10 @@
 
 static int JK_METHOD ws_write(jk_ws_service_t *s, const void *b, unsigned l);
 
+static void JK_METHOD ws_add_log_items(jk_ws_service_t *s,
+   const char *const *log_names,
+   const char *const *log_values,
+   unsigned num_of_log_items);
 
 /* = */
 /* JK Service step callbacks */
@@ -425,6 +429,22 @@
 return JK_FALSE;
 }
 
+static void JK_METHOD ws_add_log_items(jk_ws_service_t *s,
+   const char *const *log_names,
+   const char *const *log_values,
+   unsigned num_of_log_items)
+{
+unsigned h;
+apache_private_data_t *p = s->ws_private;
+request_rec *r = p->r;
+
+for (h = 0; h < num_of_log_items; h++) {
+if (log_names[h] && log_values[h]) {
+apr_table_setn(r->notes, log_names[h], log_values[h]);
+}
+}
+}
+
 /* = */
 /* Utility functions */
 /* = */
@@ -482,6 +502,7 @@
 s->read = ws_read;

Re: possible mod_jk "feature"

[Rainer Jung]

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.

I would prefer the more useful 3 param connections/pool sizing I
suggested. I had a look at the code and it doesn't look very
complicated. I have a couple of open commits for the weekend and most
likely I've got the time to implement and document the "new" pool
behaviour. Furthermore there will be no need to break old pool configs,
although we add more functionality.

> 
> Regards,
> Mladen.

Regards,
Rainer

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

svn commit: r434138 - /tomcat/connectors/trunk/jk/native/common/jk_status.c

[rjung]

Author: rjung
Date: Wed Aug 23 12:39:12 2006
New Revision: 434138

URL: http://svn.apache.org/viewvc?rev=434138&view=rev
Log:
iAnd another fix for r434110.

Modified:
tomcat/connectors/trunk/jk/native/common/jk_status.c

Modified: tomcat/connectors/trunk/jk/native/common/jk_status.c
URL: 
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/common/jk_status.c?rev=434138&r1=434137&r2=434138&view=diff
==
--- tomcat/connectors/trunk/jk/native/common/jk_status.c (original)
+++ tomcat/connectors/trunk/jk/native/common/jk_status.c Wed Aug 23 12:39:12 
2006
@@ -452,7 +452,7 @@
 "", NULL);
 jk_printf(s, "%d", lb->s->retries);
 jk_printf(s, "%s", lb_method_type[lb->lbmethod]);
-jk_printf(s, "%s", lb->lblock == JK_LB_LOCK_DEFAULT ? 
JK_LB_LM_DEFAULT : JK_LB_LM_PESSIMISTIC);
+jk_printf(s, "%s", lb_locking_type[lb->lblock]);
 jk_puts(s, "\n\n\n");
 jk_puts(s, ""
 
"NameTypejvmRouteHostAddr"



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

DO NOT REPLY [Bug 40306] New: - POST request bodies are not restored on successful login when using mod_jk

[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=40306

   Summary: POST request bodies are not restored on successful login
when using mod_jk
   Product: Tomcat 5
   Version: 5.5.16
  Platform: All
OS/Version: Linux
Status: NEW
  Severity: major
  Priority: P2
 Component: Catalina
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


After the FormAuthenticator intercepts a POST request to a protected resource,
the original request is not properly restored upon successful login when using
mod_jk. When connectiong to tomcat directly (8080), the POST request is restored
as expected.

I've tested this with mod_jk 1.2.15 and 1.2.18. It seems the problem is that the
orginal request is not saved properly. I (think) I've narrowed down the issue in
  FormAuthenticator.java. body.toString() was returning null. (The buffer was
null) so it looks like the root of the problem is that nothing is read from the
input stream.

During testing I reverted to the old way of adding the request parameters
(saved.addParameter()) to see if they were indeed there and it worked. 

I also tried,
InputStream is = new BufferedInputStream(request.getInputStream()); 
which didn't work..


from FormAuthenticator.java: 

protected void saveRequest(Request request, Session session)
throws IOException {

  ...

  if ("POST".equalsIgnoreCase(request.getMethod())) {
ByteChunk body = new ByteChunk();
body.setLimit(request.getConnector().getMaxSavePostSize());

byte[] buffer = new byte[4096];
int bytesRead;
InputStream is = request.getInputStream();

while ( (bytesRead = is.read(buffer) ) >= 0) {
body.append(buffer, 0, bytesRead);
}

saved.setBody(body);
} 

...
}

-- 
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]

svn commit: r434141 - /tomcat/connectors/trunk/jk/native/common/jk_status.c

[rjung]

Author: rjung
Date: Wed Aug 23 12:51:31 2006
New Revision: 434141

URL: http://svn.apache.org/viewvc?rev=434141&view=rev
Log:
New features for jk_status:
- When a request updates data, the response does a meta redirect
  to the list view, so that a following browser refresh by the user does
  not send the update a second time.
- Add a link to start/stop automatic refresh
- Improve formatting of the dl/dt/dd construct at the top of the status page.

Modified:
tomcat/connectors/trunk/jk/native/common/jk_status.c

Modified: tomcat/connectors/trunk/jk/native/common/jk_status.c
URL: 
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/common/jk_status.c?rev=434141&r1=434140&r2=434141&view=diff
==
--- tomcat/connectors/trunk/jk/native/common/jk_status.c (original)
+++ tomcat/connectors/trunk/jk/native/common/jk_status.c Wed Aug 23 12:51:31 
2006
@@ -887,28 +887,79 @@
 int refresh = status_int("refresh", s->query_string, -1);
 s->start_response(s, 200, "OK", headers_names, headers_vhtml, 3);
 s->write(s, JK_STATUS_HEAD, sizeof(JK_STATUS_HEAD) - 1);
-if (refresh >= 0) {
-jk_printf(s, "\n",
-  refresh, s->req_uri, refresh);
+if (cmd > 1) {
+jk_putv(s, "\nreq_uri, "\">", NULL);
+}
+else if (cmd == 0 && refresh >= 0) {
+jk_printf(s, "\n",
+  refresh, s->req_uri, s->query_string);
 }
 if (p->s_worker->css) {
 jk_putv(s, "\ns_worker->css, "\" />\n", NULL);
 }
 s->write(s, JK_STATUS_HEND, sizeof(JK_STATUS_HEND) - 1);
-jk_puts(s, "JK Status Manager for ");
-jk_puts(s, s->server_name);
-jk_puts(s, "\n\n");
-jk_putv(s, "Server Version: ",
-s->server_software, "\n", NULL);
-jk_putv(s, "JK Version: ",
-JK_VERSTRING, "\n\n", NULL);
-/* Step 2: Display configuration */
-display_workers(s, p->s_worker, worker, l);
-
-
+if ( cmd <= 1 ) {
+jk_puts(s, "JK Status Manager for ");
+jk_puts(s, s->server_name);
+jk_puts(s, "\n\n");
+jk_putv(s, "Server Version:",
+s->server_software, "\n", NULL);
+jk_putv(s, "JK Version:",
+JK_VERSTRING, "\n\n", NULL);
+}
+if ( cmd == 0 ) {
+jk_putv(s, "[req_uri, NULL);
+if (refresh >= 0) {
+char *buf = jk_pool_alloc(s->pool, sizeof(char *) * 
BIG_POOL_SIZE);
+const char *str = s->query_string;
+int result = 0;
+int scan = 0;
+
+while (str[scan] != 0) {
+if (strncmp(&str[scan], "refresh=", 8) == 0) {
+scan += 8;
+while (str[scan] != 0 && str[scan] != '&')
+scan++;
+if (str[scan] == '&')
+scan++;
+}
+else {
+if (result > 0 && str[scan] != 0 && str[scan] != 
'&') {
+buf[result] = '&';
+result++;
+}
+while (str[scan] != 0 && str[scan] != '&') {
+buf[result] = str[scan];
+result++;
+scan++;
+}
+if (str[scan] == '&')
+scan++;
+}
+}
+buf[result] = 0;
+
+if (buf && buf[0])
+jk_putv(s, "?", buf, NULL);
+jk_puts(s, "\">stop");
+}
+else {
+jk_puts(s, "?");
+if (s->query_string && s->query_string[0])
+jk_putv(s, s->query_string, "&", NULL);
+jk_puts(s, "refresh=10\">start");
+}
+jk_puts(s, " auto update]");
+}
+if ( cmd <= 1 ) {
+/* Step 2: Display configuration */
+display_workers(s, p->s_worker, worker, l);
+}
+
 s->write(s, JK_STATUS_BEND, sizeof(JK_STATUS_BEND) - 1);
-
+
 }
 else if (mime == 1) {
 s->start_response(s, 200, "OK", headers_names, headers_vxml, 3);



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

stale RELEASE-NOTES commentary

[William A. Rowe, Jr.]

...at least in 4.1.31...

  GLIBC 2.2 / Linux 2.4 users should also define an environment variable:
  export LD_ASSUME_KERNEL=2.2.5

  Additionally, Redhat 9.0 users should use the same setting, to avoid stability
  problems.

This is really, really horrific advice.  A comment to for the user to follow
the recommendations in the README would really be better.

LD_ASSUME_KERNEL usually makes an ass of the one who uses it, in the end
(with all sorts of 'mystery' artifacts and behaviors), and we really should
avoid endorsing it :)


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

Re: stale RELEASE-NOTES commentary

[Yoav Shapira]

Hi,
It's not only in the 4.1.31 release, it's even in the latest stable
5.5.17.  Let's change it in the next releases of 4.x and 5.x, starting
with 5.5.18 which should happen any day now.

I think the advice was decent (and based on empirical evidence IIRC)
when originally issued, but that was more than two years ago, and it's
now stale or worse.  Maybe we should also post a notice for users on
the users mailing list, especially if we're not going to do a 4.x
release for a while...

Yoav

On 8/23/06, William A. Rowe, Jr. <[EMAIL PROTECTED]> wrote:

...at least in 4.1.31...

  GLIBC 2.2 / Linux 2.4 users should also define an environment variable:
  export LD_ASSUME_KERNEL=2.2.5

  Additionally, Redhat 9.0 users should use the same setting, to avoid stability
  problems.

This is really, really horrific advice.  A comment to for the user to follow
the recommendations in the README would really be better.

LD_ASSUME_KERNEL usually makes an ass of the one who uses it, in the end
(with all sorts of 'mystery' artifacts and behaviors), and we really should
avoid endorsing it :)


-
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: stale RELEASE-NOTES commentary

[William A. Rowe, Jr.]

Yoav Shapira wrote:
> Hi,
> It's not only in the 4.1.31 release, it's even in the latest stable
> 5.5.17.  Let's change it in the next releases of 4.x and 5.x, starting
> with 5.5.18 which should happen any day now.
> 
> I think the advice was decent (and based on empirical evidence IIRC)
> when originally issued, but that was more than two years ago, and it's
> now stale or worse.

Worse.  That's the trouble with LD_ASSUME_KERNEL, it's a bandaid that
gets gross and crusty when left on too long :)  When I suggested we point
to README, I ment their corresponding VM's readme, not ours; let the VM
vendor lead or mislead our users and not take ownership of VM quirks.

> Maybe we should also post a notice for users on
> the users mailing list, especially if we're not going to do a 4.x
> release for a while...

It's one reason we moved Announcement (httpd's short summary, similar
to the tomcat RELEASE-NOTES) out of the project tree and tarball, and
host those directly in /dist/httpd/ - they can be fixed/amended after
the release without rerolling.

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

Re: parameters in URL path segments

[James Berry]

Hi Jean-Frederic,

On Aug 23, 2006, at 1:24 PM, Jean-frederic Clere wrote:


James Berry wrote:

Jean-Frederic, Bill, Remy,

I didn't get any response to this, but would really like to hear  
your  thoughts on this issue of parameters within URL path  
segments, which  tomcat current does not allow. Can you give me  
any feedback?


http://example.com/this;biz=bar;foo/that;v=1.1/whatever
The question is to which "context" such a request has to be mapped?
http://example.com/this/that and servlet whatever?


My response is that the tomcat should be completely blind to  
"parameters". Basically, to Tomcat's perspective, they don't exist.  
There is nothing any more special about "this;biz=bar" than  
"this,biz=bar" or "this-biz-bar".


So if there is no context with the name "this;biz=bar" then tomcat  
should do whatever it does when there is no context  
"undefinedcontext". Same with servlet mapping.


Tomcat should be blind to the very existence of parameters because it  
doesn't place any meaning on them. And frankly, since it doesn't, I'm  
probably not very likely to try to give you a url such as that one,  
because there's no reason to make such an ugly url, but I guess it  
makes a good argument, and perhaps a good example.


A more realistic url I might use is:

	http://example.com/context/servlet/sega;with=parameters/ 
segb;v=1.0;b;c/segc


In such a case, my servlet would would parse the pathinfo and do  
something meaningful with the parameters.


My point, however, is that currently I cannot do the later, because  
tomcat is trying to be too smart. It doesn't support any meaning for  
the parameter syntax, and so, rather than tossing any path that  
contains parameters, it should just be blind to the fact that they  
are there. If somebody creates a url scheme that uses them, Tomcat  
shouldn't stand in their way.


James


What do you want to do will biz=bar and foo?
v=1.1... means that you want version 1.1 of  that, no?

Cheers

Jean-Frederic



Thanks!

James

On Aug 21, 2006, at 8:42 PM, James Berry wrote:


On Aug 21, 2006, at 6:26 PM, James Berry wrote:


Guys,

Sorry to open up this subject again. I've just read the mails  
in  this thread:


http://marc.theaimsgroup.com/?l=tomcat- 
dev&m=115344110306194&w=2
http://marc.theaimsgroup.com/?l=tomcat- 
dev&m=115346837428224&w=2


Though I can't say I paid particular attention to the jkmount   
situation (and so I can't testify as to how treatment of such   
parameters might affect that), I can say that I'd like to be  
able  to use ;parameter=value in my path segments in a tomcat  
environment:


http://example.com/this;biz=bar;foo/that;v=1.1/whatever

To me, this looks completely valid per rfc 2396, 2616, and  
3986,  and it's a surprise to me that tomcat strips any path  
following  the first such parameter.


I would like to see tomcat essentially ignore the fact that ';'   
exists in a path segment, and pass it on into the servlet   
unmodified to do with as it pleases.



In fact, I don't see any motivation for any special handling of   
semicolon vs any other of the other sub-delims characters, none  
of  which tomcat does anything special with. Comma and Plus are  
allowed  in path segments, for instance; why is semicolon  
treated  differently? The more recent RFCs say that there is  
nothing special  that the server/container should do with such a  
character when it  appears in a path segment.


Obviously, of course, there would be places where it would be  
plain  wrong to place such a parameter/character (if it didn't  
map to a  servlet, or to a file, or...) but there are other  
places (in extra  path segments in pathInfo, for instance) where  
the interpretation  of such characters should NOT BE made by the  
server, but by the  ultimate consumer of those bits. Therefore,  
the server should  simply not place any special meaning on such  
characters in any path  segment.




I'm inspired by the following paragraph in G.4 of rfc 2396:

Extensive testing of current client applications  
demonstrated that

   the majority of deployed systems do not use the ";" character to
   indicate trailing parameter information, and that the  
presence  of a
   semicolon in a path segment does not affect the relative   
parsing of
   that segment.  Therefore, parameters have been removed as a   
separate
   component and may now appear in any path segment.  Their  
influence

   has been removed from the algorithm for resolving a relative URI
   reference.  The resolution examples in Appendix C have been   
modified

   to reflect this change.

And also by the following from rfc 3986:

   Aside from dot-segments in hierarchical paths, a path segment is
   considered opaque by the generic syntax.  URI producing   
applications
   often use the reserved characters allowed in a segment to  
delimit
   scheme-specific or dereference-handler-specific  
subcomponents.   For
   example, the semicolon (";") and equals ("=") reserved   

Re: possible mod_jk "feature"

[Filip Hanik - Dev Lists]

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.



I would prefer the more useful 3 param connections/pool sizing I
suggested. I had a look at the code and it doesn't look very
complicated. I have a couple of open commits for the weekend and most
likely I've got the time to implement and document the "new" pool
behaviour. Furthermore there will be no need to break old pool configs,
although we add more functionality.
  
I like ideals and ideas too, however, I believe Jim presented a very 
simple patch, that solves a very *real* problem in a very simple manner,
very simple -> very real -> very simple, I like the simple part of this 
patch.


Leave it up to the users to figure out if they want it or not. For those 
that believe in the philosophy you present, will simply never use it. 
For those who are struggling with firewall problems today, can get 
instant relief.


Filip


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

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

[rjung]

Author: rjung
Date: Wed Aug 23 14:02:24 2006
New Revision: 434177

URL: http://svn.apache.org/viewvc?rev=434177&view=rev
Log:
Cleanup of the code structure of the service method.
Adding TACE, JK_LOG_NULL_PARAMS and do the same null pointer
checks in all service methods.
95% of the diff log comes from changed indentation due to
deleted "if" statements.

Modified:
tomcat/connectors/trunk/jk/native/common/jk_ajp12_worker.c
tomcat/connectors/trunk/jk/native/common/jk_ajp_common.c
tomcat/connectors/trunk/jk/native/common/jk_jni_worker.c
tomcat/connectors/trunk/jk/native/common/jk_lb_worker.c
tomcat/connectors/trunk/jk/native/common/jk_status.c

Modified: tomcat/connectors/trunk/jk/native/common/jk_ajp12_worker.c
URL: 
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/common/jk_ajp12_worker.c?rev=434177&r1=434176&r2=434177&view=diff
==
--- tomcat/connectors/trunk/jk/native/common/jk_ajp12_worker.c (original)
+++ tomcat/connectors/trunk/jk/native/common/jk_ajp12_worker.c Wed Aug 23 
14:02:24 2006
@@ -87,45 +87,50 @@
  jk_ws_service_t *s,
  jk_logger_t *l, int *is_error)
 {
-jk_log(l, JK_LOG_DEBUG, "Into jk_endpoint_t::service");
+ajp12_endpoint_t *p = e->endpoint_private;
+unsigned int attempt;
+int rc = -1;
+/*
+ * AJP12 protocol is not recoverable.
+ */
 
-if (e && e->endpoint_private && s && is_error) {
-ajp12_endpoint_t *p = e->endpoint_private;
-unsigned int attempt;
-/*
- * AJP12 protocol is not recoverable.
- */
+JK_TRACE_ENTER(l);
+ 
+if (is_error)
 *is_error = JK_HTTP_SERVER_ERROR;
+if (!e || !e->endpoint_private || !s || !is_error) {
+JK_LOG_NULL_PARAMS(l);
+JK_TRACE_EXIT(l);
+return JK_FALSE;
+}
 
-for (attempt = 0; attempt < p->worker->connect_retry_attempts;
- attempt++) {
-p->sd =
-jk_open_socket(&p->worker->worker_inet_addr,
-   JK_FALSE, -1, 0, l);
+for (attempt = 0; attempt < p->worker->connect_retry_attempts;
+ attempt++) {
+p->sd =
+jk_open_socket(&p->worker->worker_inet_addr,
+   JK_FALSE, -1, 0, l);
 
-jk_log(l, JK_LOG_DEBUG, "In jk_endpoint_t::service, sd = %d",
-   p->sd);
-if (IS_VALID_SOCKET(p->sd)) {
-break;
-}
-}
+jk_log(l, JK_LOG_DEBUG, "In jk_endpoint_t::service, sd = %d",
+   p->sd);
 if (IS_VALID_SOCKET(p->sd)) {
-
-jk_sb_open(&p->sb, p->sd);
-if (ajpv12_handle_request(p, s, l)) {
-jk_log(l, JK_LOG_DEBUG,
-   "In jk_endpoint_t::service, sent request");
-return ajpv12_handle_response(p, s, l);
-}
+break;
 }
-jk_log(l, JK_LOG_ERROR, "In jk_endpoint_t::service, Error sd = %d",
-   p->sd);
 }
-else {
-jk_log(l, JK_LOG_ERROR,
-   "In jk_endpoint_t::service, NULL parameters");
+if (IS_VALID_SOCKET(p->sd)) {
+
+jk_sb_open(&p->sb, p->sd);
+if (ajpv12_handle_request(p, s, l)) {
+jk_log(l, JK_LOG_DEBUG,
+   "In jk_endpoint_t::service, sent request");
+rc = ajpv12_handle_response(p, s, l);
+JK_TRACE_EXIT(l);
+return rc;
+}
 }
+jk_log(l, JK_LOG_ERROR, "In jk_endpoint_t::service, Error sd = %d",
+   p->sd);
 
+JK_TRACE_EXIT(l);
 return JK_FALSE;
 }
 

Modified: tomcat/connectors/trunk/jk/native/common/jk_ajp_common.c
URL: 
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/common/jk_ajp_common.c?rev=434177&r1=434176&r2=434177&view=diff
==
--- tomcat/connectors/trunk/jk/native/common/jk_ajp_common.c (original)
+++ tomcat/connectors/trunk/jk/native/common/jk_ajp_common.c Wed Aug 23 
14:02:24 2006
@@ -1654,152 +1654,152 @@
 int i, err;
 ajp_operation_t oper;
 ajp_operation_t *op = &oper;
+ajp_endpoint_t *p;
 
 JK_TRACE_ENTER(l);
 
 if (is_error)
 *is_error = JK_HTTP_SERVER_ERROR;
+if (!e || !e->endpoint_private || !s || !is_error) {
+JK_LOG_NULL_PARAMS(l);
+JK_TRACE_EXIT(l);
+return JK_FALSE;
+}
 
-if (e && e->endpoint_private && s && is_error) {
-ajp_endpoint_t *p = e->endpoint_private;
-op->request = jk_b_new(&(p->pool));
-jk_b_set_buffer_size(op->request, DEF_BUFFER_SZ);
-jk_b_reset(op->request);
-
-op->reply = jk_b_new(&(p->pool));
-jk_b_set_buffer_size(op->reply, DEF_BUFFER_SZ);
-jk_b_reset(op->reply);
-
-op->post = jk_b_new(&(p->pool));
-jk_b_set_buffer_size(op->post, DEF_BUFFER_SZ);
-  

Re: stale RELEASE-NOTES commentary

[Yoav Shapira]

Hi,


It's one reason we moved Announcement (httpd's short summary, similar
to the tomcat RELEASE-NOTES) out of the project tree and tarball, and
host those directly in /dist/httpd/ - they can be fixed/amended after
the release without rerolling.


I don't mind doing the same with Tomcat.  We can actually update the
file in the filesystem now, so that the web site is updated.  The file
on the site will be different from what one would get by running the
docs generation ant target, but it's probably worth it for this case.
If we do this, we have to remember to also update it in SVN.

Yoav

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

Re: parameters in URL path segments

[William A. Rowe, Jr.]

James Berry wrote:
> 
> My response is that the tomcat should be completely blind to
> "parameters". Basically, to Tomcat's perspective, they don't exist.
> There is nothing any more special about "this;biz=bar" than
> "this,biz=bar" or "this-biz-bar".

But, of course, your access control does call out a segment this/,
then the segment this;biz=bar/ would escape that access control,
so in some ways it is *quite* special; parameters are extra metadata.

> Tomcat should be blind to the very existence of parameters because it
> doesn't place any meaning on them.

I agree that an application could add meaning to a parameter, but do
consider the first rule of URI namespace which is that each and every
URI should be canonical and unique.  Returning the same 200 OK result
with the same document for everything under /abuseme means that a
crawler can end up with /abuseme/1 /abuseme/2 /abuseme/3 ... in all
sorts of nasty recursive situations.

Because Tomcat and Apache are blind to parameters, the connector -should-
reject them.  When Tomcat/Apache are able to treat your "this;biz=bar"
example the same as "this" for the purpose of access control, then they
can be enabled in an opaque manner that lets the application determine
their meaning and context.


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

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

[rjung]

Author: rjung
Date: Wed Aug 23 14:15:03 2006
New Revision: 434185

URL: http://svn.apache.org/viewvc?rev=434185&view=rev
Log:
Remove obsolete parameter from get_most_suitable_worker().

Modified:
tomcat/connectors/trunk/jk/native/common/jk_lb_worker.c

Modified: tomcat/connectors/trunk/jk/native/common/jk_lb_worker.c
URL: 
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/common/jk_lb_worker.c?rev=434185&r1=434184&r2=434185&view=diff
==
--- tomcat/connectors/trunk/jk/native/common/jk_lb_worker.c (original)
+++ tomcat/connectors/trunk/jk/native/common/jk_lb_worker.c Wed Aug 23 14:15:03 
2006
@@ -492,7 +492,6 @@
 
 static worker_record_t *get_most_suitable_worker(lb_worker_t * p,
  jk_ws_service_t *s,
- int attempt,
  jk_logger_t *l)
 {
 worker_record_t *rc = NULL;
@@ -642,7 +641,7 @@
 
 while (num_of_workers) {
 worker_record_t *rec =
-get_most_suitable_worker(p->worker, s, attempt, l);
+get_most_suitable_worker(p->worker, s, l);
 int rc;
 /* Do not reuse previous worker, because
  * that worker already failed.



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

Re: parameters in URL path segments

[James Berry]

Hi William,

On Aug 23, 2006, at 2:05 PM, William A. Rowe, Jr. wrote:


James Berry wrote:


My response is that the tomcat should be completely blind to
"parameters". Basically, to Tomcat's perspective, they don't exist.
There is nothing any more special about "this;biz=bar" than
"this,biz=bar" or "this-biz-bar".


But, of course, your access control does call out a segment this/,
then the segment this;biz=bar/ would escape that access control,
so in some ways it is *quite* special; parameters are extra metadata.


Perhaps I'm not understanding you. Yes, in this case the segment name  
should be "this;biz=bar" and not "this". If there were access control  
on segment "this" then "this;biz=bar" should not follow that access  
control.


In what way, and why, does "this;biz=bar" escape access control any  
more than "this-funny-name" would? If it was "this,biz=bar" would it?





Tomcat should be blind to the very existence of parameters because it
doesn't place any meaning on them.


I agree that an application could add meaning to a parameter, but do
consider the first rule of URI namespace which is that each and every
URI should be canonical and unique.  Returning the same 200 OK result
with the same document for everything under /abuseme means that a
crawler can end up with /abuseme/1 /abuseme/2 /abuseme/3 ... in all
sorts of nasty recursive situations.


Again, I'm not following you, perhaps. I can certainly do that today,  
by passing all sorts of information in pathinfo following any url.


Because Tomcat and Apache are blind to parameters, the connector - 
should-

reject them.  When Tomcat/Apache are able to treat your "this;biz=bar"
example the same as "this" for the purpose of access control, then  
they

can be enabled in an opaque manner that lets the application determine
their meaning and context.


So maybe this is the crux of it. Why/where is it that "this;biz=bar"  
cannot be treated the same for the purposes of access control as  
"this"? The URL spec says that these are equally valid, and that  
"this,biz=bar" is equally valid (and suggests too that it might also  
be used for passing parameters) but to my understanding, that should  
be no concern of tomcat's.


James

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

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

[rjung]

Author: rjung
Date: Wed Aug 23 14:30:15 2006
New Revision: 434189

URL: http://svn.apache.org/viewvc?rev=434189&view=rev
Log:
Moving getting the session id out of get_most_suitable_worker
into the service method. Doing it once is enough.
Also so minor cleanups.

Modified:
tomcat/connectors/trunk/jk/native/common/jk_lb_worker.c

Modified: tomcat/connectors/trunk/jk/native/common/jk_lb_worker.c
URL: 
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/common/jk_lb_worker.c?rev=434189&r1=434188&r2=434189&view=diff
==
--- tomcat/connectors/trunk/jk/native/common/jk_lb_worker.c (original)
+++ tomcat/connectors/trunk/jk/native/common/jk_lb_worker.c Wed Aug 23 14:30:15 
2006
@@ -491,11 +491,11 @@
 }
 
 static worker_record_t *get_most_suitable_worker(lb_worker_t * p,
+ char *sessionid,
  jk_ws_service_t *s,
  jk_logger_t *l)
 {
 worker_record_t *rc = NULL;
-char *sessionid = NULL;
 int r;
 
 JK_TRACE_ENTER(l);
@@ -513,12 +513,6 @@
 return NULL;
 }
 }
-else if (p->s->sticky_session) {
-/* Use sessionid only if sticky_session is
- * defined for this load balancer
- */
-sessionid = get_sessionid(s);
-}
 if (p->lblock == JK_LB_LOCK_PESSIMISTIC)
 r = jk_shm_lock();
 else {
@@ -533,11 +527,6 @@
 }
 if (sessionid) {
 char *session = sessionid;
-if (JK_IS_DEBUG_LEVEL(l)) {
-jk_log(l, JK_LOG_DEBUG,
-   "total sessionid is %s",
-   sessionid ? sessionid : "empty");
-}
 while (sessionid) {
 char *next = strchr(sessionid, ';');
 char *session_route = NULL;
@@ -612,6 +601,7 @@
 int attempt = 0;
 int num_of_workers;
 worker_record_t *prec = NULL;
+char *sessionid = NULL;
 
 JK_TRACE_ENTER(l);
 
@@ -634,14 +624,20 @@
 jk_b_set_buffer_size(s->reco_buf, DEF_BUFFER_SZ);
 jk_b_reset(s->reco_buf);
 s->reco_status = RECO_INITED;
+if (p->worker->s->sticky_session) {
+/* Use sessionid only if sticky_session is
+ * defined for this load balancer
+ */
+sessionid = get_sessionid(s);
+}
 if (JK_IS_DEBUG_LEVEL(l))
 jk_log(l, JK_LOG_DEBUG,
-   "service sticky_session=%d",
-   p->worker->s->sticky_session);
+   "service sticky_session=%d id='%s'",
+   p->worker->s->sticky_session, sessionid ? sessionid : "empty");
 
 while (num_of_workers) {
 worker_record_t *rec =
-get_most_suitable_worker(p->worker, s, l);
+get_most_suitable_worker(p->worker, sessionid, s, l);
 int rc;
 /* Do not reuse previous worker, because
  * that worker already failed.
@@ -694,11 +690,13 @@
 /* Update partial reads and writes if any */
 rec->s->readed += rd;
 rec->s->transferred += wr;
-if (p->worker->lbmethod == JK_LB_METHOD_TRAFFIC)
+if (p->worker->lbmethod == JK_LB_METHOD_TRAFFIC) {
 rec->s->lb_value += (rd+wr)*rec->s->lb_mult;
-else if (p->worker->lbmethod == JK_LB_METHOD_BUSYNESS)
-if (rec->s->lb_value >= rec->s->lb_mult)
+}
+else if (p->worker->lbmethod == JK_LB_METHOD_BUSYNESS) {
+if (rec->s->lb_value >= rec->s->lb_mult) {
 rec->s->lb_value -= rec->s->lb_mult;
+}
 else {
 rec->s->lb_value = 0;
 if (JK_IS_DEBUG_LEVEL(l)) {
@@ -714,6 +712,7 @@
rec->s->lb_mult);
 }
 }
+}
 
 /* When returning the endpoint mark the worker as not busy.
  * We have at least one endpoint free
@@ -742,7 +741,7 @@
 else {
 /* If we can not get the endpoint
  * mark the worker as busy rather then
- * as in error if the attemp number is
+ * as in error if the attempt number is
  * greater then the number of retries.
  */
 attempt++;
@@ -754,7 +753,7 @@
"could not get free endpoint for worker %s (attempt 
%d)",
rec->s->name, attempt);
 /* In case of attempt > num of workers sleep for 100 ms
- * on each consequtive attempt.
+ * on each consecutive attempt.
  */
 if (attempt > (int)p->worker->num_of_workers)
 jk_sleep_def();

Re: parameters in URL path segments

[William A. Rowe, Jr.]

James Berry wrote:
> 
>> Because Tomcat and Apache are blind to parameters, the connector -should-
>> reject them.  When Tomcat/Apache are able to treat your "this;biz=bar"
>> example the same as "this" for the purpose of access control, then they
>> can be enabled in an opaque manner that lets the application determine
>> their meaning and context.
> 
> So maybe this is the crux of it. Why/where is it that "this;biz=bar"
> cannot be treated the same for the purposes of access control as "this"?
> The URL spec says that these are equally valid, and that "this,biz=bar"
> is equally valid (and suggests too that it might also be used for
> passing parameters) but to my understanding, that should be no concern
> of tomcat's.

BUT today's parsers don't do that.  So any DENY rule on "this" would let
"this;biz=bar" slip through, while the handler might process "this" and
ignore parameters entirely.

Now understand I'm not a big fan of deny rules (deny all, then always
selectively grant access ;-)  But we can't ignore that they exist, and
if parameters must be treated independently of the resource that they
modify, then /myfolder;v=1.1/records.doc;f=rtf must parse against any
access control rules of /myfolder/records.doc, which means they need
a canonical form for access control independent of their parameters.

I need to research, but it's probably doable.  It's not doable by just
tweaking the code in mod_jk, however.




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

Re: parameters in URL path segments

[James Berry]

On Aug 23, 2006, at 2:22 PM, James Berry wrote:

Tomcat should be blind to the very existence of parameters  
because it

doesn't place any meaning on them.


Perhaps I should clarify that when I say tomcat should be "blind" to  
parameters, perhaps I really should have said "Tomcat should not be  
discerning of parameters". It should completely _not_recognize_  
parameters. It's not that it shouldn't see them, but that it  
shouldn't recognize them as anything but a string of characters. It  
should treat the strings of characters "one", "two", "one+two",  
"one;two", "one;two=three", "one,two=three", etc, no differently  
(yes, they are distinct strings, but none is more special than any  
other). rfc 3986 basically says they should be no distinctions  
between these segment names.


James

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

DO NOT REPLY [Bug 40307] New: - error page not shown when exception occurs in nested custom JSP tag after jsp:include

[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=40307

   Summary: error page not shown when exception occurs in nested
custom JSP tag after jsp:include
   Product: Tomcat 5
   Version: 5.5.17
  Platform: PC
OS/Version: Windows 2000
Status: NEW
  Severity: normal
  Priority: P2
 Component: Jasper
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]
CC: [EMAIL PROTECTED]


I have a JSP page that contains a custom JSP tag nested within a custom JSP 
body tag, which occurs after a jsp:include tag with flush="true".  When an 
exception is thrown from the nested custom JSP tag, I don't see the error page 
associated with the JSP page.  This problem is only reproducible in certain 
circumstances, which I will explain below.

I have reproduced it in Tomcat 5.5.17.

Here is the code for the JSP page (nestedTagError.jsp):

**
<%@ taglib uri="/WEB-INF/tlds/testtagerrors.tld" prefix="testtagerrors"%>
<%@ page errorPage="errors.jsp"%>



Nested Tag Page







  


Nested Tag Page



**

The noBodyTagWithError tag is the one that throws the error.  Here is the code 
for the tag class:

**
package testtagerrors;

import java.io.IOException;

import javax.servlet.jsp.tagext.TagSupport;
import javax.servlet.jsp.JspException;

public class NoBodyTagWithError extends TagSupport {
public int doStartTag() throws JspException {

if (true)
throw new RuntimeException("RuntimeException thrown from 
NoBodyTagWithError.doStartTag");

return SKIP_BODY;
}
}
**

simpleBufferedBodyTag is a body tag that buffers its contents and then writes 
them out in the doAfterBody method:

**
package testtagerrors;

import javax.servlet.jsp.tagext.*;
import javax.servlet.jsp.JspException;
import javax.servlet.jsp.JspWriter;
import java.io.IOException;

public class SimpleBufferedBodyTag extends BodyTagSupport {
public int doStartTag() throws JspException {
return EVAL_BODY_BUFFERED;
}

public int doAfterBody() throws JspException {
try {
JspWriter out = getPreviousOut();
BodyContent bodyContent = getBodyContent();
bodyContent.writeOut(out);
bodyContent.clearBody();
} catch (IOException ioe) {
throw new JspException (ioe);
}
return SKIP_BODY;
}
}
**

included.jsp just contains some simple HTML content:

**

Some included content.

**

Finally, errors.jsp is a simple error page:

**
<%@ page isErrorPage="true"%>



Error Page




ERROR

<%= exception.getMessage() %>


**

When I request nestedTagError.jsp, I get the following output:

**



Nested Tag Page



**

This is rendered as a blank page in the browser.  I would expect to get:

**



Nested Tag Page









Error Page




ERROR

RuntimeException thrown from NoBodyTagWithError.doStartTag



**

This is indeed what I get if I replace the simpleBufferedBodyTag in 
nestedTagError.jsp with anothyer custom JSP tag, simpleBodyTag, which has the 
following code:

**
package testtagerrors;

import javax.servlet.jsp.tagext.*;
import javax.servlet.jsp.JspException;

public class SimpleBodyTag extends BodyTagSupport {
public int doStartTag() throws JspException {
return EVAL_BODY_INCLUDE;
}
}
**

After doing some testing, there are 4 conditions required to reproduce this 
behavior:

1) The tag that throws the error (noBodyTagWithError) mu

DO NOT REPLY [Bug 40307] - error page not shown when exception occurs in nested custom JSP tag after jsp:include

[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=40307





--- Additional Comments From [EMAIL PROTECTED]  2006-08-23 22:05 ---
Created an attachment (id=18748)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=18748&action=view)
A test case that should reproduce the issue on Tomcat 5.5.17.


-- 
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: parameters in URL path segments

[James Berry]

On Aug 23, 2006, at 2:40 PM, William A. Rowe, Jr. wrote:


James Berry wrote:


Because Tomcat and Apache are blind to parameters, the connector - 
should-
reject them.  When Tomcat/Apache are able to treat your  
"this;biz=bar"
example the same as "this" for the purpose of access control,  
then they
can be enabled in an opaque manner that lets the application  
determine

their meaning and context.


So maybe this is the crux of it. Why/where is it that "this;biz=bar"
cannot be treated the same for the purposes of access control as  
"this"?
The URL spec says that these are equally valid, and that  
"this,biz=bar"

is equally valid (and suggests too that it might also be used for
passing parameters) but to my understanding, that should be no  
concern

of tomcat's.


BUT today's parsers don't do that.  So any DENY rule on "this"  
would let
"this;biz=bar" slip through, while the handler might process "this"  
and

ignore parameters entirely.


So such a deny rule on "this" would currently let "this;biz=bar"  
through, and would also let "thisthatandtheotherthing" through too,  
right?


I see nothing wrong with that: if follows my assertion that semicolon  
parameters simply should not be treated any differently.



Now understand I'm not a big fan of deny rules (deny all, then always
selectively grant access ;-)  But we can't ignore that they exist, and
if parameters must be treated independently of the resource that they


What I'm saying is that they should not be treated independently or  
differently. They should be treated not as metadata, but as part of  
the segment.



modify, then /myfolder;v=1.1/records.doc;f=rtf must parse against any
access control rules of /myfolder/records.doc, which means they need
a canonical form for access control independent of their parameters.


The situation today is that if I form one url that looks like:

/myfolder;v=1.1/records.doc;f=rtf

and another that looks like:

/myfolder,v=1.1/records.doc,f=rtf

and another that looks like:

/myfolder+v=1.1/records.doc+f=rtf

The one that uses semicolons is mangled by Tomcat, while the other  
two are not. What I'm claiming is that this is a bug, because  
parameters should not be treated differently by tomcat; it can do  
nothing different with the first url than it can with the second or  
third url, and it should leave the distinction to code that can,  
rather than assuming it knows something that it doesn't.


The rfcs, to me, are saying that http servers shouldn't treat segment  
parameters in any special way. And until they should, or can, or  
really want to, Tomcat shouldn't reject a semicolon when it doesn't  
reject a comma.



I need to research, but it's probably doable.  It's not doable by just
tweaking the code in mod_jk, however.




-
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: parameters in URL path segments

[William A. Rowe, Jr.]

James Berry wrote:
> 
> On Aug 23, 2006, at 2:40 PM, William A. Rowe, Jr. wrote:
> 
>> James Berry wrote:
>>>
>>> So maybe this is the crux of it. Why/where is it that "this;biz=bar"
>>> cannot be treated the same for the purposes of access control as "this"?
>>> The URL spec says that these are equally valid, and that "this,biz=bar"
>>> is equally valid (and suggests too that it might also be used for
>>> passing parameters) but to my understanding, that should be no concern
>>> of tomcat's.
>>
>> BUT today's parsers don't do that.  So any DENY rule on "this" would let
>> "this;biz=bar" slip through, while the handler might process "this" and
>> ignore parameters entirely.
> 
> So such a deny rule on "this" would currently let "this;biz=bar"
> through, and would also let "thisthatandtheotherthing" through too, right?
> 
> I see nothing wrong with that: if follows my assertion that semicolon
> parameters simply should not be treated any differently.
> 
> What I'm saying is that they should not be treated independently or
> differently. They should be treated not as metadata, but as part of the
> segment.

To be 100% clear; this is what Apache httpd does today.  If you ask for
foo.html;v=1 it will open the -file- foo.html;v=1 or fail.  What jk or
tomcat does with the same is up to those components, but httpd has no
magic whatsoever which is what you want.  You would like the same of
Tomcat.  But...

...this would be valid if /servlet/MyApplication;v=1 invokes the class
MyApplication;v=1 and not MyApplication with a parameter of v=1.

If it invokes the class MyApplication then we can't follow your philosophy
since the permissions were likely to apply to the servlet class and not
to the precise syntax the user called MyApplication with.


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

Re: parameters in URL path segments

[James Berry]

Hi Bill,

On Aug 23, 2006, at 3:35 PM, William A. Rowe, Jr. wrote:


James Berry wrote:

What I'm saying is that they should not be treated independently or
differently. They should be treated not as metadata, but as part  
of the

segment.


To be 100% clear; this is what Apache httpd does today.  If you ask  
for

foo.html;v=1 it will open the -file- foo.html;v=1 or fail.  What jk or
tomcat does with the same is up to those components, but httpd has no
magic whatsoever which is what you want.  You would like the same of
Tomcat.  But...

...this would be valid if /servlet/MyApplication;v=1 invokes the class
MyApplication;v=1


Yes, I would expect it to invoke the class "MyApplication;v=1". I  
hadn't considered the other behavior.



and not MyApplication with a parameter of v=1.
If it invokes the class MyApplication then we can't follow your  
philosophy
since the permissions were likely to apply to the servlet class and  
not

to the precise syntax the user called MyApplication with.


That's not  what I'm asking for. It's an interesting idea, but as  
you've pointed out, might require significantly more work and thought  
to get right.


I'm simply asking that Tomcat not mangle urls that contain  
parameters. The cases in which I'd be interested in using parameters  
are below the servlet level (in pathinfo), so invoking servlets with  
such parameters, while conceivably interesting, is by no means  
necessary.


I'd ask that, for now, special case handling of parameters be  
removed. If at some point in the future support was added to  
specially parse parameters and pass them into servlets, then I'd  
assume there would have to be special configuration to enable such  
behavior. So allowing the more wide open general case behavior that  
I'm asking for now wouldn't prevent such support in the future, as  
parameters to servlets would presumably only be parsed if such  
behavior was enabled.


Given the present behavior, however, any use of parameters is  
disallowed, which seems overly restrictive, and certainly prevents a  
broad range of interesting application for segment parameters.


James




-
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]

svn commit: r434252 - /tomcat/container/branches/tc4.1.x/RELEASE-NOTES-4.1.txt

[markt]

Author: markt
Date: Wed Aug 23 16:47:06 2006
New Revision: 434252

URL: http://svn.apache.org/viewvc?rev=434252&view=rev
Log:
Update the release notes.

Modified:
tomcat/container/branches/tc4.1.x/RELEASE-NOTES-4.1.txt

Modified: tomcat/container/branches/tc4.1.x/RELEASE-NOTES-4.1.txt
URL: 
http://svn.apache.org/viewvc/tomcat/container/branches/tc4.1.x/RELEASE-NOTES-4.1.txt?rev=434252&r1=434251&r2=434252&view=diff
==
--- tomcat/container/branches/tc4.1.x/RELEASE-NOTES-4.1.txt (original)
+++ tomcat/container/branches/tc4.1.x/RELEASE-NOTES-4.1.txt Wed Aug 23 16:47:06 
2006
@@ -2337,7 +2337,6 @@
 * Tomcat 4.1 Standard APIs Available
 * Tomcat 4.1 and XML Parsers
 * Web application reloading and static fields in shared libraries
-* Tomcat on Linux
 * Enabling SSI and CGI Support
 * Security manager URLs
 * Symlinking static resources
@@ -2373,11 +2372,11 @@
 A standard installation of Tomcat 4 makes all of the following APIs available
 for use by web applications (by placing them in "common/lib" or "shared/lib"):
 * activation.jar (Java Activation Framework)
-* ant.jar (Apache Ant 1.5.1)
-* commons-collections.jar (Commons Collections 2.1)
-* commons-dbcp.jar (Commons DBCP 1.0)
-* commons-logging-api.jar (Commons Logging 1.0.2)
-* commons-pool.jar (Commons Pool 1.0)
+* ant.jar (Apache Ant 1.6.5)
+* commons-collections.jar (Commons Collections 3.2)
+* commons-dbcp.jar (Commons DBCP 1.2.1)
+* commons-logging-api.jar (Commons Logging 1.0.4)
+* commons-pool.jar (Commons Pool 1.3)
 * jasper-compiler.jar (Jasper 2 Compiler)
 * jasper-runtime.jar (Jasper 2 Runtime)
 * jdbc2_0-stdext.jar (JDBC 2.0 Optional Package, javax.sql.*)
@@ -2393,7 +2392,7 @@
 putting unpacked classes into a "classes" directory (not created by default),
 or by placing them in JAR files in the "lib" directory.
 
-Tomcat 4.1 also makes available Xerces 2.3.0 to web applications.
+Tomcat 4.1 also makes available Xerces 2.8.0 to web applications.
 
 
 --
@@ -2422,25 +2421,6 @@
 "lib" folder, and classes should be put in the "classes" folder).
 
 

-Tomcat on Linux:

-
-Virtual machine crashes can be experienced when using certain combinations of
-kernel / glibc under Linux with Sun Hotspot 1.2 to 1.3. The crashes were 
-reported to occur mostly on startup. Sun JDK 1.4 does not exhibit the problems,
-and neither does IBM JDK for Linux.
-
-The problems can be fixed by reducing the default stack size. At bash shell, 
-do "ulimit -s 2048"; use "limit stacksize 2048" for tcsh.
-
-GLIBC 2.2 / Linux 2.4 users should also define an environment variable:
-export LD_ASSUME_KERNEL=2.2.5
-
-Additionally, Redhat 9.0 users should use the same setting, to avoid stability
-problems.
-
-
 
 Enabling SSI and CGI Support:
 
@@ -2456,20 +2436,18 @@
   %CATALINA_HOME%\server\lib\servlets-cgi.jar.
 * rename the file %CATALINA_HOME%\server\lib\servlets-ssi.renametojar to
   %CATALINA_HOME%\server\lib\servlets-ssi.jar.
-* in %CATALINA_HOME%\conf\web.xml, uncomment the servlet declarations starting
-  line 165 and 213, as well as the associated servlet mappings 
-  line 265 and 274. Alternately, these servlet declarations and mappings can
-  be added to your web application deployment descriptor.
+* in %CATALINA_HOME%\conf\web.xml, uncomment the servlet declarations as well
+  as the associated servlet mappings. Alternately, these servlet declarations
+  and mappings can be added to your web application deployment descriptor.
 
 On Unix:
 * rename the file $CATALINA_HOME/server/lib/servlets-cgi.renametojar to
   $CATALINA_HOME/server/lib/servlets-cgi.jar.
 * rename the file $CATALINA_HOME/server/lib/servlets-ssi.renametojar to
   $CATALINA_HOME/server/lib/servlets-ssi.jar.
-* in $CATALINA_HOME/conf/web.xml, uncomment the servlet declarations starting
-  line 165 and 213, as well as the associated servlet mappings 
-  line 265 and 274. Alternately, these servlet declarations and mappings can
-  be added to your web application deployment descriptor.
+* in $CATALINA_HOME/conf/web.xml, uncomment the servlet declarations as well
+  as the associated servlet mappings. Alternately, these servlet declarations
+  and mappings can be added to your web application deployment descriptor.
 
 
 -



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

svn commit: r434253 - /tomcat/container/branches/tc4.1.x/BUGS.txt

[markt]

Author: markt
Date: Wed Aug 23 16:50:40 2006
New Revision: 434253

URL: http://svn.apache.org/viewvc?rev=434253&view=rev
Log:
Remove old file.

Removed:
tomcat/container/branches/tc4.1.x/BUGS.txt


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

DO NOT REPLY [Bug 40252] - Different commons-logging version in web app preventing tomcat startup

[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=40252





--- Additional Comments From [EMAIL PROTECTED]  2006-08-24 00:03 ---
This is now working (using commons-logging-1.1). Expect 4.1.34 shortly.

-- 
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]

[RESULT] [VOTE] Release Tomcat 4.1.33 as beta

[Mark Thomas]

All,

This vote passed (thanks to those that voted) but with the help of
Simon Kitching on the commons-dev list bug 40252 has been fully
resolved. Therefore I do not intend to go further with this release
but to go to 4.1.34. This also allows the RELEASE-NOTES changes raised
 earlier today to be included as well.

Mark

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

Re: [RESULT] [VOTE] Release Tomcat 4.1.33 as beta

[Yoav Shapira]

Cool, I was about to ask that we include the RELEASE-NOTES changes in
the next 4.1 cut.  Thanks, and +1,

Yoav

On 8/23/06, Mark Thomas <[EMAIL PROTECTED]> wrote:

All,

This vote passed (thanks to those that voted) but with the help of
Simon Kitching on the commons-dev list bug 40252 has been fully
resolved. Therefore I do not intend to go further with this release
but to go to 4.1.34. This also allows the RELEASE-NOTES changes raised
 earlier today to be included as well.

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]

svn commit: r434283 [2/2] - in /tomcat/container/branches/tc4.1.x/catalina/src/share/org/apache: catalina/ catalina/cluster/ catalina/connector/http/ catalina/connector/http10/ catalina/core/ catalina

[markt]

Modified: 
tomcat/container/branches/tc4.1.x/catalina/src/share/org/apache/naming/resources/ResourceAttributes.java
URL: 
http://svn.apache.org/viewvc/tomcat/container/branches/tc4.1.x/catalina/src/share/org/apache/naming/resources/ResourceAttributes.java?rev=434283&r1=434282&r2=434283&view=diff
==
--- 
tomcat/container/branches/tc4.1.x/catalina/src/share/org/apache/naming/resources/ResourceAttributes.java
 (original)
+++ 
tomcat/container/branches/tc4.1.x/catalina/src/share/org/apache/naming/resources/ResourceAttributes.java
 Wed Aug 23 18:57:51 2006
@@ -229,6 +229,8 @@
 
 /**
  * Is collection.
+ * 
+ * @return value of the collection flag
  */
 public boolean isCollection() {
 if (attributes != null) {
@@ -241,8 +243,6 @@
 
 /**
  * Set collection flag.
- * 
- * @return value of the collection flag
  */
 public void setCollection(boolean collection) {
 this.collection = collection;



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

svn commit: r434285 - /tomcat/jasper/branches/tc4.1.x/build.xml

[markt]

Author: markt
Date: Wed Aug 23 19:01:40 2006
New Revision: 434285

URL: http://svn.apache.org/viewvc?rev=434285&view=rev
Log:
Fix javadoc warnings

Modified:
tomcat/jasper/branches/tc4.1.x/build.xml

Modified: tomcat/jasper/branches/tc4.1.x/build.xml
URL: 
http://svn.apache.org/viewvc/tomcat/jasper/branches/tc4.1.x/build.xml?rev=434285&r1=434284&r2=434285&view=diff
==
--- tomcat/jasper/branches/tc4.1.x/build.xml (original)
+++ tomcat/jasper/branches/tc4.1.x/build.xml Wed Aug 23 19:01:40 2006
@@ -29,6 +29,7 @@
 
 
 
+
   
 
   



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

svn commit: r434291 - /tomcat/container/branches/tc4.1.x/catalina/build.xml

[markt]

Author: markt
Date: Wed Aug 23 19:33:33 2006
New Revision: 434291

URL: http://svn.apache.org/viewvc?rev=434291&view=rev
Log:
Prevent Javadoc warnings when building with Java 5

Modified:
tomcat/container/branches/tc4.1.x/catalina/build.xml

Modified: tomcat/container/branches/tc4.1.x/catalina/build.xml
URL: 
http://svn.apache.org/viewvc/tomcat/container/branches/tc4.1.x/catalina/build.xml?rev=434291&r1=434290&r2=434291&view=diff
==
--- tomcat/container/branches/tc4.1.x/catalina/build.xml (original)
+++ tomcat/container/branches/tc4.1.x/catalina/build.xml Wed Aug 23 19:33:33 
2006
@@ -889,6 +889,7 @@
 
   
 
+
   
 
 



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

svn commit: r434292 - in /tomcat/container/branches/tc4.1.x: RELEASE-NOTES-4.1.txt build.properties.default

[markt]

Author: markt
Date: Wed Aug 23 19:45:02 2006
New Revision: 434292

URL: http://svn.apache.org/viewvc?rev=434292&view=rev
Log:
Final fix for bug 40252 - upgrade to commons-logging 1.1

Modified:
tomcat/container/branches/tc4.1.x/RELEASE-NOTES-4.1.txt
tomcat/container/branches/tc4.1.x/build.properties.default

Modified: tomcat/container/branches/tc4.1.x/RELEASE-NOTES-4.1.txt
URL: 
http://svn.apache.org/viewvc/tomcat/container/branches/tc4.1.x/RELEASE-NOTES-4.1.txt?rev=434292&r1=434291&r2=434292&view=diff
==
--- tomcat/container/branches/tc4.1.x/RELEASE-NOTES-4.1.txt (original)
+++ tomcat/container/branches/tc4.1.x/RELEASE-NOTES-4.1.txt Wed Aug 23 19:45:02 
2006
@@ -155,6 +155,12 @@
 [4.1.33] Commons BeanUtils
  Revert to 1.6.1
 
+[4.1.34] Commons BeanUtils
+ Return to 1.7.0
+
+[4.1.34] Commons Logging
+ Upgrade to 1.1
+
 
 -
 Catalina New Features:
@@ -1621,6 +1627,10 @@
  that prevented web applications from loading if the Commons Logging
  library was present in the web application.
 
+[4.1.34] #40252
+ Commons Logging
+ Return to BeanUtils 1.7.0 since Commons Logging 1.1 resolves the issue
+
 
 
 Coyote Bug Fixes:
@@ -2375,7 +2385,7 @@
 * ant.jar (Apache Ant 1.6.5)
 * commons-collections.jar (Commons Collections 3.2)
 * commons-dbcp.jar (Commons DBCP 1.2.1)
-* commons-logging-api.jar (Commons Logging 1.0.4)
+* commons-logging-api.jar (Commons Logging 1.1)
 * commons-pool.jar (Commons Pool 1.3)
 * jasper-compiler.jar (Jasper 2 Compiler)
 * jasper-runtime.jar (Jasper 2 Runtime)

Modified: tomcat/container/branches/tc4.1.x/build.properties.default
URL: 
http://svn.apache.org/viewvc/tomcat/container/branches/tc4.1.x/build.properties.default?rev=434292&r1=434291&r2=434292&view=diff
==
--- tomcat/container/branches/tc4.1.x/build.properties.default (original)
+++ tomcat/container/branches/tc4.1.x/build.properties.default Wed Aug 23 
19:45:02 2006
@@ -56,11 +56,11 @@
 # --
 
 
-# - Commons Beanutils, version 1.1 to 1.6.1 -
-commons-beanutils.home=${base.path}/commons-beanutils-1.6.1
+# - Commons Beanutils, version 1.1 or later -
+commons-beanutils.home=${base.path}/commons-beanutils-1.7.0
 commons-beanutils.lib=${commons-beanutils.home}
 commons-beanutils.jar=${commons-beanutils.lib}/commons-beanutils.jar
-commons-beanutils.loc=${base-jakarta.loc}/commons/beanutils/binaries/commons-beanutils-1.6.1.tar.gz
+commons-beanutils.loc=${base-jakarta.loc}/commons/beanutils/binaries/commons-beanutils-1.7.0.tar.gz
 
 
 # - Commons Collections, version 1.0 or later -
@@ -90,12 +90,12 @@
 commons-io.loc=${base-jakarta.loc}/commons/io/binaries/commons-io-1.2.tar.gz
 
 
-# - Commons Logging, version 1.0.1 or later -
-commons-logging.home=${base.path}/commons-logging-1.0.4
+# - Commons Logging, version 1.1 or later -
+commons-logging.home=${base.path}/commons-logging-1.1
 commons-logging.lib=${commons-logging.home}
-commons-logging-api.jar=${commons-logging.lib}/commons-logging-api.jar
-commons-logging.jar=${commons-logging.lib}/commons-logging.jar
-commons-logging.loc=${base-jakarta.loc}/commons/logging/binaries/commons-logging-1.0.4.tar.gz
+commons-logging-api.jar=${commons-logging.lib}/commons-logging-api-1.1.jar
+commons-logging.jar=${commons-logging.lib}/commons-logging-1.1.jar
+commons-logging.loc=${base-jakarta.loc}/commons/logging/binaries/commons-logging-1.1.tar.gz
 
 
 # - Java Naming and Directory Interface (JNDI), version 1.2 or later -



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