DO NOT REPLY [Bug 7931] - A url that contains %2F in the path, tomcat returns 400 bad request.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7931. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7931 A url that contains %2F in the path, tomcat returns 400 bad request. [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2002-04-11 07:52 --- It is nice that Apache handles it fine. Tomcat can't process such a request without opening some URL based security exploits. 4.0-HEAD with Coyote doesn't have the need for the normalization. TO have it work fine, either use a nightly build, or configure Apache to work with Tomcat through JK. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 7931] New: - A url that contains %2F in the path, tomcat returns 400 bad request.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7931. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7931 A url that contains %2F in the path, tomcat returns 400 bad request. Summary: A url that contains %2F in the path, tomcat returns 400 bad request. Product: Tomcat 4 Version: 4.0.4 Beta 2 Platform: All OS/Version: All Status: NEW Severity: Major Priority: Other Component: Connector:HTTP/1.1 (deprecated) AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] If I do a request to a url such as: http://localhost:8080/test/foo%2Fbar tomcat returns 400 Bad Request and the request is not logged in the access log. It should not return this, apache processes the request correctly. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 7344] - Tomcat appears to be case-sensitive with regard to the token Basic in Authorization request parameter
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7344. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7344 Tomcat appears to be case-sensitive with regard to the token Basic in Authorization request parameter [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2002-03-23 17:59 --- This will be fixed in 4.0.4 b2. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 7344] New: - Tomcat appears to be case-sensitive with regard to the token Basic in Authorization request parameter
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7344. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7344 Tomcat appears to be case-sensitive with regard to the token Basic in Authorization request parameter Summary: Tomcat appears to be case-sensitive with regard to the token Basic in Authorization request parameter Product: Tomcat 4 Version: 4.0 Final Platform: All OS/Version: All Status: NEW Severity: Normal Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] While using OpenSTA for developing some automated tests, I noticed that it generates its Authorization string as follows: Authorization: BASIC lkjdflkjfdslkjfsdlkjsfd This seemed to cause problems with Tomcat 4, until we manually forced the string to be: Authorization: Basic lkjfdjkldsjklfdsjkllkjkjl RFC for HTTP says that the token identifying the authorization type should be case-insensitive (http://www-old.ics.uci.edu/pub/ietf/http/rfc1945.html#AA) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 7277] New: - request URI processing works wrong
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7277.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7277
request URI processing works wrong
Summary: request URI processing works wrong
Product: Tomcat 4
Version: 4.0.4 Beta 1
Platform: All
OS/Version: All
Status: NEW
Severity: Major
Priority: Other
Component: Connector:Other
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
tomcat 4 does not allow escaped character %2f ('/') (HttpProcessor.java) in the
path. it is contradictory to HTTP specification, and it is significant, since
some applications use this character in the pathInfo.
it is not clear how it should be interpreted -- on the one hand, URI
specification allows it _inside_ path elements, on the other hand, HTTP/1.1
specification suggest to treat it the same way as '/'.
in both cases it shouldn't be disallowed.
from Hypertext Transfer Protocol -- HTTP/1.1
-
For definitive information on URL syntax and semantics,
see Uniform Resource Identifiers (URI): Generic Syntax and Semantics, RFC
2396 [42] (which replaces RFCs 1738 [4] and RFC 1808 [11]).
-
from Uniform Resource Identifiers (URI): Generic Syntax and Semantics:
-
2.2. Reserved Characters
Many URI include components consisting of or delimited by, certain
special characters. These characters are called reserved, since
their usage within the URI component is limited to their reserved
purpose. If the data for a URI component would conflict with the
reserved purpose, then the conflicting data must be escaped before
forming the URI.
reserved= ; | / | ? | : | @ | | = | + |
$ | ,
The reserved syntax class above refers to those characters that are
allowed within a URI, but which may not be allowed within a
particular component of the generic URI syntax; they are used as
delimiters of the components described in Section 3.
...
2.4.2. When to Escape and Unescape
A URI is always in an escaped form, since escaping or unescaping a
completed URI might change its semantics. Normally, the only time
escape encodings can safely be made is when the URI is being created
from its component parts; each component may have its own set of
characters that are reserved, so only the mechanism responsible for
generating or interpreting that component can determine whether or
not escaping a character will change its semantics. Likewise, a URI
must be separated into its components before the escaped characters
within those components can be safely decoded.
-
however,
from Hypertext Transfer Protocol -- HTTP/1.1:
-
3.2.3 URI Comparison
When comparing two URIs to decide if they match or not, a client SHOULD use a
case-sensitive octet-by-octet comparison of the entire URIs, with these
exceptions:
- A port that is empty or not given is equivalent to the default
port for that URI-reference;
- Comparisons of host names MUST be case-insensitive;
- Comparisons of scheme names MUST be case-insensitive;
- An empty abs_path is equivalent to an abs_path of /.
Characters other than those in the reserved and unsafe sets (see RFC 2396
[42]) are equivalent to their % HEX HEX encoding.
...
If the Request-URI is encoded using the % HEX HEX encoding [42], the origin
server MUST decode the Request-URI in order to properly interpret the request.
Servers SHOULD respond to invalid Request-URIs with an appropriate status code.
---
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 7277] - request URI processing works wrong
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7277. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7277 request URI processing works wrong [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2002-03-20 15:50 --- Coyote will allow whatever %xx character you want (at least when it's used with 4.0-HEAD). However, it will normalize // to / because that would allow bypassing security constraints, and various other nasty tricks. Use a request parameter, or it will not work. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 6557] - isapi_redirector can not handle post request from netscape 4.7x
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6557. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6557 isapi_redirector can not handle post request from netscape 4.7x [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||LATER --- Additional Comments From [EMAIL PROTECTED] 2002-03-20 00:21 --- I regret not having the time to look more into this, and need to LATER this one relative to Tomcat 3.3.1. I will try to address this in jakarta-tomcat-connectors. A test case that we can use to duplicate the problem would be helpful. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 7173] New: - Tomcat fails to respect HTTP HEAD request
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7173. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7173 Tomcat fails to respect HTTP HEAD request Summary: Tomcat fails to respect HTTP HEAD request Product: Tomcat 4 Version: 4.0.3 Final Platform: Other OS/Version: Linux Status: NEW Severity: Minor Priority: Other Component: Unknown AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 7173] - Tomcat fails to respect HTTP HEAD request
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7173. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7173 Tomcat fails to respect HTTP HEAD request [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2002-03-16 22:41 --- You'll have to provide an example of bad behavior, as this is a duplicate of bug 5126, which was fixed. *** This bug has been marked as a duplicate of 5126 *** -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 5126] - Client request using HEAD results in a response body returned to client.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5126. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5126 Client request using HEAD results in a response body returned to client. [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2002-03-16 22:41 --- *** Bug 7173 has been marked as a duplicate of this bug. *** -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 5785] - XML request time attribute notgenerated correctly
Hi, *moan* Now I have to convert HTML tags we have that use request-time attributes into custom tags so that we can give them request time attributes. *sigh* Is it going to change in 1.3? I mean, XSLT allows all *non*-XSLT tags to have the equivalent of request-time attributes. I guess I thought JSP would be the same. It just makes sense, doesn't it? :) We ran into exactly the same problem. IMO it's a really ugly spec bug :-( I already sent a comment about that to [EMAIL PROTECTED], but got no response. We (kind of) solved the problem by wrapping our pages in custom tags that buffer their body content and parse it by hand. Of course, this doesn't work for arbitrary expressions without putting a lot of effort into it. In our case, we just look up pageContext attributes so that img src=%= someSrc %/ is translated into img src=someImg/ with someImg being the value of pageContext.getAttribute(someSrc). Since this is not satisfactory, we're currently working at a solution that takes an XML document that looks like a JSP and translates it into a non-XML-JSP (via XSLT). During translation, all %= = attribute values are replaced by the appropriate code. This way, you're still working with something that looks like an XML-JSP but with RT attribute expressions in _all_ tags. If you're interested, I can send you more information. Note: This work is done within a diploma thesis, so it's absolutely free to use, copy, change, ... Well, maybe I can kill two birds with one stone: sooner or later I need to get real HTML syntax out of my JSP1.2 pages anyway, maybe I will just get all the HTML custom tags to output proper HTML syntax tags. The performance is going to be bad though... I really wouldn't do that, it's too work for what you get at the end. BTW, I don't think you can sell img../ (or other html tags) to Jasper as custom tags without a namespace prefix: xyz:img.../. And this looks _really_ ugly! Best regards Andreas Junghans PS Sorry for being so lengthy, it's a bad habit of mine ... -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 5785] - XML request time attributenotgenerated correctly
Thanks for the message. It is wonderful to know that we are not the only ones that got stuck. In my opinion, JSP 1.2 XML has two bugs. This and the fact that we can't specify that the output is really HTML in XHTML form. In other words, we need something like the output method in XSLT and James Clark's implementation of that element in his XT XSLT processor: that you can plug in an output module to handle the actual tag outputs. For instance, if you specify that the output is really HTML, the HTML output module will take over and makes sure the tags it outputs are proper HTML tags. We used that approach with XT to output some bizzarre HTML-like markup languages like HDML, WML variants that insist of having the literal character (literal characters, can you imagine that?) in their attributes (it caused so much pain...). As long as it sends the JSP tags to the JSP output writer, the JSP semantics will still be maintained. I might just have to implement something like that. Obviously, that will not violate the JSP 1.2 spec. A post-processor, if you like. I will simply use the mime type that you can specify in JSP pages to indicate the output engine to use... Let me think about the solution you have. I am not sure how we can incorporate it into our system. In our system, we start from XML files that specify HTML Form elements on pages, without presentation. We then use XSLT to convert that into JSP pages that combine look-and-feel elements from other files. In this way, we can generate a Web site with a particular look-and-feel in about 2 minutes, and still basically serve JSP pages. Half a year ago, we used JSP 1.1 with CDATA sections and xsl:text disable-output-escaping='yes' all over the place in our XSLT scripts. It was painful, not to mention very error-prone, as we cannot expect XML to match tags and attribute quotes for us any more. So I was ecstatic when JSP 1.2 XML came out. Now, if I had to follow the spec, I had two choices: tons of CDATA sections and xsl:text and generally ugliness in my XSLT scripts, or tons of CDATA sections and generally ugliness in the JSP pages we generate. What a choice! :) About the need for namespace prefix. I can use xmlns='...' to declare the default namespace to be my namespace name. That will get rid of the prefix. Don't apologise for long messages. They are good for clearing up complex situations. Khun Yee [EMAIL PROTECTED] 03/12/02 03:46AM Hi, *moan* Now I have to convert HTML tags we have that use request-time attributes into custom tags so that we can give them request time attributes. *sigh* Is it going to change in 1.3? I mean, XSLT allows all *non*-XSLT tags to have the equivalent of request-time attributes. I guess I thought JSP would be the same. It just makes sense, doesn't it? :) We ran into exactly the same problem. IMO it's a really ugly spec bug :-( I already sent a comment about that to [EMAIL PROTECTED], but got no response. We (kind of) solved the problem by wrapping our pages in custom tags that buffer their body content and parse it by hand. Of course, this doesn't work for arbitrary expressions without putting a lot of effort into it. In our case, we just look up pageContext attributes so that img src=%= someSrc %/ is translated into img src=someImg/ with someImg being the value of pageContext.getAttribute(someSrc). Since this is not satisfactory, we're currently working at a solution that takes an XML document that looks like a JSP and translates it into a non-XML-JSP (via XSLT). During translation, all %= = attribute values are replaced by the appropriate code. This way, you're still working with something that looks like an XML-JSP but with RT attribute expressions in _all_ tags. If you're interested, I can send you more information. Note: This work is done within a diploma thesis, so it's absolutely free to use, copy, change, ... Well, maybe I can kill two birds with one stone: sooner or later I need to get real HTML syntax out of my JSP1.2 pages anyway, maybe I will just get all the HTML custom tags to output proper HTML syntax tags. The performance is going to be bad though... I really wouldn't do that, it's too work for what you get at the end. BTW, I don't think you can sell img../ (or other html tags) to Jasper as custom tags without a namespace prefix: xyz:img.../. And this looks _really_ ugly! Best regards Andreas Junghans PS Sorry for being so lengthy, it's a bad habit of mine ... -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 5785] - XML request time attribute not generated correctly
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5785. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5785 XML request time attribute not generated correctly [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2002-03-11 18:42 --- The runtime expression (of the form %=...%) in only evaluated when it appears in the attributes of ajsp:expression, some standard action, or a custom tag action element, and is not in an unterpreted tag. Check the spec. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 5785] - XML request time attribute notgenerated correctly
*moan* Now I have to convert HTML tags we have that use request-time attributes into custom tags so that we can give them request time attributes. *sigh* Is it going to change in 1.3? I mean, XSLT allows all *non*-XSLT tags to have the equivalent of request-time attributes. I guess I thought JSP would be the same. It just makes sense, doesn't it? :) Well, maybe I can kill two birds with one stone: sooner or later I need to get real HTML syntax out of my JSP1.2 pages anyway, maybe I will just get all the HTML custom tags to output proper HTML syntax tags. The performance is going to be bad though... Thanks. Khun Yee [EMAIL PROTECTED] 03/11/02 01:42PM DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5785. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5785 XML request time attribute not generated correctly [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2002-03-11 18:42 --- The runtime expression (of the form %=...%) in only evaluated when it appears in the attributes of ajsp:expression, some standard action, or a custom tag action element, and is not in an unterpreted tag. Check the spec. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 6942] - getRequestURL does not return a port number is request scheme is different then http or https
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6942. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6942 getRequestURL does not return a port number is request scheme is different then http or https [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||REMIND --- Additional Comments From [EMAIL PROTECTED] 2002-03-07 20:01 --- I'm forwarding this report to the Servlet API feedback address ([EMAIL PROTECTED]) because this class is part of the standard Servlet API. Two other things to note: * This class is deprecated as of Servlet 2.3, in favor of using HttpServletRequest.getRequestURL(). * The Tomcat implementation of HttpServletRequest.getRequestURL() is implemented in the manner you suggest. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 6942] New: - getRequestURL does not return a port number is request scheme is different then http or https
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6942.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6942
getRequestURL does not return a port number is request scheme is different then http
or https
Summary: getRequestURL does not return a port number is request
scheme is different then http or https
Product: Tomcat 4
Version: 4.0.1 Final
Platform: Other
OS/Version: All
Status: NEW
Severity: Normal
Priority: Other
Component: Unknown
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
This is a problem in implementation of servlet api -
javax.servlet.http.HttpUtils - getRequestURL (HttpServletRequest req) method.
The method only assumes http and https urls. That is, if the request scheme is
other than http or https then the port number of the server will not be
included in the reconstructed url.
The following code:
if ((scheme.equals (http) port != 80)
|| (scheme.equals (https) port != 443)) {
url.append (':');
url.append (req.getServerPort ());
}
should be replaced with:
if (! ( (scheme.equals(http) port == 80) ||
(scheme.equals(https) port == 443) ) ) {
url.append (':');
url.append (req.getServerPort ());
}
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[4.0] [Seurity] Security problem when using the SecurityManager with a request dispatcher
Hi, A security problem affecting Tomcat 4.0.2 (and all versions of 4.x) has been reported, which allows to get a request dispatcher to an URL outside of the context root. This is not a security problem when NOT using a security manager, since it is always possible to use direct filesystem access to achieve the same result. However, this vulnerability allows to bypass the security manager protection, and serve resources located anywhere on the server. For example, this vulnerability can be reproduced by adding an include command inside a JSP page, like jsp:include page=../../../foo2/jsp/include/bar.txt/. A Tomcat release including the fix will be made available shortly. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 6610] - Request-Time Attribute Expressions in XML-Syntax JSPs not working
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6610. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6610 Request-Time Attribute Expressions in XML-Syntax JSPs not working [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Additional Comments From [EMAIL PROTECTED] 2002-02-25 18:59 --- I tried a simple test, and it seemed to work. Did you set the rtexprvalue of the attibute in your tld to true? The default is false, so if you didn't set it to true, you'll get what you are getting now. If you still have problem with this, reopen the bug with a concrete test case: supply a war file! -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 6557] - isapi_redirector can not handle post request from netscape 4.7x
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6557. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6557 isapi_redirector can not handle post request from netscape 4.7x --- Additional Comments From [EMAIL PROTECTED] 2002-02-25 20:30 --- i tried ajp13 for both tomcat3 and tomcat4. it seems worse, even ie can not connect to my servlet by calling both URLOpenStream()(an ie activex api) and NPN_PostURLNotify() (netscape plug api), which works fine with apache+tomcat. i send http requst with binary data in the body: 00 POST /InTether/s 50 4f 53 54 20 2f 49 6e 54 65 74 68 65 72 2f 73 16 ervlet/FileExcha 65 72 76 6c 65 74 2f 46 69 6c 65 45 78 63 68 61 32 ngeServer HTTP/1 6e 67 65 53 65 72 76 65 72 20 48 54 54 50 2f 31 48 .1..Accept: */*. 2e 31 0d 0a 41 63 63 65 70 74 3a 20 2a 2f 2a 0d 64 .Accept-Encoding 0a 41 63 63 65 70 74 2d 45 6e 63 6f 64 69 6e 67 80 : gzip, deflate. 3a 20 67 7a 69 70 2c 20 64 65 66 6c 61 74 65 0d 96 .User-Agent: Moz 0a 55 73 65 72 2d 41 67 65 6e 74 3a 20 4d 6f 7a 000112 illa/4.0 (compat 69 6c 6c 61 2f 34 2e 30 20 28 63 6f 6d 70 61 74 000128 ible; MSIE 6.0; 69 62 6c 65 3b 20 4d 53 49 45 20 36 2e 30 3b 20 000144 Windows NT 5.0; 57 69 6e 64 6f 77 73 20 4e 54 20 35 2e 30 3b 20 000160 InTetherAgent 0. 49 6e 54 65 74 68 65 72 41 67 65 6e 74 20 30 2e 000176 1/443e9c3c-7bb4- 31 2f 34 34 33 65 39 63 33 63 2d 37 62 62 34 2d 000192 4be8-9f79-656e21 34 62 65 38 2d 39 66 37 39 2d 36 35 36 65 32 31 000208 fff6f1)..Host: l 66 66 66 36 66 31 29 0d 0a 48 6f 73 74 3a 20 6c 000224 ocalhost:90..Con 6f 63 61 6c 68 6f 73 74 3a 39 30 0d 0a 43 6f 6e 000240 tent-Length: 4.. 74 65 6e 74 2d 4c 65 6e 67 74 68 3a 20 34 0d 0a 000256 Connection: Keep 43 6f 6e 6e 65 63 74 69 6f 6e 3a 20 4b 65 65 70 000272 -Alive..Cache-Co 2d 41 6c 69 76 65 0d 0a 43 61 63 68 65 2d 43 6f 000288 ntrol: no-cache. 6e 74 72 6f 6c 3a 20 6e 6f 2d 63 61 63 68 65 0d 000304 .Cookie: JSESSIO 0a 43 6f 6f 6b 69 65 3a 20 4a 53 45 53 53 49 4f 000320 NID=97E25BFA89BD 4e 49 44 3d 39 37 45 32 35 42 46 41 38 39 42 44 000336 9B94AE94A9C65B8F 39 42 39 34 41 45 39 34 41 39 43 36 35 42 38 46 000352 0660 30 36 36 30 0d 0a 0d 0a ff ff ff ff but i caught exception in servlet: internal Server Error description server encountered an internal error (Internal Server Error) that prevented it from fulfilling this request and then IOException once i read from the request body the following are the log message from isapi.log: [Mon Feb 25 14:25:43 2002] [jk_isapi_plugin.c (657)]: HttpFilterProc started [Mon Feb 25 14:25:43 2002] [jk_isapi_plugin.c (705)]: In HttpFilterProc Virtual Host redirection of /localhost:90/InTether/servlet/FileExchangeServer [Mon Feb 25 14:25:43 2002] [jk_uri_worker_map.c (447)]: Into jk_uri_worker_map_t::map_uri_to_worker [Mon Feb 25 14:25:43 2002] [jk_uri_worker_map.c (464)]: Attempting to map URI '/localhost:90/InTether/servlet/FileExchangeServer' [Mon Feb 25 14:25:43 2002] [jk_uri_worker_map.c (570)]: jk_uri_worker_map_t::map_uri_to_worker, done without a match [Mon Feb 25 14:25:43 2002] [jk_isapi_plugin.c (711)]: In HttpFilterProc test Default redirection of /InTether/servlet/FileExchangeServer [Mon Feb 25 14:25:43 2002] [jk_uri_worker_map.c (447)]: Into jk_uri_worker_map_t::map_uri_to_worker [Mon Feb 25 14:25:43 2002] [jk_uri_worker_map.c (464)]: Attempting to map URI '/InTether/servlet/FileExchangeServer' [Mon Feb 25 14:25:43 2002] [jk_uri_worker_map.c (489)]: jk_uri_worker_map_t::map_uri_to_worker, Found a context match ajp13 - /InTether/ [Mon Feb 25 14:25:43 2002] [jk_isapi_plugin.c (721)]: HttpFilterProc [/InTether/servlet/FileExchangeServer] is a servlet url - should redirect to ajp13 [Mon Feb 25 14:25:43 2002] [jk_isapi_plugin.c (784)]: HttpFilterProc check if [/InTether/servlet/FileExchangeServer] is points to the web-inf directory [Mon Feb 25 14:25:43 2002] [jk_isapi_plugin.c (824)]: HttpExtensionProc started [Mon Feb 25 14:25:43 2002] [jk_worker.c (132)]: Into wc_get_worker_for_name ajp13 [Mon Feb 25 14:25:43 2002] [jk_worker.c (136)]: wc_get_worker_for_name, done found a worker [Mon Feb 25 14:25:43 2002] [jk_isapi_plugin.c (860)]: HttpExtensionProc got a worker for name ajp13 [Mon Feb 25 14:25:43 2002] [jk_ajp_common.c (1352)]: Into jk_worker_t::get_endpoint [Mon Feb 25 14:25:43 2002] [jk_ajp_common.c (1075)]: Into jk_endpoint_t::service [Mon Feb 25 14:25:43 2002] [jk_ajp_common.c (280)]: Into ajp_marshal_into_msgb [Mon Feb 25 14:25:43 2002] [jk_ajp_common.c (413)]: ajp_marshal_into_msgb - Done [Mon Feb 25 14:25:43 2002] [jk_ajp_common.c (612)]: sending to ajp13 #362 [Mon Feb 25 14:25:43 2002] [jk_ajp_common.c (853
RE: mod_jk suggestion, add request logging option
OK, I think that explains it. So mod_jk 2.0 and Ajp14 are still in development, and it may be a while before they are finished. What is the status of mod_jk (2) 1.2 and Ajp 14? My opinion: Jk2 supports all the features from jk1 ( and some more ). There are probably some new bugs and some old bugs that still need to be ported, but feature-wise the code can replace jk1 as soon as there is enough will and interest to do so. The only problem with jk2 is that it's only available for Apache 2.0, port to Apache 1.3 should be conducted... And for sure IIS/iPlanet, and we have to know if we could have a mod_jk 2.x with and without APR (with less features) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: mod_jk suggestion, add request logging option
GOMEZ Henri wrote: OK, I think that explains it. So mod_jk 2.0 and Ajp14 are still in development, and it may be a while before they are finished. What is the status of mod_jk (2) 1.2 and Ajp 14? My opinion: Jk2 supports all the features from jk1 ( and some more ). There are probably some new bugs and some old bugs that still need to be ported, but feature-wise the code can replace jk1 as soon as there is enough will and interest to do so. The only problem with jk2 is that it's only available for Apache 2.0, port to Apache 1.3 should be conducted... And for sure IIS/iPlanet, and we have to know if we could have a mod_jk 2.x with and without APR (with less features) APR should work also when using IIS/iPlanet. If not tell me (I also like to see my name in [EMAIL PROTECTED] ;-)). -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: mod_jk suggestion, add request logging option
On Fri, 22 Feb 2002, GOMEZ Henri wrote: The only problem with jk2 is that it's only available for Apache 2.0, port to Apache 1.3 should be conducted... True. My focus was on cleaning up the code, and it was much easier with a single server. I don't think updating the other servers is very difficult. And for sure IIS/iPlanet, and we have to know if we could have a mod_jk 2.x with and without APR (with less features) Is APR released as 1.0 ? Do we gain anything by removing the current jk_pool, jk_map, etc ? Have we tested APR with IIS ? IMHO - jk2.0 should keep the old code and be able to operate without APR ( but default to APR ). In 2.1 we can drop the old code and use APR exclusively. The current design allows one to use 'native' APIs - if a server has a pool-equivalent it can be used ( so in Apache1.3 we have the choice between 1.3 pool, apr pool, or jk pool ). Same for logging, maps. Long term I think it would be good to use the 'natives' whenever possible, and APR for missing features. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: mod_jk suggestion, add request logging option
The only problem with jk2 is that it's only available for Apache 2.0, port to Apache 1.3 should be conducted... True. My focus was on cleaning up the code, and it was much easier with a single server. I don't think updating the other servers is very difficult. Hope so, maybe Apache 1.3 port is somewhere hidden in a laptop (;)) And for sure IIS/iPlanet, and we have to know if we could have a mod_jk 2.x with and without APR (with less features) Is APR released as 1.0 ? Do we gain anything by removing the current jk_pool, jk_map, etc ? Have we tested APR with IIS ? Having an APR release will be great, we could only today works against tagged release (latest against Apache HTTPD 2.0.32 beta) IMHO - jk2.0 should keep the old code and be able to operate without APR ( but default to APR ). +1 In 2.1 we can drop the old code and use APR exclusively. +1 The current design allows one to use 'native' APIs - if a server has a pool-equivalent it can be used ( so in Apache1.3 we have the choice between 1.3 pool, apr pool, or jk pool ). Same for logging, maps. Long term I think it would be good to use the 'natives' whenever possible, and APR for missing features. +10 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: mod_jk suggestion, add request logging option
So if I wanted to add the request logging feature to mod_jk 1.2 there is still time to do that? And should those changes be committed to the HEAD CVS branch of jakarta-tomcat-connectors? mod_jk 1.2 in JTC is not feature freeze, so let's commit there, some will port the update to mod_jk 2.0 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 6610] New: - Request-Time Attribute Expressions in XML-Syntax JSPs not working
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6610. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6610 Request-Time Attribute Expressions in XML-Syntax JSPs not working Summary: Request-Time Attribute Expressions in XML-Syntax JSPs not working Product: Tomcat 4 Version: 4.0.2 Final Platform: All OS/Version: All Status: NEW Severity: Normal Priority: Other Component: Jasper AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] The Request-Time Attribute Expressions in XML coded JSPs are not working. JSP-Syntax: my:tag attribute=%= some-java-code % / should be the same as my:tag attribute=%= some-java-code % / in a XML-coded JSP page. This doesn't work, the strings %= ... % is forwarded unevaluated. See JSP Spec V 1.2 (JSP.5.3.11) for details. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 6557] - isapi_redirector can not handle post request from netscape 4.7x
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6557. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6557 isapi_redirector can not handle post request from netscape 4.7x [EMAIL PROTECTED] changed: What|Removed |Added Component|Connectors |HTTP/1.1 Connector Product|Tomcat 3|Tomcat 4 Version|3.3 Release Candidate 2 |Unknown --- Additional Comments From [EMAIL PROTECTED] 2002-02-21 16:22 --- why does nobody response? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 6557] - isapi_redirector can not handle post request from netscape 4.7x
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6557. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6557 isapi_redirector can not handle post request from netscape 4.7x --- Additional Comments From [EMAIL PROTECTED] 2002-02-21 16:19 --- Created an attachment (id=1222) dump of data thru http -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
AW: mod_jk suggestion, add request logging option
Hi, what about adding 'port' to the list. For lb workers the worker would be the real one used not 'loadbalancer', right? I think it would be really helpful to have this log level. Cheers, Hans -Ursprungliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]Im Auftrag von Glenn Nielsen Gesendet: Donnerstag, 21. Februar 2002 16:57 An: Tomcat Developers List Betreff: Re: mod_jk suggestion, add request logging option Updated list of fields for request logging. Timestamp worker host URI Status (OK, FAIL, etc) Latency (Time in ms or us to handle request) Glenn Glenn Nielsen wrote: Currently mod_jk has four logging levels - (debug,info,error,emerg). I suggest a fifth log level be added called request. (debug, info, request, error, emerg) This log level would log each request with the following possible info, what info is logged could be controlled by an new config option JkLogRequestFormat. Timestamp URI Status (OK, FAIL, etc) Latency (Time in ms or us to handle request) And there may be other fields of interest to add to the above list. I am most interested in using mod_jk to log the request latency for Tomcat to handle different requests so that statistics can be generated. Having mod_jk do this instead of Tomcat avoids violating the heisenberg principal. Regards, Glenn -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | -- -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | -- -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 6557] - isapi_redirector can not handle post request from netscape 4.7x
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6557. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6557 isapi_redirector can not handle post request from netscape 4.7x [EMAIL PROTECTED] changed: What|Removed |Added Component|HTTP/1.1 Connector |Connectors Product|Tomcat 4|Tomcat 3 Version|Unknown |3.3 Final --- Additional Comments From [EMAIL PROTECTED] 2002-02-21 17:43 --- Changing it back to Tomcat3 since the data supplied is for Tomcat 3.3. Based on your attached data, please try Ajp13 and see if the problem is still present there. Ajp12 is deprecated in Tomcat 3.3 (i.e. bugs aren't likely to be fixed) and isn't supported at all in Tomcat 4.x. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: mod_jk suggestion, add request logging option
On Thu, 21 Feb 2002, Glenn Nielsen wrote: Currently mod_jk has four logging levels - (debug,info,error,emerg). I suggest a fifth log level be added called request. (debug, info, request, error, emerg) This log level would log each request with the following possible info, what info is logged could be controlled by an new config option JkLogRequestFormat. +1, I don't know if I'll have time to help too much, but it's a good idea. However it may be easier to use the apache logger for that - it provides most of the info you need ( the access log ), and if you need more it is reasonably easy to add ( i.e. as a contribution to httpd project, or just create a new access log module that extends the current one. This is general-purpose and used for all requets. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: mod_jk suggestion, add request logging option
I suggest a fifth log level be added called request. (debug, info, request, error, emerg) This log level would log each request with the following possible info, what info is logged could be controlled by an new config option JkLogRequestFormat. +1, I don't know if I'll have time to help too much, but it's a good idea. However it may be easier to use the apache logger for that - it provides most of the info you need ( the access log ), and if you need more it is reasonably easy to add ( i.e. as a contribution to httpd project, or just create a new access log module that extends the current one. This is general-purpose and used for all requets. Some may want to have this kind of debug also on IIS/iPlanet ? So will have to format the log message to apache logger and of course flat file on non Apache Web Servers ;) If you, requesters, have any code to add such stuff, I'll be happy to review and make necessary adaptation for mod_jk 1.2/2.0 ;) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: mod_jk suggestion, add request logging option
GOMEZ Henri wrote: These features could be added to mod_jk 1.2.0 (native) and 2.0.0 (native2) in jakarta-tomcat-connectors. What is the status of mod_jk (2) 1.2 and Ajp 14? mod_jk 1.2 is the original mod_jk from TC 3.3, with little cleanup. mod_jk 2.0 is a serious rewrite of mod_jk, using OO in C (Costin like OO), which will support ajp14. ajp14 is now a sort of ajp13++, as it works on ajp13 connections , but add extras features. As such an Ajp14 Java side connector is also an Ajp13 connector (Ajp13++ in fact) I went back through alot of the proposals and followup emails on the list, but I am unsure of where development of these is at. The works is in progress :) The mod_jk in TC 3.3 is now feature freezed Fine with me. -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | -- -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: mod_jk suggestion, add request logging option
OK, I think that explains it. So mod_jk 2.0 and Ajp14 are still in development, and it may be a while before they are finished. Depends on how many people will help, a known story ;) What about mod_jk 1.2, when will that be ready for production use? Ready to use, I'm using it since TC 4.0.2 release against TC 3.3 and 4.0.2 boxes without problems -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: mod_jk suggestion, add request logging option
On Thu, 21 Feb 2002, Glenn Nielsen wrote: OK, I think that explains it. So mod_jk 2.0 and Ajp14 are still in development, and it may be a while before they are finished. What is the status of mod_jk (2) 1.2 and Ajp 14? My opinion: Jk2 supports all the features from jk1 ( and some more ). There are probably some new bugs and some old bugs that still need to be ported, but feature-wise the code can replace jk1 as soon as there is enough will and interest to do so. For the first release of jk2 the major goal is to be 'as good or better' than jk1. It is already a bit faster, IMHO it's much cleaner, and it has some nice extra features - that may not be yet ready ( like unix sockets, I think only me and JFC tested it ). But as a replacement for jk1, jk2 is already as good ( most of the code for ajp13 was just cutpasted ). All it needs is 3-4 tomcat commiters who are willing to review and play with the code - and we can move to beta. I don't plan too many more changes in the APIs, except those requeted by reviewers. On the java side things are much better, I did a lot of testing of the low level stuff and there are many optimizations ( like C2B conversions, etc ). It'll probably be most visible on tomcat4, but also tomcat33 will see some benefits from the new connector. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
AW: AW: mod_jk suggestion, add request logging option
-Ursprungliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]Im Auftrag von Glenn Nielsen Gesendet: Donnerstag, 21. Februar 2002 19:28 An: Tomcat Developers List Betreff: Re: AW: mod_jk suggestion, add request logging option Hans Schmid wrote: Hi, what about adding 'port' to the list. Is this the port the http request came in on, or the port for the worker? I thought of the host and port of the worker. In our setup we send different workers to different hosts (even loadbalanced workers) So its easy to see where the request was sent to. But if we can configure, which of the fields we want to see in the log there can't be too much availlable :) Cheers, Hans For lb workers the worker would be the real one used not 'loadbalancer', right? Yes, you would want the worker which points at the actual instance of Tomcat the request was forwarded to. I think it would be really helpful to have this log level. Cheers, Hans -Ursprungliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]Im Auftrag von Glenn Nielsen Gesendet: Donnerstag, 21. Februar 2002 16:57 An: Tomcat Developers List Betreff: Re: mod_jk suggestion, add request logging option Updated list of fields for request logging. Timestamp worker host URI Status (OK, FAIL, etc) Latency (Time in ms or us to handle request) Glenn Glenn Nielsen wrote: Currently mod_jk has four logging levels - (debug,info,error,emerg). I suggest a fifth log level be added called request. (debug, info, request, error, emerg) This log level would log each request with the following possible info, what info is logged could be controlled by an new config option JkLogRequestFormat. Timestamp URI Status (OK, FAIL, etc) Latency (Time in ms or us to handle request) And there may be other fields of interest to add to the above list. I am most interested in using mod_jk to log the request latency for Tomcat to handle different requests so that statistics can be generated. Having mod_jk do this instead of Tomcat avoids violating the heisenberg principal. Regards, Glenn -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | -- -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | -- -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | -- -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 6557] New: - isapi_redirector can not handle post request from netscape 4.7x
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6557. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6557 isapi_redirector can not handle post request from netscape 4.7x Summary: isapi_redirector can not handle post request from netscape 4.7x Product: Tomcat 3 Version: 3.3 Release Candidate 2 Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Major Priority: Other Component: Connectors AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] when i post a requst by calling NPN_PostURLNotify(), ns plug-in api. iis_redirect could not forward the request to tomcat the problem i addressed was ns4.7x sends the request in seperate steps, eg. 1. send the http request header 2. send an 0x0d 3. send an 0x0a 4. send the request body but iis_redirect only forward the first pieces, and tomcat will not get any request body data looking for a fix for this issue -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 6557] - isapi_redirector can not handle post request from netscape 4.7x
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6557. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6557 isapi_redirector can not handle post request from netscape 4.7x --- Additional Comments From [EMAIL PROTECTED] 2002-02-19 20:18 --- well, it was a netscape 4.7 issue. but the apache addon module of tomcat can handle such case. i think the isapi_redirect should do so, right? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 6557] - isapi_redirector can not handle post request from netscape 4.7x
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6557. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6557 isapi_redirector can not handle post request from netscape 4.7x [EMAIL PROTECTED] changed: What|Removed |Added Priority|Other |High --- Additional Comments From [EMAIL PROTECTED] 2002-02-19 20:35 --- i changed the priority to high because iis nt service can not be stopped after such a 'post' -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 6531] New: - Request Dispatcher forward to j_security_check not working
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6531. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6531 Request Dispatcher forward to j_security_check not working Summary: Request Dispatcher forward to j_security_check not working Product: Tomcat 4 Version: Nightly Build Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Normal Priority: Other Component: Unknown AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I'm trying to use the following concept to encrypt my password before authenticating (b/c password in db in encrypted). http://www.mail-archive.com/struts-user@jakarta.apache.org/msg22257.html snip String req = j_security_check?j_username= + form.getUsername() + j_password= + StringUtil.encodeString(form.getPassword()); RequestDispatcher rd = request.getRequestDispatcher(req); rd.forward(request, response); /snip In Tomcat 4.0.1, 4.0.2 and the nightly build, this results in the following error: Apache Tomcat/4.0.1 - HTTP Status 404 - /j_security_check type Status report message /j_security_check description The requested resource (/j_security_check) is not available. This code works GREAT in Tomcat 3.2.4. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 6531] - Request Dispatcher forward to j_security_check not working
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6531. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6531 Request Dispatcher forward to j_security_check not working [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2002-02-19 02:24 --- Applications that try to reference the j_security_check URL by any means are guaranteed to be non-portable, because the spec only defines this URL as being significant when the *container* sends back the form login page. In fact, that is the way that Tomcat 4 implements it, so trying to use a request dispatcher to forward control to this page is not going to work, because the URL doesn't exist at that point in time (hence the 404 error). An alternative approach would be to subclass one of the existing Realm implementations and make it do the encoding for you before calling the real authenticate() method in its superclass. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 6515] New: - tomcat sets response headers in sub request
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6515.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6515
tomcat sets response headers in sub request
Summary: tomcat sets response headers in sub request
Product: Tomcat 3
Version: 3.3 Final
Platform: Other
OS/Version: Other
Status: NEW
Severity: Major
Priority: Other
Component: Unknown
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
In respect to included content, Section 8.3 of the servlet 2.2 specification
states: The included servlet cannot set headers or call any method that affects
the headers of the response. Any attempt to do so should be ignored.
In the FileHandler class of
org.apache.tomcat.modules.generators.StaticInterceptor, the response headers for
content type, content length and date are always set, even if it is a
sub-request - the setting of the response headers should be conditional on the
request being a top level request
In the 3.3.x nightly builds, the following patch needs to be applied.
--- src/share/org/apache/tomcat/modules/generators/StaticInterceptor.java
Fri Feb 15 22:23:08 2002
+++ StaticInterceptor.java Mon Feb 18 13:36:38 2002
@@ -324,6 +324,7 @@
File file = new File( absPath );
// If we are included, the If-Modified-Since isn't for us.
+ // Nor is the setting of response headers
if( ! res.isIncluded() ) {
MessageBytes imsMB=req.getMimeHeaders().getValue(If-Modified-Since);
@@ -340,20 +341,20 @@
}
- }
- if( debug0) log( After paranoic checks = + absPath);
+ if( debug0) log( After paranoic checks = + absPath);
-String mimeType=ctx.getMimeMap().getContentTypeFor(absPath);
+String mimeType=ctx.getMimeMap().getContentTypeFor(absPath);
- if (mimeType == null) {
- mimeType = text/plain;
- }
- if( debug0) log( Serving + absPath);
+ if (mimeType == null) {
+ mimeType = text/plain;
+ }
+ if( debug0) log( Serving + absPath);
- res.setContentType(mimeType);
- res.setContentLength((int)file.length());
+ res.setContentType(mimeType);
+ res.setContentLength((int)file.length());
- setDateHeader(res, Last-Modified, file.lastModified());
+ setDateHeader(res, Last-Modified, file.lastModified());
+ }
FileInputStream in=null;
try {
// end patch
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 6515] - tomcat sets response headers in sub request
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6515. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6515 tomcat sets response headers in sub request [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2002-02-18 03:46 --- The problem is more general than just StaticInterceptor. Checking the code, only the Last-Modified header was getting through. That hole has now been closed in the CVS HEAD, and will appear in 3.3.1-RC1. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Feature request - context as a vhost and a sub-dir
Hi, Would it be possible for contexts to exist as a vhost (cntxt.domain.ext) and a sub-dir (www.domain.ext/cntxt) at the same time? Greetings, deacon Marcus -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 6137] New: - Context Administration removes /ROOT instead of the specified context at first remove request
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6137. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6137 Context Administration removes /ROOT instead of the specified context at first remove request Summary: Context Administration removes /ROOT instead of the specified context at first remove request Product: Tomcat 3 Version: 3.3 Final Platform: All OS/Version: All Status: NEW Severity: Normal Priority: Other Component: Webapps AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] When using the Tomcat 3.3 Context Administration web interface to remove a context by name (say, context /test) the context /ROOT gets removed instead of the specified one. The following is logged: 2002-01-30 23:48:18 - ContextManager: Removing context DEFAULT:/ROOT 2002-01-30 23:48:18 - Ctx() : Remove mapping On second subsequent request to remove the same context it actually removes it giving out the following 2002-01-30 23:48:28 - ContextManager: Removing context DEFAULT:/test 2002-01-30 23:48:28 - Ctx(/test) : Remove mapping /test 2002-01-30 23:48:28 - Ctx(/test) : Remove mapping /test/test And in the servlet log the expected: test: test: destroy On further requests to add or remove the context it works as expected. However, if the context /ROOT is added then it gets removed again when trying to remove some other context. The context removing via the context list (View All Contexts) works as expected removing the specified context. I have seen this behaviour on Tomcat 3.3a and Tomcat 3.3.1-dev (2002-01-30) (directly out of package, just modifying conf/apps-admin.xml to make admin webapp trusted). The JVM is Sun JDK 1.3.1_02 on Linux. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 6137] - Context Administration removes /ROOT instead of the specified context at first remove request
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6137. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6137 Context Administration removes /ROOT instead of the specified context at first remove request [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2002-01-31 03:40 --- This is now fixed in the CVS HEAD, and should appear in the 1/31 nightly. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Update Request
Hi, When you are creating a default mail session you are using the Session.getDefaultInstance method - can this be changed to Session.getInstance. The reason being that the former seems to create an instance for the JVM and regardless of consequent changes to the SMTP host they are ignored. The latter resolves this problem. Thanks Regards Asar Khan - --- Visit our Internet site at http://www.reuters.com Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Reuters Ltd. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 5853] New: - Unable to get request parameters in the Error page for form based login
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5853. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5853 Unable to get request parameters in the Error page for form based login Summary: Unable to get request parameters in the Error page for form based login Product: Tomcat 4 Version: Nightly Build Platform: All OS/Version: All Status: NEW Severity: Major Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Case: While implementing Form Based login with declarative security in Tomcat , if one tries to access the request parameter(s) , in the Error Page configured for the login, one is unable to get the parameter. eg: If LoginServ is the servlet that needs to be authenticated,and form.jsp and error.jsp are the login for and error form respectively. Then the user is unable to get any request parameters in Error.jsp -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 5785] New: - XML request time attribute not generated correctly
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5785.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5785
XML request time attribute not generated correctly
Summary: XML request time attribute not generated correctly
Product: Tomcat 4
Version: 4.0.1 Final
Platform: PC
OS/Version: Windows NT/2K
Status: NEW
Severity: Normal
Priority: Other
Component: Jasper
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
Example JSP: converted and modified from foo.jsp in the examples/jsp/simpletag
directory.
jsp:root
xmlns:jsp=http://java.sun.com/JSP/Page;
xmlns:eg=http://jakarta.apache.org/tomcat/examples-taglib;
version=1.2
html
body
Radio stations that rock:
ul
eg:foo att1=98.5 att2=92.3 att3=107.7
form action=%= member %/
lijsp:expressionmember/jsp:expression/li
/eg:foo
/ul
/body
/html
/jsp:root
The jsp:expression is generated okay. But the request-time expression in the
action attribute is not.
It seems if a tag is considered 'uninterpreted', then the attributes are simply
output to the servlet writer.
Possible fix:
diff -C 5
tomcat/src/jasper/src/share/org/apache/jasper/compiler/UninterpretedTagBeginGenerator.java
jakarta-tomcat-4.0.1-src/jasper/src/share/org/apache/jasper/compiler/UninterpretedTagBeginGenerator.java
***
tomcat/src/jasper/src/share/org/apache/jasper/compiler/UninterpretedTagBeginGenerator.java
Mon Jan 7 16:35:34 2002
---
jakarta-tomcat-4.0.1-src/jasper/src/share/org/apache/jasper/compiler/UninterpretedTagBeginGenerator.java
Sun Oct 14 12:14:32 2001
***
*** 102,121
String quote = doubleQuote;
String name = attrs.getQName(i);
String value = attrs.getValue(i);
if (value.indexOf('') != -1) quote = singleQuote;
sb.append( ).append(name).append(=).append(quote);
! if (JspUtil.isExpression(value, true))
! {
! sb.append(\););
! sb.append(out.print( + new
String(JspUtil.escapeXml(JspUtil.getExpr(value, true))) + ););
! sb.append(out.write(\).append(quote);
! }
! else
! {
! sb.append(value).append(quote);
! }
}
sb.append();
}
writer.print(sb.toString());
writer.print(\););
--- 102,112
String quote = doubleQuote;
String name = attrs.getQName(i);
String value = attrs.getValue(i);
if (value.indexOf('') != -1) quote = singleQuote;
sb.append( ).append(name).append(=).append(quote);
! sb.append(value).append(quote);
}
sb.append();
}
writer.print(sb.toString());
writer.print(\););
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 5742] New: - manager application hangs if the context is currently processing a request
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5742. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5742 manager application hangs if the context is currently processing a request Summary: manager application hangs if the context is currently processing a request Product: Tomcat 4 Version: 4.0.1 Final Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Normal Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I have noticed that if I try to use the manager 'reload' feature at the same time that a request is being processed for the given path, that both the manager request and the context request hang and eventually time out. The context at this point become unusable and tomcat must be restarted to get the context back. Another manager command to 'stop' times out also. All other contexts/virtual hosts still work fine. The requested servlet in the context would normally return in about 1-2 seconds. I can consistantly repeat this condition. This is what is in the error log: 2002-01-08 10:53:57 Manager: restart: Reloading web application at '/' 2002-01-08 10:53:57 StandardContext[]: Reloading this Context has started 2002-01-08 10:53:57 StandardWrapper[:ContentServlet]: Waiting for 2 instance(s) to be deallocated If I try a stop request, it also times out and the following is added to the log file: 2002-01-08 11:01:45 Manager: stop: Stopping web application at '/' 2002-01-08 11:01:45 StandardHost[www.socratesxml.com]: standardHost.stop Charlie -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 5742] - manager application hangs if the context is currently processing a request
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5742. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5742 manager application hangs if the context is currently processing a request [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2002-01-08 08:17 --- This problem has just been fixed (thanks again David). *** This bug has been marked as a duplicate of 5719 *** -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Fix for mod_webapp - warp connector operation under SSL client request
I sent a patch in last night that I don't think would have been accepted for the
simple reason I have not followed the patch guidelines.
I apologize for that.
I'm currently looking at mod_webapp as I'm trying to write a JSP application with
Tomcat under Debian Linux (i386 - bleeding edge unstable).
The problem appears to be that there are atleast two different options for
SSL..ApacheSSL and mod_ssl. Unfortunately, mod_webapp seems to have been developed
using mod_ssl as the reference. Essentially there are settings that mod_ssl makes in
the r-ctx when it sets up for handling the request.
The only way that I've successfully been able to get mod_webapp to pass the correct
scheme and SSL values is to do the following:
cvs server: Diffing .
Index: mod_webapp.c
===
RCS file: /home/cvspublic/jakarta-tomcat-connectors/webapp/apache-1.3/mod_webapp.c,v
retrieving revision 1.29
diff -u -r1.29 mod_webapp.c
--- mod_webapp.c1 Nov 2001 22:20:51 - 1.29
+++ mod_webapp.c3 Jan 2002 16:56:33 -
@@ -439,6 +439,9 @@
return(HTTP_INTERNAL_SERVER_ERROR);
}
+ap_add_cgi_vars(r);
+ap_add_common_vars(r);
+
/* Set up the WebApp Library request structure client and server host
data (from the connection */
stmp=(char *)r-hostname;
@@ -457,7 +460,6 @@
req-ruri=apr_pstrdup(req-pool,r-uri);
req-args=apr_pstrdup(req-pool,r-args);
req-prot=apr_pstrdup(req-pool,r-protocol);
-req-schm=apr_pstrdup(req-pool,ap_http_method(r));
req-user=apr_pstrdup(req-pool,con-user);
req-auth=apr_pstrdup(req-pool,con-ap_auth_type);
req-clen=0;
@@ -467,6 +469,7 @@
/* SSL logic */
ssl_temp = (char *)ap_table_get(r-subprocess_env,HTTPS);
if ( ssl_temp !strcasecmp(ssl_temp, on)) {
+req-schm=apr_pstrdup(req-pool,https);
req-ssld=(wa_ssldata *) apr_palloc(req-pool,sizeof(wa_ssldata));
req-ssld-ciph = (char *)ap_table_get(
@@ -484,6 +487,7 @@
req-ssld-cert = (char *)ap_table_get(
r-subprocess_env,SSL_CLIENT_CERT);
} else {
+req-schm=apr_pstrdup(req-pool,http);
req-ssld=NULL;
}
==
if someone could please do a code review on this for me and tell me if this is the
correct way to perform this operation I would really appreciate it.
This could looks like it would also have to be added to the apache-2.0 module as well.
DO NOT REPLY [Bug 5531] New: - ISAPI (iss_redirect.dll) doesn't forward the request
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5531. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5531 ISAPI (iss_redirect.dll) doesn't forward the request Summary: ISAPI (iss_redirect.dll) doesn't forward the request Product: Tomcat 3 Version: 3.3 Final Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Major Priority: Other Component: Connectors AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] ISAPI (iss_redirect.dll) doesn't forward the request. It send me: not found: /jakarta/iis_redirect.dll in browser -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 5531] - ISAPI (iss_redirect.dll) doesn't forward the request
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5531. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5531 ISAPI (iss_redirect.dll) doesn't forward the request [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2001-12-20 06:12 --- The URL /jakarta/isapi_redirect (I'm assuming a typo in iss_redirect.dll) is only used internally. It should never be invoked by or seen by the browser. On NT/Win2k, make sure you do not add the Filter DLLs key, this applies only to Win9x. Delete it if it has been added. There are not a lot of details on which to base the above answer. If there is still a problem, re-open the bug and provide more details. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Difference in the Request class between Tomcat 3.2 and Tomcat 3.3
Hi all, What happened to methods getRemoteAddr, getServerName, getServletPath in the Request class for Tomcat 3.3 ? I had an Interceptor written for Tomcat 3.2 that uses these methods within the Request. How can I access internal servlet information from Request int Tomcat 3.3 ? Thanks again Renato - Brazil. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Difference in the Request class between Tomcat 3.2 and Tomcat 3.3
Just found it... they change names... ( silly me :)) ) On Wed Dec 19 11:54:57 2001, Renato [EMAIL PROTECTED] escreveu : Hi all, What happened to methods getRemoteAddr, getServerName, getServletPath in the Request class for Tomcat 3.3 ? I had an Interceptor written for Tomcat 3.2 that uses these methods within the Request. How can I access internal servlet information from Request int Tomcat 3.3 ? Thanks again Renato - Brazil. -- To unsubscribe, e-mail: mailto:tomcat-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:tomcat-dev- [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 4828] - getSession(true) gets last valid session iven if invalidated during same request
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4828. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4828 getSession(true) gets last valid session iven if invalidated during same request [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Additional Comments From [EMAIL PROTECTED] 2001-12-09 17:16 --- This works for me against the 4.0.1 release code as well as against the current development branch. In addition, one of the unit test cases (Session04.java) does exactly this operation -- invalidate an old sesion, create a new one, and ensure that you got a different session. Could you try this against the 4.0.1 release code and reopen the bug (with a reproducible test case) if it still fails for you? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 5169] - If jsp_precompile is evalutated to be false, the request will be processed by the target JSP
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5169. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5169 If jsp_precompile is evalutated to be false, the request will be processed by the target JSP [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2001-11-29 12:00 --- Fixed (nightly 20011130), thanks Ryan Lubke for the patch. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 5169] New: - If jsp_precompile is evalutated to be false, the request will be processed by the target JSP
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5169. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5169 If jsp_precompile is evalutated to be false, the request will be processed by the target JSP Summary: If jsp_precompile is evalutated to be false, the request will be processed by the target JSP Product: Tomcat 4 Version: 4.0.1 Final Platform: All OS/Version: All Status: NEW Severity: Major Priority: Other Component: Jasper AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] JavaServer Pages Specification 1.2, Section JSP.8.4.2: The jsp_precompile parameter may have no value, or may have the values true or false. In all cases, the request should not be delivered to the JSP page. With Tomcat, if the jsp_precompile parameter is false, the request is delivered to the target JSP page. This is a violation of the spec. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 5171] New: - ContextManager: Error reading request, ignored - java.lang.ArrayIndexOutOfBoundsException: 2048
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5171. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5171 ContextManager: Error reading request, ignored - java.lang.ArrayIndexOutOfBoundsException: 2048 Summary: ContextManager: Error reading request, ignored - java.lang.ArrayIndexOutOfBoundsException: 2048 Product: Tomcat 3 Version: 3.2 Final Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Blocker Priority: Other Component: Servlet AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I have a html table which displays 104 rows approximately each column of the HTML row has some form elements like check boxes, textfield and dropdowns. When I am editing these rows and trying to save the edits, I am getting this exception. ContextManager: Error reading request, ignored - java.lang.ArrayIndexOutOfBoundsException: 2048 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 5171] - ContextManager: Error reading request, ignored - java.lang.ArrayIndexOutOfBoundsException: 2048
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5171. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5171 ContextManager: Error reading request, ignored - java.lang.ArrayIndexOutOfBoundsException: 2048 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2001-11-28 15:45 --- *** This bug has been marked as a duplicate of 3784 *** -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 5126] New: - Client request using HEAD results in a response body returned to client.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5126.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5126
Client request using HEAD results in a response body returned to client.
Summary: Client request using HEAD results in a response body
returned to client.
Product: Tomcat 4
Version: 4.0.1 Final
Platform: All
OS/Version: All
Status: NEW
Severity: Normal
Priority: Other
Component: HTTP/1.1 Connector
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
According to the HTTP 1.0 and 1.1 RFC's if a client uses the HEAD method for the
request, a response-body *must* not be returned, only the headers that would
have been returned for a normal GET request for that resource.
telnet myhost 8000
Trying 100.100.100.118...
Connected to myhost.
Escape character is '^]'.
HEAD /foo HTTP/1.0
HTTP/1.1 404 /foo
Content-Type: text/html
Date: Tue, 27 Nov 2001 14:17:04 GMT
Server: Apache Tomcat/4.0.1 (HTTP/1.1 Connector)
Connection: close
htmlheadtitleApache Tomcat/4.0.1 - Error
report/titleSTYLE!--H1{font-family : sans-serif,Arial,Tahoma;color :
white;background-color : #0086b2;} BODY{font-family :
sans-serif,Arial,Tahoma;color : black;background-color : white;} B{color :
white;background-color : #0086b2;} HR{color : #0086b2;} --/STYLE
/headbodyh1Apache Tomcat/4.0.1 - HTTP Status 404 - /foo/h1HR size=1
noshadepbtype/b Status report/ppbmessage/b
u/foo/u/ppbdescription/b uThe requested resource (/foo) is not
available./u/pHR size=1 noshade/body/htmlConnection closed by
foreign host.
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 5126] - Client request using HEAD results in a response body returned to client.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5126. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5126 Client request using HEAD results in a response body returned to client. [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2001-11-27 08:42 --- Fixed in the CVS HEAD branch. The nightly for 11/28 will have the fix, and the fix will be ported to the 4.0 branch. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 4828] New: - getSession(true) gets last valid session iven if invalidated during same request
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4828. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4828 getSession(true) gets last valid session iven if invalidated during same request Summary: getSession(true) gets last valid session iven if invalidated during same request Product: Tomcat 4 Version: 4.0 Beta 7 Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Major Priority: Other Component: Webapps AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I remove an attribute from a session, invalidate it but if i do getSession (true) during the same request I get the Session I started with at the beginning of the same request. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: How does Tomcat handle discarded-request
Thank you. Bill and Craig.
David
--
From: Bill Barker[SMTP:[EMAIL PROTECTED]]
Reply To: Tomcat Developers List
Sent: Thursday, November 01, 2001 6:28 PM
To: Tomcat Developers List
Subject: Re: How does Tomcat handle discarded-request
Generally with 3.2.x it will throw there, but it may throw later due to
buffering. And since the browser has closed the connection, no you can't
send/receive anything further. Of course, there is nothing to prevent you
inclosing your code in a try {} finally {} block if workBean needs to do
cleanup.
- Original Message -
From: Hu, Xuebing [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED]
Sent: Thursday, November 01, 2001 2:39 PM
Subject: RE: How does Tomcat handle discarded-request
Hi, Craig,
Here is my skeleton jsp,
jsp:useBean id=workBean class=... ...
/jsp:useBean
%
Object param1=getParameter(Param1) ;
...
Object paramn = getParameter(Paramn) ;
// let us say that doWork takes a few minutes to finish
// and I just can not wait at the browser side and I issues
another request to TOMCAT
Object result = workBean.doWork(param1, ..., paramn) ;
// Is IOException thrown out here?
out.println(result) ;
%
As per your explaination, is IOException thrown out on out.println()???,
since it is JSP, so my workBean has no way to talk to something at the
browser side to get data.
thanks,
David
--
From: Craig R. McClanahan[SMTP:[EMAIL PROTECTED]]
Reply To: Tomcat Developers List
Sent: Thursday, November 01, 2001 5:08 PM
To: Tomcat Developers List
Cc: Hu, Xuebing
Subject: RE: How does Tomcat handle discarded-request
On Thu, 1 Nov 2001, Hu, Xuebing wrote:
Date: Thu, 1 Nov 2001 17:03:29 -0500
From: Hu, Xuebing [EMAIL PROTECTED]
Reply-To: Tomcat Developers List [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED]
Subject: RE: How does Tomcat handle discarded-request
Thanks, Bill for the response. Any detail? I am currently using TOMCAT
3.2.3.
In general, you cannot count on the server even knowing that the request
was cancelled. The following scenarios are all possible:
* The entire request was read before the cancel happened, so no
notification is possible until the response is written back out
and receives an IOException. (This is by far the most common case.)
* Tomcat was able to read the headers, but does not need to read
the data. In this case, it is the application (not Tomcat) that
would receive an IOException when trying to process the input
stream. Therefore, it is up to your application to respond
appropriately.
* Tomcat was unable to read the headers (because the cancel happened
very quickly). It will typically log an exception and throw the
request away.
David
Craig
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
**
This message is intended only for the use of the person(s) listed above
as the intended recipient(s), and may contain information that is
PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient,
you may not read, copy, or distribute this message or any attachment.
If you received this communication in error, please notify us immediately
by e-mail and then delete all copies of this message and any attachments.
In addition you should be aware that ordinary (unencrypted) e-mail sent
through the Internet is not secure. Do not send confidential or sensitive
information, such as social security numbers, account numbers, personal
identification numbers and passwords, to us via ordinary (unencrypted)
e-mail.
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
How does Tomcat handle discarded-request
Hi, I issues to Tomcat one request which takes kind of long time to response, when the backend servlet or bean is working on the result, I just can not wait and clicked somewhere on my browser page to issue another request, in this case, I am wondering what Tomcat to do with the previous working servlet, is it still runing until finish or Tomcat just kill the thread and force it stop. The question is closely related to connection pool, without the work finish, the connection will not be returned to pool in working bean or servlet, I suppose that Tomcat keeps the servlet thread running until it finishes, otherwise, there is no way for the servlet to finish his work and return connection. Any response is appreciated. Thanks, David -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: How does Tomcat handle discarded-request
This depends on the version of Tomcat, and to some extent whether you are running Tomcat behind another web server. - Original Message - From: Hu, Xuebing [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, November 01, 2001 11:57 AM Subject: How does Tomcat handle discarded-request Hi, I issues to Tomcat one request which takes kind of long time to response, when the backend servlet or bean is working on the result, I just can not wait and clicked somewhere on my browser page to issue another request, in this case, I am wondering what Tomcat to do with the previous working servlet, is it still runing until finish or Tomcat just kill the thread and force it stop. The question is closely related to connection pool, without the work finish, the connection will not be returned to pool in working bean or servlet, I suppose that Tomcat keeps the servlet thread running until it finishes, otherwise, there is no way for the servlet to finish his work and return connection. Any response is appreciated. Thanks, David -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] ** This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: How does Tomcat handle discarded-request
Thanks, Bill for the response. Any detail? I am currently using TOMCAT 3.2.3. David -- From: Bill Barker[SMTP:[EMAIL PROTECTED]] Reply To: Tomcat Developers List Sent: Thursday, November 01, 2001 2:57 PM To: Tomcat Developers List Subject: Re: How does Tomcat handle discarded-request This depends on the version of Tomcat, and to some extent whether you are running Tomcat behind another web server. - Original Message - From: Hu, Xuebing [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, November 01, 2001 11:57 AM Subject: How does Tomcat handle discarded-request Hi, I issues to Tomcat one request which takes kind of long time to response, when the backend servlet or bean is working on the result, I just can not wait and clicked somewhere on my browser page to issue another request, in this case, I am wondering what Tomcat to do with the previous working servlet, is it still runing until finish or Tomcat just kill the thread and force it stop. The question is closely related to connection pool, without the work finish, the connection will not be returned to pool in working bean or servlet, I suppose that Tomcat keeps the servlet thread running until it finishes, otherwise, there is no way for the servlet to finish his work and return connection. Any response is appreciated. Thanks, David -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] ** This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: How does Tomcat handle discarded-request
On Thu, 1 Nov 2001, Hu, Xuebing wrote: Date: Thu, 1 Nov 2001 17:03:29 -0500 From: Hu, Xuebing [EMAIL PROTECTED] Reply-To: Tomcat Developers List [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Subject: RE: How does Tomcat handle discarded-request Thanks, Bill for the response. Any detail? I am currently using TOMCAT 3.2.3. In general, you cannot count on the server even knowing that the request was cancelled. The following scenarios are all possible: * The entire request was read before the cancel happened, so no notification is possible until the response is written back out and receives an IOException. (This is by far the most common case.) * Tomcat was able to read the headers, but does not need to read the data. In this case, it is the application (not Tomcat) that would receive an IOException when trying to process the input stream. Therefore, it is up to your application to respond appropriately. * Tomcat was unable to read the headers (because the cancel happened very quickly). It will typically log an exception and throw the request away. David Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: How does Tomcat handle discarded-request
Hi, Craig, Here is my skeleton jsp, jsp:useBean id=workBean class=... ... /jsp:useBean % Object param1=getParameter(Param1) ; ... Object paramn = getParameter(Paramn) ; // let us say that doWork takes a few minutes to finish // and I just can not wait at the browser side and I issues another request to TOMCAT Object result = workBean.doWork(param1, ..., paramn) ; // Is IOException thrown out here? out.println(result) ; % As per your explaination, is IOException thrown out on out.println()???, since it is JSP, so my workBean has no way to talk to something at the browser side to get data. thanks, David -- From: Craig R. McClanahan[SMTP:[EMAIL PROTECTED]] Reply To: Tomcat Developers List Sent: Thursday, November 01, 2001 5:08 PM To: Tomcat Developers List Cc: Hu, Xuebing Subject: RE: How does Tomcat handle discarded-request On Thu, 1 Nov 2001, Hu, Xuebing wrote: Date: Thu, 1 Nov 2001 17:03:29 -0500 From: Hu, Xuebing [EMAIL PROTECTED] Reply-To: Tomcat Developers List [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Subject: RE: How does Tomcat handle discarded-request Thanks, Bill for the response. Any detail? I am currently using TOMCAT 3.2.3. In general, you cannot count on the server even knowing that the request was cancelled. The following scenarios are all possible: * The entire request was read before the cancel happened, so no notification is possible until the response is written back out and receives an IOException. (This is by far the most common case.) * Tomcat was able to read the headers, but does not need to read the data. In this case, it is the application (not Tomcat) that would receive an IOException when trying to process the input stream. Therefore, it is up to your application to respond appropriately. * Tomcat was unable to read the headers (because the cancel happened very quickly). It will typically log an exception and throw the request away. David Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: How does Tomcat handle discarded-request
Generally with 3.2.x it will throw there, but it may throw later due to
buffering. And since the browser has closed the connection, no you can't
send/receive anything further. Of course, there is nothing to prevent you
inclosing your code in a try {} finally {} block if workBean needs to do
cleanup.
- Original Message -
From: Hu, Xuebing [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED]
Sent: Thursday, November 01, 2001 2:39 PM
Subject: RE: How does Tomcat handle discarded-request
Hi, Craig,
Here is my skeleton jsp,
jsp:useBean id=workBean class=... ...
/jsp:useBean
%
Object param1=getParameter(Param1) ;
...
Object paramn = getParameter(Paramn) ;
// let us say that doWork takes a few minutes to finish
// and I just can not wait at the browser side and I issues
another request to TOMCAT
Object result = workBean.doWork(param1, ..., paramn) ;
// Is IOException thrown out here?
out.println(result) ;
%
As per your explaination, is IOException thrown out on out.println()???,
since it is JSP, so my workBean has no way to talk to something at the
browser side to get data.
thanks,
David
--
From: Craig R. McClanahan[SMTP:[EMAIL PROTECTED]]
Reply To: Tomcat Developers List
Sent: Thursday, November 01, 2001 5:08 PM
To: Tomcat Developers List
Cc: Hu, Xuebing
Subject: RE: How does Tomcat handle discarded-request
On Thu, 1 Nov 2001, Hu, Xuebing wrote:
Date: Thu, 1 Nov 2001 17:03:29 -0500
From: Hu, Xuebing [EMAIL PROTECTED]
Reply-To: Tomcat Developers List [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED]
Subject: RE: How does Tomcat handle discarded-request
Thanks, Bill for the response. Any detail? I am currently using TOMCAT
3.2.3.
In general, you cannot count on the server even knowing that the request
was cancelled. The following scenarios are all possible:
* The entire request was read before the cancel happened, so no
notification is possible until the response is written back out
and receives an IOException. (This is by far the most common case.)
* Tomcat was able to read the headers, but does not need to read
the data. In this case, it is the application (not Tomcat) that
would receive an IOException when trying to process the input
stream. Therefore, it is up to your application to respond
appropriately.
* Tomcat was unable to read the headers (because the cancel happened
very quickly). It will typically log an exception and throw the
request away.
David
Craig
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
**
This message is intended only for the use of the person(s) listed above
as the intended recipient(s), and may contain information that is
PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient,
you may not read, copy, or distribute this message or any attachment.
If you received this communication in error, please notify us immediately
by e-mail and then delete all copies of this message and any attachments.
In addition you should be aware that ordinary (unencrypted) e-mail sent
through the Internet is not secure. Do not send confidential or sensitive
information, such as social security numbers, account numbers, personal
identification numbers and passwords, to us via ordinary (unencrypted)
e-mail.
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 4529] - webapp connector does not set isSecure() on request
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4529. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4529 webapp connector does not set isSecure() on request [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2001-10-31 03:39 --- I have fixed the problem by check the scheme to https. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
How does Tomcat handle discarded-request
Hi, I issues to Tomcat one request which takes kind of long time to response, when the backend servlet or bean is working on the result, I just can not wait and clicked somewhere on my browser page to issue another request, in this case, I am wondering what Tomcat to do with the previous working servlet, is it still runing until finish or Tomcat just kill the thread and force it stop. The question is closely related to connection pool, without the work finish, the connection will not be returned to pool in working bean or servlet, I suppose that Tomcat keeps the servlet thread running until it finishes, otherwise, there is no way for the servlet to finish his work and return connection. Any response is appreciated. Thanks, David -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Tomcat 3.2.3 Documentation update request.
Hello. Could someone please update the Tomcat 3.2.3 documentation (http://jakarta.apache.org/tomcat/tomcat-3.2-doc/uguide/tomcat_ug.html)? In the section on server.xml, the description for Connector in the table in that section does not describe the inet option that can be used to make Tomcat 3.2.3 listen on a specific host interface. For example, the text can read as follows: 4. inet - The host interface (IP address or host name) on which to listen for connections. The lack of this documentation has caused me a lot of grief for the last couple of days (until I was helped graciously in the user's mailing list). Thanks much, Prasanna.
DO NOT REPLY [Bug 4263] - Apache Tomcat service hangs after serving first request.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4263. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4263 Apache Tomcat service hangs after serving first request. --- Additional Comments From [EMAIL PROTECTED] 2001-10-18 09:13 --- Are you sure the first page you see wasn't served by your browser's cache ? I use the Tomcat as a sys service (installed through the installer) with Win2k (SP2) / JDK 1.3.1, and it works ok. Please check the stdout.log. If it's empty then it's bad. If Tomcat did indeed start, some of the other log files should contain some kind of error message.
DO NOT REPLY [Bug 4263] - Apache Tomcat service hangs after serving first request.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4263. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4263 Apache Tomcat service hangs after serving first request. --- Additional Comments From [EMAIL PROTECTED] 2001-10-18 21:06 --- Dear Remy, I follow your step. Clear cache on my browser. I think you may right, the first page may come from browser cache. So, this time... I cannot call even first page... http://localhost:8080 I change port to ensure that other application may not occupy port 8080. But it still does not work. To make sure that it is not my machine problem. I install Tomcat on Windows XP build 2600 Professional. This time it shows the message Microsoft Visual C++ Runtime Library Runtime Error! Program: C:\Program Files\Apache Tomcat 4.0\bin\tomcat.exe This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. So, I think it has the same problem with Windows 2000 Advanced Server. The stderr.log is completely empty, the other log seems to have normal message. Is there any steps should I try?
DO NOT REPLY [Bug 4263] - Apache Tomcat service hangs after serving first request.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4263. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4263 Apache Tomcat service hangs after serving first request. [EMAIL PROTECTED] changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2001-10-18 22:05 --- I don't know if the XP error means anything interesting. Probably not. The problem seems to be that for some reason the JVM doesn't start. I'm afraid the only way to guarantee that the service setup would succeed all the time would to do a lot of checks on the detected VM (and allow the user to manually select one), which isn't easy to do with the current installer. It's still easier than installing it manually, but your mileage may vary The installer depends on the registry keys set by the installer of the Sun JDK. So if you move the JDK around, it won't work. I wish the JDK/JRE would behave a bit more like a Windows program ... (or that NSIS would allow accessing something other than the registry easily). You can try to check in the registry that the service registration info is correct (and modify it if it isn't). HKLM/SYSTEM/CurrentControlSet/Services/Apache Tomcat/Parameters The value of 'JVM Library' must be something meaningful on your system. Like all the other installer bugs, this looks like a non-fixable JDK/JRE configuration problem. So WONTFIX in this current installer.
[Fwd: Tomcat's non-polymorphic request handler.]
I sent this to the tomcat user group, but got no response.
Comments?
I'm having some difficulty with the polymorphic behavior of Tomcat's
request handler.
Consider the following:
package RMS;
import java.lang.Integer;
public class TestPolyMorph {
int i;
String s;
public void setNumberVar(String i) {
this.i = Integer.parseInt(i);
}
public void setNumberVar(int i) {
this.i = i;
}
public int getNumber() {
return(i);
}
public void setStringVar(String s) {
this.s = s;
}
public String getStringVar(String s) {
return(s);
}
public TestPolyMorph() {
}
}
... and the .JSP file:
!DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.01 Transitional//EN
http://www.w3.org/TR/html4/loose.dtd;
html
head
!-- meta http-equiv=Pragma content=no-cache
meta http-equiv=Expires content=Mon, 01 Jan 1990 00:00:01 GMT
--
meta http-equiv=Content-Type
content=text/html;CHARSET=iso-8859-1
meta http-equiv=Content-Style-Type content=text/css
/head
%@ page language=java import=RMS.* %
jsp:useBeanid=ui class=RMS.TestPolyMorph scope=session/
jsp:setProperty name=ui property=*/
body
Testing... Testing... Testing.
/body
/html
Now... the passing a non-integer value for the property: numberVar will
yield a stack trace:
http://SERVER:PORT/CONTEXT/jsp/TestPolyMorph.jsp?numberVar=foobar
org.apache.jasper.JasperException: foobar
at
org.apache.jasper.runtime.JspRuntimeLibrary.introspecthelper(JspRuntimeLibrary.java:204)
at
org.apache.jasper.runtime.JspRuntimeLibrary.introspect(JspRuntimeLibrary.java:152)
at
jsp._0002fjsp_0002fTestPolyMorph_0002ejspTestPolyMorph_jsp_2._jspService(_0002fjsp_0002fTestPolyMorph_0002ejspTestPolyMorph_jsp_2.java:91)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:119)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at
org.apache.jasper.servlet.JspServlet$JspServletWrapper.service(JspServlet.java:177)
at
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:318)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:391)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at
org.apache.tomcat.core.ServletWrapper.doService(ServletWrapper.java:404)
at org.apache.tomcat.core.Handler.service(Handler.java:286)
at
org.apache.tomcat.core.ServletWrapper.service(ServletWrapper.java:372)
at
org.apache.tomcat.core.ContextManager.internalService(ContextManager.java:797)
at
org.apache.tomcat.core.ContextManager.service(ContextManager.java:743)
at
org.apache.tomcat.service.http.HttpConnectionHandler.processConnection(HttpConnectionHandler.java:210)
at
org.apache.tomcat.service.TcpWorkerThread.runIt(PoolTcpEndpoint.java:416)
at
org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java:498)
at java.lang.Thread.run(Thread.java:484)
Root cause:
org.apache.jasper.JasperException: 3.2
at
org.apache.jasper.runtime.JspRuntimeLibrary.convert(JspRuntimeLibrary.java:138)
at
org.apache.jasper.runtime.JspRuntimeLibrary.introspecthelper(JspRuntimeLibrary.java:198)
at
org.apache.jasper.runtime.JspRuntimeLibrary.introspect(JspRuntimeLibrary.java:152)
at
jsp._0002fjsp_0002fTestPolyMorph_0002ejspTestPolyMorph_jsp_2._jspService(_0002fjsp_0002fTestPolyMorph_0002ejspTestPolyMorph_jsp_2.java:91)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:119)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at
org.apache.jasper.servlet.JspServlet$JspServletWrapper.service(JspServlet.java:177)
at
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:318)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:391)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at
org.apache.tomcat.core.ServletWrapper.doService(ServletWrapper.java:404)
at org.apache.tomcat.core.Handler.service(Handler.java:286)
at
org.apache.tomcat.core.ServletWrapper.service(ServletWrapper.java:372)
at
org.apache.tomcat.core.ContextManager.internalService(ContextManager.java:797)
at
org.apache.tomcat.core.ContextManager.service(ContextManager.java:743)
at
org.apache.tomcat.service.http.HttpConnectionHandler.processConnection(HttpConnectionHandler.java:210)
at
org.apache.tomcat.service.TcpWorkerThread.runIt(PoolTcpEndpoint.java:416)
at
org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java:498)
at java.lang.Thread.run(Thread.java:484)
Even though there is indeed a method signature:
setNumberVar(String i);
Tomcat prefers to use (through introspection):
setNumberVar(int i);
The beans I use to handle property settings must continue to use
polymorphism.
Any ideas?
Thanks,
matt
---BeginMessage---
I'm having some difficulty with the polymorphic behavior of Tomcat's
request handler.
Consider the following:
package RMS;
import java.lang.Integer;
public class TestPolyMorph {
int i;
String s;
public void setNumberVar(String i) {
this.i
DO NOT REPLY [Bug 3727] - Switched included request parameters
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3727. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3727 Switched included request parameters [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|ASSIGNED --- Additional Comments From [EMAIL PROTECTED] 2001-09-26 17:28 --- My tests confirm what Bill Barker has said. If you have a mapping for /*, requests that don't otherwise match some other mapping will have the servlet_path empty and path_info non-empty. See section 4.4 in the Servlet 2.3 spec (this behavior didn't change from 2.2 and the Servlet 2.3 spec has some typo's fixed that are present in the Servlet 2.2 spec). If you take either the /lawn/* or /garden/* examples and replace the /lawn or /garden with , you will see that the servlet_path becomes blank. Thus your statement in the last reopen is incorrect. The servlet_path and path_info are not switched. More to come...
DO NOT REPLY [Bug 3727] - Switched included request parameters
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3727. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3727 Switched included request parameters [EMAIL PROTECTED] changed: What|Removed |Added AssignedTo|tomcat- |[EMAIL PROTECTED] |[EMAIL PROTECTED] | Status|ASSIGNED|NEW --- Additional Comments From [EMAIL PROTECTED] 2001-09-26 17:29 --- I tried adding the /foobar/* dummy mapping and behavior did not change as it shouldn't. If you are still able to get altered behavior when adding a dummy mapping, please specify the dummy mapping and the URL you are using to invoke it. I'm assuming the /* mapping is still present along with the dummy mapping. As Costin is indicating by marking 3760 as a duplicate, perhaps it was the restarting of Tomcat, not the dummy mapping itself, that is responsible for the changing behavior in your test case. I don't see the changing behavior, but I may not be duplicating your test case exactly. As a result, we would need to know your test case in exact detail. Thanks.
DO NOT REPLY [Bug 3727] - Switched included request parameters
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3727. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3727 Switched included request parameters [EMAIL PROTECTED] changed: What|Removed |Added CC||sebastian.kanthak@muehlheim. ||de --- Additional Comments From [EMAIL PROTECTED] 2001-09-23 11:11 --- *** Bug 3760 has been marked as a duplicate of this bug. ***
DO NOT REPLY [Bug 3727] - Switched included request parameters
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3727. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3727 Switched included request parameters --- Additional Comments From [EMAIL PROTECTED] 2001-09-21 09:23 --- But then, why do the values change, when we ADD a dummy url mapping (e.g. '/foobar/*') in the test-application's web.xml file? Adding, another url mapping shouldn't change the behavior of the servlet engine in this concrete case! Did you run the sample code from above?
DO NOT REPLY [Bug 3727] - Switched included request parameters
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3727. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3727 Switched included request parameters --- Additional Comments From [EMAIL PROTECTED] 2001-09-21 11:41 --- All of your tests work for me. That is that the servlet_path is empty and everything is in the path_info just like it should be. The only way that I didn't get it was when I put a typo in the web.xml file by mistake, and Tomcat added the context anyway but without mappings. While that might be considered a bug, the servlet_path and path_info were correct for the context configuration.
DO NOT REPLY [Bug 3727] - Switched included request parameters
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3727. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3727 Switched included request parameters --- Additional Comments From [EMAIL PROTECTED] 2001-09-21 14:13 --- Your remarks are corrct for the path_info and servet_path fields read from the ServletContext object of a running servlet. In the case where the url mapping '/*' matches, the servlet-path will be empty and the path_info will contain the part after the context path up to the request parameters. However, the problem I have reported concerns the path_info and servet_path fields stored as request attributes after a servlet has been invoked by calling the include method of a RequestDispatcher. The servlet is addressed by its class name, thus the url mappings specified in the web.xml file are not involved in this case. According to the specification of servlet api 2.2 / Section 8.3.1, the request attribut fields of an included servlet contain the path by which it was invoked and not the original request paths! Thus, for the example given earlier the path_info should be 'null' and the servlet_path should hold the value '/servlet/SnoopIncluderServlet'. Could you please comment the second problem I have remarked: If you look at the output of the given example code, why do the outputed values change, when a dummy entry is ADDED to the current web.xml config?
DO NOT REPLY [Bug 3727] - Switched included request parameters
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3727. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3727 Switched included request parameters [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2001-09-21 16:15 --- I still thing the bug is invalid - /servlet/* is not part of the spec, is just a tomcat-specific thing ( well, all containers support that - but it's still outside of the spec). The attributes are set during mapping - and it works fine for all 'normal' mapps. I can probably fix this ( by changing Invoker to adjust the paths ), but it's low priority, and you shouldn't use /servlet mappings anyway ( they're only for backward compatibility with a feature that was never specified AFAIK )
DO NOT REPLY [Bug 3727] - Switched included request parameters
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3727. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3727 Switched included request parameters [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | --- Additional Comments From [EMAIL PROTECTED] 2001-09-21 17:17 --- Sorry to be so insistent, but for the area of servlet-based framework development neither the given mapping nor the use of the include mechanism are 'abnormal'. Any framework containing a central contoller servlet, which handles all requests sent to the corresponding application context, has its url mapping set to '/' and '/*'. To push the problem back into the scope of the servlet API specification I have modified the test code to call the servlet using its name. Thus, the call looks like: RequestDispatcher disp = null; disp = getServletContext().getRequestDispatcher(/SnoopIncluder); And, still, we get different results depending on the set of url mappings present in the web.xml file. Having only '/' and '/*' defined the output contains: javax.servlet.include.path_info = /SnoopIncluder javax.servlet.include.servlet_path = javax.servlet.include.context_path = /appsvtest javax.servlet.include.request_uri = /appsvtest/SnoopIncluder Adding a dummy url mapping, the values are set as it might be expected: javax.servlet.include.servlet_path = /SnoopIncluder javax.servlet.include.context_path = /appsvtest javax.servlet.include.request_uri = /appsvtest/SnoopIncluder The example shows, that the problem has nothing to to with the Invoker. For me this rather looks like a pattern matching problem for a given set of url mappings and a request URI.
DO NOT REPLY [Bug 3727] - Switched included request parameters
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3727. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3727 Switched included request parameters --- Additional Comments From [EMAIL PROTECTED] 2001-09-20 17:53 --- Since you have a servlet-mapping for /*, Tomcat's values are exactly what you would expect them to be.
DO NOT REPLY [Bug 3727] New: - Switched included request parameters
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3727. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3727 Switched included request parameters Summary: Switched included request parameters Product: Tomcat 3 Version: 3.3 Beta 2 Platform: Sun OS/Version: Solaris Status: NEW Severity: Normal Priority: Other Component: Servlet AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] When a servlet is called using a RequestDispatcher - the dispatcher is received by calling getRequestDispatcher() of ServletRequest and servlet to call is addressed by its class name - it mixes up its path information stored in the requet's attribute fields. The servlet is basically called by disp = req.getRequestDispatcher(/servlet/appsvtest.server.AppSvTestServlet); disp.forward(req, resp); The attribute fields of the called servlet contain the following values after the forward call. --- Attribute: javax.servlet.include.path_info Value: /servlet/ch.nevis.appsvtest.server.AppSvTestServlet --- Attribute: javax.servlet.include.servlet_path Value: [empty string] --- By my understanding the servlet path should instead point to the servlet class and the path info should contain an empty string, because there is no additional information after the name of the servlet class.
DO NOT REPLY [Bug 3665] - Request Dispatching - Parameters are not properly set
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3665. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3665 Request Dispatching - Parameters are not properly set [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|CLOSED --- Additional Comments From [EMAIL PROTECTED] 2001-09-18 14:42 --- Thank you! Problems have been isolated and solved outside the tomcat code.
DO NOT REPLY [Bug 3665] New: - Request Dispatching - Parameters are not properly set
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3665. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3665 Summary: Request Dispatching - Parameters are not properly set Product: Tomcat 4 Version: 4.0 Release Candidate 2 Platform: Sun OS/Version: Solaris Status: NEW Severity: Normal Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] According to Servlet API Spec 2.3/Section 8.3.1, the following request attributes are set whenever a request is dispatched to another servlet/jsp using the 'include' method of the RequestDispatcher object: javax.servlet.include.request_uri javax.servlet.include.context_path javax.servlet.include.servlet_path javax.servlet.include.path_info javax.servlet.include.query_string This fields should enable a servlet being used from within an include to access the parameters by which it was invoked. According to our test environment checking several dispatching methods Tomcat 4.0rc2 seems to handle this fields wrongly. Using a RequestDispatcher (not a NamedDispatcher) and the 'include' method, Tomcat 4.0rc2 does not set these fields at all. Checking the request attributes, shows that these fields are not available for the called servlet.
DO NOT REPLY [Bug 3665] - Request Dispatching - Parameters are not properly set
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3665. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3665 --- Additional Comments From [EMAIL PROTECTED] 2001-09-17 16:22 --- Can you submit a test case demonstrating this (as an attachment to this bug report)? I've got bunches of test cases (and running applications) that think it is working correctly per the specification.
DO NOT REPLY [Bug 3665] - Request Dispatching - Parameters are not properly set
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3665. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3665 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2001-09-17 17:11 --- The problem is that setting a request attribute to a null value is not legal (same for session attributes and servlet context attributes). Therefore, not setting the javax.servlet.include.path_info attribute is the appropriate indication to the included servlet that it was invoked with no extra path info. Same thing happens on the query string attribute if there is no query string on the path passed to getRequestDispatcher(). Note that Tomcat's current behavior is what the J2EE compatibility tests are looking for, so you will find it to be portable across all containers.
DO NOT REPLY [Bug 3641] - Bad value in query string parameter while forwarding request
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3641. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3641 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2001-09-16 17:48 --- Fixed, please check the next nightly.
Re: Tomcat 4 build from CVS this morning, bugs in request cookiehandling?
On Wed, 5 Sep 2001, Glenn Nielsen wrote: Date: Wed, 05 Sep 2001 11:59:18 -0500 From: Glenn Nielsen [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Tomcat 4 build from CVS this morning, bugs in request cookie handling? I built Tomcat 4 from CVS this morning and it looks like there may be a problem in how it is handling cookies, especially the JSESSIONID cookie. The HttpServletRequest seems to no longer recognize that the session came from a cookie. A regression caused by the URL encoding change yesterday. I just checked in a patch that will fix this in tonight's nightly build (or current CVS sources). Glenn Craig
Re: Tomcat 4 build from CVS this morning, bugs in request cookiehandling?
I rebuilt Tomcat 4 from CVS after your commits today and sessions are working correctly. Thanks Craig! Glenn Craig R. McClanahan wrote: On Wed, 5 Sep 2001, Glenn Nielsen wrote: Date: Wed, 05 Sep 2001 11:59:18 -0500 From: Glenn Nielsen [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Tomcat 4 build from CVS this morning, bugs in request cookie handling? I built Tomcat 4 from CVS this morning and it looks like there may be a problem in how it is handling cookies, especially the JSESSIONID cookie. The HttpServletRequest seems to no longer recognize that the session came from a cookie. A regression caused by the URL encoding change yesterday. I just checked in a patch that will fix this in tonight's nightly build (or current CVS sources). Glenn Craig -- -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | --
Re: Request: binary mod_webapp.so for Solaris built with -DEAPI
Eryq [EMAIL PROTECTED] wrote: I was using the mod_webapp.so connector for Solaris which I downloaded from apache.org All was going well until I rebuilt my Apache (1.3.20) with SSL support. Now I get: [warn] Loaded DSO libexec/mod_webapp.so uses plain Apache 1.3 API, this module might crash under EAPI! (please recompile it with -DEAPI) Well, I didn't compile it, so I can't recompile it. I expect that a number of other users will be in the same boat. Is there any compelling reason not to build with -DEAPI? What will really happen if this mod_webapp.so is used? It will happen that the NON-EAPI server will complain because of unresolved dependancies... :( Pier
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/request AccessInterceptor.java
nacho 01/08/24 16:58:51
Modified:src/share/org/apache/tomcat/request Tag: tomcat_32
AccessInterceptor.java
Log:
Fix for Bugzilla#2118
Incosistent behaviuor updating OriginalLocation in FormAuthHandler Class
Reported by Juan Jose Muñoz ( jmartine at alhsys.es ), mark.shotton at
micromass.co.uk
Revision ChangesPath
No revision
No revision
1.12.2.10 +8 -7
jakarta-tomcat/src/share/org/apache/tomcat/request/Attic/AccessInterceptor.java
Index: AccessInterceptor.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/request/Attic/AccessInterceptor.java,v
retrieving revision 1.12.2.9
retrieving revision 1.12.2.10
diff -u -r1.12.2.9 -r1.12.2.10
--- AccessInterceptor.java2001/07/17 04:25:55 1.12.2.9
+++ AccessInterceptor.java2001/08/24 23:58:51 1.12.2.10
@@ -465,6 +465,14 @@
session=req.getSession( true );
String username=(String)session.getAttribute( j_username );
+String originalLocation = req.getRequestURI();
+
+ if (req.getQueryString() != null)
+ originalLocation += ? + req.getQueryString();
+
+ session.setAttribute( tomcat.auth.originalLocation,
+ originalLocation);
+
if( debug0) log( Username = + username);
if( username != null ) {
// 401 with existing j_username - that means wrong credentials.
@@ -477,13 +485,6 @@
return;
}
-String originalLocation = req.getRequestURI();
-
- if (req.getQueryString() != null)
- originalLocation += ? + req.getQueryString();
-
- session.setAttribute( tomcat.auth.originalLocation,
- originalLocation);
if( debug 0 )
log(Redirect1: + page + originalUri= + req.getRequestURI());
Request: binary mod_webapp.so for Solaris built with -DEAPI
I was using the mod_webapp.so connector for Solaris which I downloaded from apache.org All was going well until I rebuilt my Apache (1.3.20) with SSL support. Now I get: [warn] Loaded DSO libexec/mod_webapp.so uses plain Apache 1.3 API, this module might crash under EAPI! (please recompile it with -DEAPI) Well, I didn't compile it, so I can't recompile it. I expect that a number of other users will be in the same boat. Is there any compelling reason not to build with -DEAPI? What will really happen if this mod_webapp.so is used? -- Eryq
tomcat 4 request/response instrumentation
something that i've started thinking about recently is how to provide hooks in tomcat 4 so that some statistics regarding request processing time could be collected. off of the top of my head, a couple of interesting stats might be average request processing time for all contexts (or webapps) and average request processing time for each context. so, some questions: *) has anybody else considered this? *) does anybody else care about this? also, would it be possible to use a Valve to accomplish this? how are valves processed? are they stacked such that the first valve entered is the last one exited? or are they chained such that one valve is processed after the next, and once the last valve is processed, the response is sent? what i'm getting at is, could you put a valve in place such that it could always log (or send events) at the beginning of a request and right before the response is sent? tia, -kevin.
Re: tomcat 4 request/response instrumentation
Kevin Seguin at [EMAIL PROTECTED] wrote: *) has anybody else considered this? Don't think so... *) does anybody else care about this? I would (but can't commit to it :) also, would it be possible to use a Valve to accomplish this? Yes... how are valves processed? are they stacked such that the first valve entered is the last one exited? Correct. or are they chained such that one valve is processed after the next, and once the last valve is processed, the response is sent? Nope... See how the invoke() method works... what i'm getting at is, could you put a valve in place such that it could always log (or send events) at the beginning of a request and right before the response is sent? In TC4.0 valve are more-or-less like loggers. So if you put down a valve at the bottom of your Engine (the first root component in the component stack of Catralina), you'll end up intercepting all requests coming from the connectors... :) Pier
Re: tomcat 4 request/response instrumentation
On Fri, 17 Aug 2001, Kevin Seguin wrote:
something that i've started thinking about recently is how to provide hooks
in tomcat 4 so that some statistics regarding request processing time could
be collected.
off of the top of my head, a couple of interesting stats might be average
request processing time for all contexts (or webapps) and average request
processing time for each context.
so, some questions:
*) has anybody else considered this?
*) does anybody else care about this?
also, would it be possible to use a Valve to accomplish this?
Yep ... a Valve would do this trick just fine, with the caveat that timing
would start *after* your Connector has accepted the request, and *before*
your Connector returns the response to the user. In essence, you are
measuring the internal processing time, not the communications time.
Here's the basic outline of a performance monitoring valve:
public class MyFirstValve extends ValveBase {
public void invoke(Request request, Response response,
ValveContext context)
throws IOException, ServletException {
long startTime = System.currentTimeMillis();
context.invoke(request, response);
long stopTime = System.currentTimeMillis();
System.out.println(Took + (stopTime - startTime) + ms.);
}
}
Note that you are free to maintain state information (the start time, in
this case) as local variables on the stack. Even if there are multiple
simultaneous requests flowing through the Valve, they each happen on a
separate request thread -- with a separate stack. So, the same design
principles apply here as apply with servlets in general, do not use
instance variables for per-request state information.
how are
valves processed? are they stacked such that the first valve entered is the
last one exited? or are they chained such that one valve is processed after
the next, and once the last valve is processed, the response is sent? what
i'm getting at is, could you put a valve in place such that it could always
log (or send events) at the beginning of a request and right before the
response is sent?
I think the most common term for how valves are organized is pipelined
-- in fact, Pipeline is the internal Tomcat name for the implementation.
Another way to look at them is as an implementation of the Chain of
Responsibility design pattern in the GoF book.
Essentially the Valves you configured or organized into a structure that
looks like this in ASCII art:
Request -- -- --
Valve 1 Valve 2 Servlet
Response -- -- --
so that Valve 1 sees the request first and passes it on (that's not
actually required, but is what you'd do for a performance monitoring
Valve. Then Valve 2 does the same. Eventually, you fall of the list of
configured valves and the container calls your servlet for you. As the
call stack unwindes, each valve regains control so it can postprocess as
necessary, and then returns. Ultimately, when Valve 1 returns (to the
Connector), the response is actually sent back to the client.
Valves are added to a pipeline in the order that you declare them with
Valve elements in server.xml. In addition, Tomcat itself adds standard
Valves as needed for some of its processing. For example, if your web app
uses container managed security, Tomcat automatically adds a valve to do
the extra checks required -- if you don't, this valve is omitted and your
performance doesn't pay any extra costs.
In Tomcat, you also have the choice of where to place the Valve in
server.xml, which controls which subset of requests your Valve will see:
* Nested inside an Engine - will see all requests
* Nested inside a Host - will see all requests for that virtual host
* Nested inside a Context - will see all requests for that web app
so you can be more selective about which requests you want to time.
As an extra added bonus, once you understand Valves, you've got about a
95% understanding of the new Filter API in Servlet 2.3 (which will be
portable, while Valve is specific to Tomcat 4). If you care about the
performance only within a single web app, you might want to go this way
instead of using a Valve, but either would work.
tia,
-kevin.
Craig
