DO NOT REPLY [Bug 42574] New: - clients blocked on a server

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

   Summary: clients blocked on a server
   Product: Tomcat 5
   Version: 5.0.28
  Platform: PC
OS/Version: Windows XP
Status: NEW
  Severity: blocker
  Priority: P2
 Component: Unknown
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


My Tomcat application is running on a Windows XP server.
A part of this application is an on-line planning.
Sometimes a client try to open the planning, but the planning is never loaded 
(the message "loading" is continually displayed).
The client can open his planning on an other PC.
He can open the planning on his PC with an other simulated server.
The only solution to permits the client to open his planning on his PC is to 
stop the server ( by clicking the cross of the tomcat window only, the tomcat 
stop command don't stop the server), and to restart the server.
I have any error message, any log.
What can block the server for a part of the clients, on their PC only ?

please help me, I don't understand !!

thanks,

-- 
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: r544137 - /tomcat/connectors/trunk/jk/native/common/jk_uri_worker_map.c

[mturk]

Author: mturk
Date: Mon Jun  4 05:08:33 2007
New Revision: 544137

URL: http://svn.apache.org/viewvc?view=rev&rev=544137
Log:
Add simple URI normalizer that can deal with things like %252e%252e. This is 
mostly copy/paste from the IIS module

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

Modified: tomcat/connectors/trunk/jk/native/common/jk_uri_worker_map.c
URL: 
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/common/jk_uri_worker_map.c?view=diff&rev=544137&r1=544136&r2=544137
==
--- tomcat/connectors/trunk/jk/native/common/jk_uri_worker_map.c (original)
+++ tomcat/connectors/trunk/jk/native/common/jk_uri_worker_map.c Mon Jun  4 
05:08:33 2007
@@ -36,6 +36,8 @@
 #define JK_STRCMP   strcmp
 #define JK_STRNCMP  strncmp
 #endif
+#define BAD_REQUEST -1
+#define BAD_PATH-2
 
 
 static const char *uri_worker_map_source_type[] = {
@@ -47,6 +49,116 @@
 NULL
 };
 
+#define JK_ISXDIGIT(x) isxdigit((int)(unsigned char)((x)))
+
+static char x2c(const char *what)
+{
+register char digit;
+
+digit = ((what[0] >= 'A') ?
+ ((what[0] & 0xdf) - 'A') + 10 : (what[0] - '0'));
+digit *= 16;
+digit += ((what[1] >= 'A') ?
+  ((what[1] & 0xdf) - 'A') + 10 : (what[1] - '0'));
+return (digit);
+}
+
+static int unescape_url(char *url)
+{
+register int x, y, badesc, badpath;
+
+badesc = 0;
+badpath = 0;
+for (x = 0, y = 0; url[y]; ++x, ++y) {
+if (url[y] != '%')
+url[x] = url[y];
+else {
+if (!JK_ISXDIGIT(url[y + 1]) || !JK_ISXDIGIT(url[y + 2])) {
+badesc = 1;
+url[x] = '%';
+}
+else {
+url[x] = x2c(&url[y + 1]);
+y += 2;
+if (url[x] == '/' || url[x] == '\0')
+badpath = 1;
+}
+}
+}
+url[x] = '\0';
+if (badesc)
+return BAD_REQUEST;
+else if (badpath)
+return BAD_PATH;
+else
+return 0;
+}
+
+static void normalize_url(char *name)
+{
+int l, w;
+
+/* Four paseses, as per RFC 1808 */
+/* 1. remove ./ path segments */
+
+for (l = 0, w = 0; name[l] != '\0';) {
+if (name[l] == '.' && name[l + 1] == '/'
+&& (l == 0 || name[l - 1] == '/'))
+l += 2;
+else
+name[w++] = name[l++];
+}
+
+/* 2. remove trailing . path, segment */
+if (w == 1 && name[0] == '.')
+w--;
+else if (w > 1 && name[w - 1] == '.' && name[w - 2] == '/')
+w--;
+name[w] = '\0';
+
+/* 3. remove all xx/../ segments. (including leading ../ and /../) */
+l = 0;
+
+while (name[l] != '\0') {
+if (name[l] == '.' && name[l + 1] == '.' && name[l + 2] == '/' &&
+(l == 0 || name[l - 1] == '/')) {
+register int m = l + 3, n;
+
+l = l - 2;
+if (l >= 0) {
+while (l >= 0 && name[l] != '/')
+l--;
+l++;
+}
+else
+l = 0;
+n = l;
+while ((name[n] = name[m]) != '\0') {
+n++;
+m++;
+}
+}
+else
+++l;
+}
+
+/* 4. remove trailing xx/.. segment. */
+if (l == 2 && name[0] == '.' && name[1] == '.')
+name[0] = '\0';
+else if (l > 2 && name[l - 1] == '.' && name[l - 2] == '.'
+ && name[l - 3] == '/') {
+l = l - 4;
+if (l >= 0) {
+while (l >= 0 && name[l] != '/')
+l--;
+l++;
+}
+else
+l = 0;
+name[l] = '\0';
+}
+}
+
 
 /* Return the string representation of the uwr source */
 const char *uri_worker_map_get_source(uri_worker_record_t *uwr, jk_logger_t *l)
@@ -535,6 +647,7 @@
   const char *uri, jk_logger_t *l)
 {
 unsigned int i;
+int rc;
 const char *rv = NULL;
 char  url[JK_MAX_URI_LEN+1];
 
@@ -578,6 +691,22 @@
 url[i] = uri[i];
 }
 url[i] = '\0';
+if (JK_IS_DEBUG_LEVEL(l))
+jk_log(l, JK_LOG_DEBUG, "Attempting to map original URI '%s' from %d 
maps",
+   url, uw_map->size);
+rc = unescape_url(url);
+if (rc == BAD_REQUEST) {
+jk_log(l, JK_LOG_INFO, "Invalid request while unescaping original URI 
'%s'", url);
+return NULL;
+}
+else if (rc == BAD_PATH) {
+jk_log(l, JK_LOG_INFO, "Invalid path while unescaping URI '%s'", url);
+return NULL;
+}
+normalize_url(url);
+if (JK_IS_DEBUG_LEVEL(l))
+jk_log(l, JK_LOG_DEBUG, "Attempting to map normalized URI '%s' from %d 
maps",
+   url, uw_map->size);
 
 if (JK_IS_DEBUG_LEVEL(l)) {
 char *url_rewrite = strstr(uri, JK_PATH_SESSION_IDENTIFIER);
@@ -585,10 +714,6 @@
 jk_log(l, JK_LOG_D

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

[Jean-Frederic]

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

Note that we should rollback
http://svn.apache.org/viewvc?view=rev&revision=538975 too, shouldn't we?

Cheers

Jean-Frederic


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

DO NOT REPLY [Bug 42409] - Extra response headers not sent when using custom error page

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





--- Additional Comments From [EMAIL PROTECTED]  2007-06-04 07:36 ---
Interesting use-case. One immediate solution that is coming to mind is setting
"X-JSON" header in your custom error page for 400 response. Doesn't this work
for you?

-- 
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: svn commit: r544137 - /tomcat/connectors/trunk/jk/native/common/jk_uri_worker_map.c

[Mladen Turk]

Jean-Frederic wrote:

On Mon, 2007-06-04 at 12:08 +, [EMAIL PROTECTED] wrote:

Author: mturk
Date: Mon Jun  4 05:08:33 2007
New Revision: 544137

URL: http://svn.apache.org/viewvc?view=rev&rev=544137
Log:
Add simple URI normalizer that can deal with things like %252e%252e. This is 
mostly copy/paste from the IIS module



Note that we should rollback
http://svn.apache.org/viewvc?view=rev&revision=538975 too, shouldn't we?




Of course. It was already reported by lots of users that FWDURICOMPATUNPARSED
breaks many current deployments where users expect the uri passed
will be r->uri, not r->unparsed_uri. In such situation users are
forcing the JK_OPT_FWDURICOMPAT anyhow, and are still suffering from
security implications.

Regards,
Mladen.



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

DO NOT REPLY [Bug 42409] - Extra response headers not sent when using custom error page

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





--- Additional Comments From [EMAIL PROTECTED]  2007-06-04 08:29 ---
How would that work?  If a javascript client makes a request to the
controller/servlet, the controller decides whether the request is "good" or not,
if not then the controller generates the response json and sets it in the header
and returns a page containing that header.  It seems it would be easier to set
the header on the page if the header value was always the same but it isn't.

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

emptySessionPath=

[Joerg Heinicke]

Hi,

I have a portal application and introduced recently emptySessionPath="true" to
have access to the same objects in the session in my servlets and my portlets,
both sitting in the same webapp.

First observation I made is the repeated use of the same session id despite
invalidating the corresponding session. I found out that this is by intention
[1], but it leaves a strange gut feeling. Why is a session id an arbitrary
string, which is under normal circumstances really hard to guess - if I do not
need to predict it at all since I know it when having access to the PC (without
any XSS issue)? I only have to wait until the user logs in the next time to
hijack his session, don't I?

But ignoring that one for the moment and blaming the portlet spec [2] I found
another issue ... From what I observed not all sessions assigned to this session
id are invalidated. This seems to be true for different portals, I found at
least uPortal [3], JetSpeed [4] and Liferay [5] (using it myself). Of course
it's possible that the portals are to blame but I wonder if they manage the
sessions themselves or if they don't only forward it to the application
container. At least in Liferay the HttpSession for the portal is invalidated,
but I can access objects in the session of my webapp (portlets + servlets). Here
the reused session id gets also very critical.

So I agree with Aaron Evans who reported this issue for JetSpeed [6]:

"I don't think this is a jetspeed problem but rather a tomcat/tomcat SSO
issue, but I was just wondering if others have seen this behaviour."

And like his idea how it should work [7].

So actually there are two issues, (1) always using the same session id, (2) not
invalidating all sessions associated with one session id. I wonder if there has
changed anything for the former since that thread [1] since I'm using the most
recent 5.5 release 23. Or if it is solvable at all. But the latter seems to be a
real issue for me. Can you please comment on it?

Regards,
Joerg

[1] http://marc.info/?t=11077928475&r=1&w=4
[2] http://marc.info/?l=tomcat-dev&m=112092302521008&w=4
[3] http://www.ja-sig.org/issues/browse/UP-1590
[4] http://issues.apache.org/jira/browse/JS2-582
[5] http://support.liferay.com/browse/LEP-1852
[6] http://www.mail-archive.com/[EMAIL PROTECTED]/msg03195.html
[7] http://www.mail-archive.com/[EMAIL PROTECTED]/msg03203.html


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

Re: emptySessionPath=

[Remy Maucherat]

Joerg Heinicke wrote:

First observation I made is the repeated use of the same session id despite
invalidating the corresponding session. I found out that this is by intention
[1], but it leaves a strange gut feeling. Why is a session id an arbitrary
string, which is under normal circumstances really hard to guess - if I do not
need to predict it at all since I know it when having access to the PC (without
any XSS issue)? I only have to wait until the user logs in the next time to
hijack his session, don't I?


It's not easier or harder, since it is possible to maintain a session 
for a user if you know the id. The session id, which is set using a 
session cookie, will change when the user closes the browser.


It should be easy to use a valve (or a filter) to perform additional 
checks if you feel you need them in your particular use case.



But ignoring that one for the moment and blaming the portlet spec [2] I found
another issue ... From what I observed not all sessions assigned to this session
id are invalidated. This seems to be true for different portals, I found at
least uPortal [3], JetSpeed [4] and Liferay [5] (using it myself). Of course
it's possible that the portals are to blame but I wonder if they manage the
sessions themselves or if they don't only forward it to the application
container. At least in Liferay the HttpSession for the portal is invalidated,
but I can access objects in the session of my webapp (portlets + servlets). Here
the reused session id gets also very critical.


It's your problem: this is not SSO, and the sessions remain fully 
independent.


Rémy

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

Re: emptySessionPath=

[David Jencks]

On Jun 4, 2007, at 8:43 AM, Joerg Heinicke wrote:


Hi,

I have a portal application and introduced recently  
emptySessionPath="true" to
have access to the same objects in the session in my servlets and  
my portlets,

both sitting in the same webapp.

First observation I made is the repeated use of the same session id  
despite
invalidating the corresponding session. I found out that this is by  
intention
[1], but it leaves a strange gut feeling. Why is a session id an  
arbitrary
string, which is under normal circumstances really hard to guess -  
if I do not
need to predict it at all since I know it when having access to the  
PC (without
any XSS issue)? I only have to wait until the user logs in the next  
time to

hijack his session, don't I?

But ignoring that one for the moment and blaming the portlet spec  
[2] I found
another issue ... From what I observed not all sessions assigned to  
this session
id are invalidated. This seems to be true for different portals, I  
found at
least uPortal [3], JetSpeed [4] and Liferay [5] (using it myself).  
Of course
it's possible that the portals are to blame but I wonder if they  
manage the
sessions themselves or if they don't only forward it to the  
application
container. At least in Liferay the HttpSession for the portal is  
invalidated,
but I can access objects in the session of my webapp (portlets +  
servlets). Here

the reused session id gets also very critical.

So I agree with Aaron Evans who reported this issue for JetSpeed [6]:

"I don't think this is a jetspeed problem but rather a tomcat/ 
tomcat SSO

issue, but I was just wondering if others have seen this behaviour."

And like his idea how it should work [7].

So actually there are two issues, (1) always using the same session  
id, (2) not
invalidating all sessions associated with one session id. I wonder  
if there has
changed anything for the former since that thread [1] since I'm  
using the most
recent 5.5 release 23. Or if it is solvable at all. But the latter  
seems to be a

real issue for me. Can you please comment on it?



IMO the area of cross-context session management is basically not  
specified in the servlet and portlet specs.  It certainly relies on a  
lot of extrapolation to make a usable product.  My conclusions are  
that to make a usable portal possible, while deploying portlet  
applications as web apps, the servlet container has to create a cross  
context session id, and manage individual sessions for each web app  
context that uses this sessionId, and when one session is invalidated  
in this collection, invalidate all sessions for that sessionId.   
AFAICT this is consistent with the servlet spec, although it is  
certainly not specified behavior according to the servlet spec.


In a little more detail:

- sessions are indexed by sessionId and context-root (or other web  
app identifier)
- invalidating one session (for a sessionId + context-root)  
invalidates all other sessions with that sessionId


After a lot of discussion with the jetty devs I got them to implement  
this, but I've never been able to understand the discussions about  
the subject on the tomcat lists so I'm really not sure what the  
expected behavior of tomcat is.


thanks
david jencks



Regards,
Joerg

[1] http://marc.info/?t=11077928475&r=1&w=4
[2] http://marc.info/?l=tomcat-dev&m=112092302521008&w=4
[3] http://www.ja-sig.org/issues/browse/UP-1590
[4] http://issues.apache.org/jira/browse/JS2-582
[5] http://support.liferay.com/browse/LEP-1852
[6] http://www.mail-archive.com/[EMAIL PROTECTED]/ 
msg03195.html
[7] http://www.mail-archive.com/[EMAIL PROTECTED]/ 
msg03203.html



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




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

DO NOT REPLY [Bug 30028] - session attributes Map may become inconsistent start causing "strange" problems

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





--- Additional Comments From [EMAIL PROTECTED]  2007-06-04 10:29 ---
Indeed. It seems it has been fixed in Tomcat 5.5.16.
Just for information, this issue is very similar to the one in BUG 36541.
(perhaps a duplicate...)


-- 
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 41824] - Unable to use nested type in TLD

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





--- Additional Comments From [EMAIL PROTECTED]  2007-06-04 11:34 ---
I am also having this problem with simple tag handlers (as opposed to classic
tag handlers described here by Renaud).  I get the exact same behavior he
described when trying to use an inner class for the type attribute in our simple
tag handler attributes.  Any idea when this might be fixed?

-- 
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 41824] - Unable to use nested type in TLD

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


[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]




-- 
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: svn commit: r544137 - /tomcat/connectors/trunk/jk/native/common/jk_uri_worker_map.c

[William A. Rowe, Jr.]

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

You have me way confused ;-)

The uri you are processing in the httpd connector has already been unfolded.
So your desire is to double-unfold the uri?  This has some very ugly side
effects for legitimately escaped paths, and if it is a security precaution,
don't you just leave yet-a-new-hole for triply-folded uris?

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

svn commit: r544243 - in /tomcat/sandbox/comet/java/org/apache: catalina/ catalina/connector/ coyote/ coyote/http11/ tomcat/util/net/

[remm]

Author: remm
Date: Mon Jun  4 13:21:47 2007
New Revision: 544243

URL: http://svn.apache.org/viewvc?view=rev&rev=544243
Log:
- Further API simplification.
- isWriteable can be used as a hidden callback to place the socket in the 
poller for
  write events.
- Remove the configure flag.
- I don't see much point in using blocking mode in Comet, since the API usage 
is actually identical.
- CometEvent.sleep will be used to disable read events (but the name is more 
explicit).
- As before, no full implementation at the moment.

Modified:
tomcat/sandbox/comet/java/org/apache/catalina/CometEvent.java
tomcat/sandbox/comet/java/org/apache/catalina/connector/CometEventImpl.java
tomcat/sandbox/comet/java/org/apache/catalina/connector/OutputBuffer.java
tomcat/sandbox/comet/java/org/apache/catalina/connector/Request.java
tomcat/sandbox/comet/java/org/apache/coyote/ActionCode.java
tomcat/sandbox/comet/java/org/apache/coyote/http11/Http11AprProcessor.java

tomcat/sandbox/comet/java/org/apache/coyote/http11/InternalAprOutputBuffer.java
tomcat/sandbox/comet/java/org/apache/tomcat/util/net/AprEndpoint.java

Modified: tomcat/sandbox/comet/java/org/apache/catalina/CometEvent.java
URL: 
http://svn.apache.org/viewvc/tomcat/sandbox/comet/java/org/apache/catalina/CometEvent.java?view=diff&rev=544243&r1=544242&r2=544243
==
--- tomcat/sandbox/comet/java/org/apache/catalina/CometEvent.java (original)
+++ tomcat/sandbox/comet/java/org/apache/catalina/CometEvent.java Mon Jun  4 
13:21:47 2007
@@ -118,7 +118,7 @@
  * @see #EventSubType
  */
 public EventSubType getEventSubType();
-
+
 /**
  * Ends the Comet session. This signals to the container that 
  * the container wants to end the comet session. This will send back to the
@@ -129,7 +129,7 @@
  * @throws IOException if an IO exception occurs
  */
 public void close() throws IOException;
-
+
 /**
  * Sets the timeout for this Comet connection. Please NOTE, that the 
implementation 
  * of a per connection timeout is OPTIONAL and MAY NOT be implemented.
@@ -142,16 +142,17 @@
  * This method should not be called asynchronously, as that will have no 
effect.
  * 
  * @param timeout The timeout in milliseconds for this connection, must be 
a positive value, larger than 0
- * @throws IOException An IOException may be thrown to indicate an IO 
error, 
- * or that the EOF has been reached on the connection
  */
-public void setTimeout(int timeout)
-throws IOException;
+public void setTimeout(int timeout);
 
 /**
  * Returns true if write notifications are disabled, or is they are 
enabled and data may
  * be written to the connection (the flag becomes false when the client is 
unable to accept
- * data fast enough). When the flag becomes 
+ * data fast enough). When the flag becomes false, the servlet must stop 
writing data. If there's
+ * an attempt to flush additional data to the client and data still cannot 
be written immediately,
+ * an IOException will be thrown. If calling this method returns false, it 
will also 
+ * request notification when the connection becomes available for writing 
again, and the  
+ * servlet will recieve a write event.
  * 
  * @return boolean true if you can write to the response 
  */
@@ -167,23 +168,15 @@
 public boolean isReadable();
 
 /**
- * Configure notifications that will be recieved. This method should be 
called during the processing of
- * the begin event. If configure is not called, the behavior will be the 
same as if configure(true, false)
- * is called.
- * 
- * @param read if true, read events will be sent to the servlet
- * @param write if true, the connection will be placed in non blocking 
mode, and write notifications
- *may be requested by using the sendNotify method
+ * Will ask the servlet container to send a notify event to the servlet, 
where the request can be processed
+ * synchronously (for example, it is possible to use this to complete the 
request after some asynchronous
+ * processing is done).
  */
-public void configure(boolean read, boolean write);
+public void callback();
 
 /**
- * Send a notify event to the servlet.
- * 
- * @param write with the value true should be called when isWriteable 
becomes false, to request notification
- *when the connection becomes available for writing again; with 
the value false, a notify event 
- *will be sent to the servlet
+ * Delay processing of the connection until the configured timeout occurs, 
or callback(true) is called.
  */
-public void callback(boolean write);
+public void sleep();
 
 }

Modified: 
tomcat/sandbox/comet/java/org/apache/catalina/connector/CometEventImpl.java
URL: 
http://svn.apache.

DO NOT REPLY [Bug 42579] New: - JNDIRealm fails to parse absolute names

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

   Summary: JNDIRealm fails to parse absolute names
   Product: Tomcat 5
   Version: 5.5.9
  Platform: All
OS/Version: other
Status: NEW
  Severity: normal
  Priority: P2
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Active Directory can respond to a query with SearchResult's that are not
relative.  We discovered this happening with a directory hosted across many
servers when the userBase was not sufficient to identify a single server.

In getUserBySearch, JNDIRealm assumes that the SearchResult is relative and goes
about creating a DN for the user by appending together the various bits of names
it gets back.  This is definitely wrong for absolute names which are URL's of
the form:  ldap://server/encoded_user_dn

I discovered this issue in Tomcat 5.5 and a cursory look at the SVN repo for
Tomcat 6.0 reveals that this bug is also present there.  

I have a patch for this issue which I will attach.

-- 
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 42579] - JNDIRealm fails to parse absolute names

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





--- Additional Comments From [EMAIL PROTECTED]  2007-06-04 14:14 ---
Created an attachment (id=20310)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=20310&action=view)
My patch to fix this issue


-- 
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: svn commit: r544137 - /tomcat/connectors/trunk/jk/native/common/jk_uri_worker_map.c

[Mladen Turk]

William A. Rowe, Jr. wrote:

[EMAIL PROTECTED] wrote:

Author: mturk
Date: Mon Jun  4 05:08:33 2007
New Revision: 544137

URL: http://svn.apache.org/viewvc?view=rev&rev=544137
Log:
Add simple URI normalizer that can deal with things like %252e%252e. This is 
mostly copy/paste from the IIS module


You have me way confused ;-)



Right. I confused many. Just look at the thread about the subject.
Almost nobody understood what was I talking about.


The uri you are processing in the httpd connector has already been unfolded.
So your desire is to double-unfold the uri?


No. Nothing is neither unfolded nor double unfolded.
This is internal for map_uri_to_worker.

How it works:
Imagine you have two applications on Tomcat appA and appB, and
you wish *only* to expose the appA via
JkMount /appA/* worker

Request:
http://host/appA/%252e%252e/appB/
mod_jk 1.2.22 (with default passing r->uri) will serve /appB/
mod_jk 1.2.23 (with default passing r->unparsed_uri) will return 404 from Tomcat
   becasue it will pass the original uri, not the one Httpd already
   unfolded)
mod_jk 1.2.24 will return 404 from Httpd because there is no JkMount /appB/*



This has some very ugly side
effects for legitimately escaped paths, and if it is a security precaution,
don't you just leave yet-a-new-hole for triply-folded uris?



Again, no. It doesn't touch the original uri.
Request for http://host/appA/%252e%252e/appB/ will be unfolded by
httpd to http://host/appA/%2e%2e/appB/ before it hits mod_jk.
Inside map_uri_to_worker it will be unescped (locally) to
/appA/../appB/ and the normalized to /appB/ and then it looks for
mounted path. In case one have JkMount /* or JkMount /appB/*, the
original uri host/appA/%2e%2e/appB/ will be passed to Tomcat.



Regards,
Mladen.




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

svn commit: r544401 - in /tomcat/container/tc5.5.x: catalina/src/share/org/apache/catalina/mbeans/JMXAdaptorLifecycleListener.java webapps/docs/changelog.xml webapps/docs/monitoring.xml

[pero]

Author: pero
Date: Mon Jun  4 23:19:13 2007
New Revision: 544401

URL: http://svn.apache.org/viewvc?view=rev&rev=544401
Log:
Add JMXAdaptorLifecycleListener to start JMX Connector with fix naming and data 
port. 
This feature is needed to have stable remote access as your local firewall is 
activ.

Added:

tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/mbeans/JMXAdaptorLifecycleListener.java
   (with props)
Modified:
tomcat/container/tc5.5.x/webapps/docs/changelog.xml
tomcat/container/tc5.5.x/webapps/docs/monitoring.xml

Added: 
tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/mbeans/JMXAdaptorLifecycleListener.java
URL: 
http://svn.apache.org/viewvc/tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/mbeans/JMXAdaptorLifecycleListener.java?view=auto&rev=544401
==
--- 
tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/mbeans/JMXAdaptorLifecycleListener.java
 (added)
+++ 
tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/mbeans/JMXAdaptorLifecycleListener.java
 Mon Jun  4 23:19:13 2007
@@ -0,0 +1,355 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements.  See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License.  You may obtain a copy of the License at
+ * 
+ *  http://www.apache.org/licenses/LICENSE-2.0
+ * 
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.catalina.mbeans;
+
+import java.util.HashMap;
+import java.util.Properties;
+import java.io.IOException;
+import java.io.FileInputStream;
+import java.io.FileNotFoundException;
+
+import org.apache.catalina.Lifecycle;
+import org.apache.catalina.LifecycleEvent;
+import org.apache.catalina.LifecycleListener;
+import org.apache.catalina.core.StandardServer;
+
+import java.net.InetAddress;
+import java.rmi.registry.LocateRegistry;
+import java.rmi.registry.Registry;
+import java.rmi.server.UnicastRemoteObject;
+import javax.rmi.ssl.SslRMIServerSocketFactory;
+import javax.rmi.ssl.SslRMIClientSocketFactory;
+
+import java.lang.management.ManagementFactory;
+import javax.management.MBeanServer;
+import javax.management.remote.JMXServiceURL;
+import javax.management.remote.JMXConnectorServer;
+import javax.management.remote.JMXConnectorServerFactory;
+import javax.management.remote.rmi.RMIConnectorServer;
+
+/**
+ * Start JSR160 JMX Adapter with naming and jmx port! Add only as Server 
Listner
+ * to your tomcat server.xml 
+ * 
+ * ...
+ *     
+ * ...
+ * 
+ * 
+ * 
+ * You can use normal jmx system properties from command line or jmx config 
file: 
+ * 
+ * -Dcom.sun.management.jmxremote.authenticate=true
+ * -Dcom.sun.management.jmxremote.ssl=false
+ * 
-Dcom.sun.management.jmxremote.access.file=$CATALINA_BASE/conf/access.file
+ * 
-Dcom.sun.management.jmxremote.password.file=$CATALINA_BASE/conf/password.file
+ * 
-Dcom.sun.management.config.file=$CATALINA_BASE/conf/jmx.properties
+ * 
+ * 
+ * Then run jconsole with:
+ * 
+ * jconsole service:jmx:rmi://myhost:8084/jndi/rmi://myhost:8083/server
+ * 
+ * 
+ * 
+ * It would be be better if this was built into Tomcat as a configuration
+ * option, rather than having to do it as part of every Tomcat instance.
+ * 
+ * Origanal code idea comes from George Lindholm read
+ * http://issues.apache.org/bugzilla/show_bug.cgi?id=39055";>Tomcat 
Bug 39055
+ * and other helpful links are:
+ * 
+ * http://today.java.net/pub/a/today/2005/11/15/using-jmx-to-manage-web-applications.html";>Using
 Web Apps
+ * http://java.sun.com/j2se/1.5.0/docs/guide/management/agent.html#SSL_enabled";>JVM
 1.5 JMX Guide
+ * 
+ * @author Peter Rossbach
+ * @author Juergen Herrmann
+ */
+public class JMXAdaptorLifecycleListener implements LifecycleListener {
+
+/**
+ * Logger
+ */
+private static org.apache.commons.logging.Log log = 
org.apache.commons.logging.LogFactory
+.getLog(JMXAdaptorLifecycleListener.class);
+
+/**
+ * The descriptive information string for this implementation.
+ */
+private static final String info = 
"org.apache.catalina.mbeans.JMXAdaptorLifecycleListener/1.0";
+
+private boolean enabled = true;
+
+private int namingPort = 0;
+
+private int port = 0;
+
+private String host

DO NOT REPLY [Bug 39055] - Firewall access for JSR 160 JMX with Java 5

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





--- Additional Comments From [EMAIL PROTECTED]  2007-06-04 23:21 ---
OK, feature is cool, but implementation has some bugs.
Juergen Herrmann send me a better code contribution.
Please check the new JMXAdaptorLifecycleListener ( Tomcat 5.5 Revision 544401).


...
  
...


Peter

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