DO NOT REPLY [Bug 10385] - SSI-Servlet produces invalid character encoding information
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=10385. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=10385 [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2005-09-19 22:44 --- *** Bug 36651 has been marked as a duplicate of this bug. *** -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35993] New: - 1.4-compat file contains wrong path information
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35993. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35993 Summary: 1.4-compat file contains wrong path information Product: Tomcat 5 Version: 5.5.9 Platform: PC OS/Version: Windows XP Status: NEW Severity: minor Priority: P2 Component: Unknown AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] I´d installed Tomcat 5.5.9 on my XP machine. For running with JRE 1.4 I had to install the 1.4-compat file: http://jakarta.apache.org/tomcat/tomcat-5.5-doc/setup.html If using a J2SE 1.4 JRE, the compatibility package must be downloaded and expanded inside the folder where Tomcat was installed. -- there is no link to get that package, no link on the download page either (I found it via browsing the archive) expanded inside the folder where Tomcat was installed The archive contains as root director jakarta-tomcat-5.5.9 which is not the directory I had chosen in the installer (c:\tomcat\5.5.9). -- change the directory structure inside the zip from: jakarta-tomcat-5.5.9\LICENSE... , jakarta-tomcat-5.5.9\bin\jmx.jar to : \LICENSE... , bin\jmx.jar -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35993] - 1.4-compat file contains wrong path information
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35993. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35993 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2005-08-03 11:45 --- Nothing to fix here ... -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35993] - 1.4-compat file contains wrong path information
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35993. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35993 [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|WONTFIX | --- Additional Comments From [EMAIL PROTECTED] 2005-08-03 12:05 --- 1. the website 2. the build file -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35993] - 1.4-compat file contains wrong path information
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35993. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35993 [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||WONTFIX -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 11563] - Authorization information not available at TOMCAT side (JSP: getRemoteUser())
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=11563. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=11563 --- Additional Comments From [EMAIL PROTECTED] 2005-07-25 16:21 --- You are correct, the document you mentioned below does talk about the tomcatAuthentication. Kevin -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 11563] - Authorization information not available at TOMCAT side (JSP: getRemoteUser())
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=11563. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=11563 [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||WORKSFORME --- Additional Comments From [EMAIL PROTECTED] 2005-07-23 00:14 --- I think the doc on tomcatAuthentication at http://jakarta.apache.org/tomcat/tomcat-5.5-doc/config/ajp.html is decent, but if you have some specific alternative/additional text in mind, please post it. Glad you found the solution... -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: PayPal Notification: Upgrade your information
Sir/Madam, We could not understand what do you want to say. Please write in details and in english language pls. Thanks and rgds., GUL. [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: fitchburg arum inhuman cancellate lighthearted hausdorff lexicography sirius carl groan conrad imperial bloop earthy decontrolling epitaxial charta escheat intoxicant ahead tenney - How much free photo storage do you get? Store your friends n family photos for FREE with Yahoo! Photos. http://in.photos.yahoo.com
PayPal Notification: Upgrade your information
fitchburg arum inhuman cancellate lighthearted hausdorff lexicography sirius carl groan conrad imperial bloop earthy decontrolling epitaxial charta escheat intoxicant ahead tenney
DO NOT REPLY [Bug 35632] New: - 5.5 no Content Type header information for TXT files
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35632. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35632 Summary: 5.5 no Content Type header information for TXT files Product: Tomcat 5 Version: 5.5.9 Platform: PC OS/Version: Windows Server 2003 Status: NEW Severity: normal Priority: P2 Component: Catalina AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] Tomcat 5.5 does not create the Content Type header information when serving TXT files back to the browser. proof of bug, is that i captured the header information from Tomcat 4.1 and Tomcat 5.5. i also made sure to clear the cache each time prior to request the TXT file. header chunk from Tomcat 4.1 when serving a TXT file: HTTP/1.1 200 Server: Microsoft-IIS/5.0 Date: Wed, 06 Jul 2005 16:22:39 GMT ETag: W/1706-1120587147968 Last-Modified: Tue, 05 Jul 2005 18:12:27 GMT Content-Type: text/plain Content-Length: 1706 header chunk from Tomcat 5.5 when serving a TXT file: HTTP/1.1 200 OK Server: Apache-Coyote/1.1 ETag: W/1706-1120666790014 Last-Modified: Wed, 06 Jul 2005 16:19:50 GMT Content-Length: 1706 Date: Wed, 06 Jul 2005 16:20:26 GMT i also verified Tomcat 5.5's conf/web.xml file and it does have the mime mapping entry for TXT files: mime-mapping extensiontxt/extension mime-typetext/plain/mime-type /mime-mapping the side effect resulting from this is that Internet Explorer 6.0 displays the TXT file using a non fixed-width font and any 'formatting' is lost as a result. that is, all the consecutive spaces are stripped. it seems to rely on Content Type. however, in FireFox 1.04, the lack of this Content Type header information does *not* seem to matter as it displayed the TXT file correctly (ie. with a fixed width font) and preserved the 'formatting'. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35632] - 5.5 no Content Type header information for TXT files
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35632. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35632 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2005-07-06 21:55 --- Yeah, right. Please try not wasting people's time. Any attempt to reopen this report will lead me to mark it as INVALID again without further comments. GET /RELEASE-NOTES.txt HTTP/1.1 Host: localhost:8080 HTTP/1.1 200 OK Server: Apache-Coyote/1.1 ETag: W/6384-1120204442875 Last-Modified: Fri, 01 Jul 2005 07:54:02 GMT Content-Type: text/plain Content-Length: 6384 Date: Wed, 06 Jul 2005 19:53:15 GMT Apache Tomcat Version 5.5.10-dev Release Notes $Id: RELEASE-NOTES,v 1.25 2005/01/19 20:30:26 remm Exp $ -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 11563] - Authorization information not available at TOMCAT side (JSP: getRemoteUser())
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=11563. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=11563 [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] Status|RESOLVED|REOPENED Component|Webapps:Examples|Webapps:Examples Product|Tomcat 4|Tomcat 5 Resolution|WORKSFORME | Version|4.0.4 Final |Unknown --- Additional Comments From [EMAIL PROTECTED] 2005-05-25 16:43 --- This is still an issue. I have the problem with Tomcat 5.5.7 using the ISAPI redirector (not using apache HTTP). Kevin -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 11563] - Authorization information not available at TOMCAT side (JSP: getRemoteUser())
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=11563. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=11563 --- Additional Comments From [EMAIL PROTECTED] 2005-05-25 16:44 --- This is still an issue. I have the problem with Tomcat 5.5.7 using the ISAPI redirector (not using apache HTTP). Kevin -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 11563] - Authorization information not available at TOMCAT side (JSP: getRemoteUser())
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=11563. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=11563 [EMAIL PROTECTED] changed: What|Removed |Added Severity|critical|normal Version|Unknown |5.5.7 --- Additional Comments From [EMAIL PROTECTED] 2005-05-25 17:49 --- It would appear that this can be resolved by turning off Tomcat Auth at the connector level. I was able to modify server.xml and add the 'tomcatAuthentication=false' setting. Perhaps a FAQ could help with this. !-- Define an AJP 1.3 Connector on port 8009 -- Connector port=8009 tomcatAuthentication=false enableLookups=false redirectPort=8443 protocol=AJP/1.3 / -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 34584] - Cannot run multiple instances of JK ISAPI Redirector Filter/Extension within a single instance of Microsoft Internet Information Server
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=34584. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=34584 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2005-04-23 10:54 --- Your solution will simply not work, because it will break any other filter in the chain, like custom authentication filters, etc... JK ISAPI filter has many static variables that limit it's option to be included more then once. What we would need is the option to have multiple configurations for each virtual web server, not having multiple filter instances. And that is not an easy fix :). Regards, Mladen. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 34584] New: - Cannot run multiple instances of JK ISAPI Redirector Filter/Extension within a single instance of Microsoft Internet Information Server
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=34584. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=34584 Summary: Cannot run multiple instances of JK ISAPI Redirector Filter/Extension within a single instance of Microsoft Internet Information Server Product: Tomcat 5 Version: 5.0.7 Platform: Other OS/Version: Windows 2000 Status: NEW Severity: major Priority: P1 Component: Native:JK AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] Many commercial/non-commercial web products lay down Tomcat as an out-of-the- box servlet container when they are installed. For Windows customers, such products also often configure an instance of the JK ISAPI filter/extension to IIS (isapi_redirect.dll). Unfortunately, the /jakarta-tomcat- connectors/jk/native/iis/isapi_redirect_plugin.c module is written in such a way that only one instance of the JK ISAPI filter/extension will function properly per instance of IIS. When you have two or more filters/extensions configured within IIS, only the final filter in the filter chain functions properly. The other filters kick out Tomcat 404 errors for all request URIs that match the URL patterns in the corresponding uriworkmap.properties file. As a developer for Compuware Corporation, I recently took it upon myself to resolve this issue. Because I am working behind an authenticating firewall, I cannot connect my CVS client to your CVS repositories in order to create a patch file, as recommended by your contribution guidelines. I have nevertheless resolved the issue by adding a single line to the /jakarta- tomcat-connectors/jk/native/iis/isapi_redirect_plugin.c file as shown below: diff -r1.2 -r1.3 23c23 * Version: $Revision: 1.2 $ * --- * Version: $Revision: 1.3 $ * 903a904 return SF_STATUS_REQ_HANDLED_NOTIFICATION; My analysis of the problem revealed that when a given instance of the JK ISAPI filter finds that a request URI matches one of the URL patterns in its map, it redirects to the proper JK ISAPI extension, but it also passes the request along to the next filter in the chain. This is what is causing the problem. When a match is found by one filter, the redirection should go directly to the extension without going through the other filters further down the chain. This can be achieved by returning SF_STATUS_REQ_HANDLED_NOTIFICATION from the HttpFilterProc function instead of SF_STATUS_REQ_NEXT_NOTIFICATION whenever a URI match is found. I have tested this fix by installing three separate instances of Tomcat, each with its own corresponding JK ISAPI filter/extension. I did this on Windows 2000 Server, Windows 2003 Server, and Windows XP professional. In every case, all three instances of the JK ISAPI filter/extension worked properly. The first filter to find URI pattern match handles the request by routing to the corresponding extension. This fix will yield significant savings for my company in terms of time and money spent on support calls, and I believe that other Tomcat redistributors will benefit from it as well. I therefore hope that you will incorporate this change, or one similar to it, into your codebase for the Tomcat JK Connector. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 34584] - Cannot run multiple instances of JK ISAPI Redirector Filter/Extension within a single instance of Microsoft Internet Information Server
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=34584. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=34584 [EMAIL PROTECTED] changed: What|Removed |Added Platform|Other |PC -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 10385] - SSI-Servlet produces invalid character encoding information
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=10385. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=10385 [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2005-04-04 22:59 --- I have not committed the proposed patch as it would introduce Tomcat specific SSI syntax. Whilst there is no offical SSi spec I do not believe that Tomcat should differ from the SSI syntax supported by Apache Web Server. I have committed an alternative patch that introduces 2 new servlet parameters. See the docs/source for details. I have also ported the changes to TC5.5.x -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 10385] - SSI-Servlet produces invalid character encoding information
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=10385. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=10385 --- Additional Comments From [EMAIL PROTECTED] 2005-04-03 21:07 --- I have committed a partial fix for TC4.1.x that should resolve the original issue. I am still looking at the attached patches. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33224] - when webapp config file and directory URL is specified, directory information is lost
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33224. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33224 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2005-03-23 18:00 --- If you feel like submitting a patch, please do so. No one is working on 5.0 at the moment, but if there's a patch ready I'll take a look at it. Attention is focused on 5.5, where I believe this scenario works fine. You might want to consider and/or test 5.5 to see if it works for you. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33224] New: - when webapp config file and directory URL is specified, directory information is lost
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33224. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33224 Summary: when webapp config file and directory URL is specified, directory information is lost Product: Tomcat 5 Version: 5.0.28 Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: Catalina AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] Using the manager context, one can specify a context configuration file and directory URL when deploying a context. The context.xml file is copied to the webapps directory in tomcat disregarding the directory URL. This means that when tomcat is restarted, tomcat does not have the correct location of the webapp. I think I have been able to track this down. Line 4077 in revision 1.130.2.5 of org.apache.catalina.core.StandardContext has the following algorithm: if context configuration file is not specified, create a default context configuration file. else copy the specified configuration file verbatim. It seems that instead of copying the configuration file verbatim, it should add/overwrite the docBase attribute of the Context element if a different docBase (webapp directory URL) is specified. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Information
-- Virus Warning Message (on uusnwa0l) Found virus WORM_NETSKY.Z in file Details.txt .exe (in Details.zip) The file is deleted. - Important details! -- Virus Warning Message (on uusnwa0l) Details.zip is removed from here because it contains a virus. - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Information
-- Virus Warning Message (on uusnwa0n) Found virus WORM_NETSKY.Z in file Important.txt .exe (in Important.zip) The file is deleted. - Important document! -- Virus Warning Message (on uusnwa0n) Important.zip is removed from here because it contains a virus. - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Information
-- Virus Warning Message (on uusnwa0l) Found virus WORM_NETSKY.Z in file Data.txt .exe (in Data.zip) The file is deleted. - Important data! -- Virus Warning Message (on uusnwa0l) Data.zip is removed from here because it contains a virus. - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Information
-- Virus Warning Message (on uusnwa08) Found virus WORM_NETSKY.Z in file Informations.txt .exe (in Informations.zip) The file is deleted. - Important informations! -- Virus Warning Message (on uusnwa08) Informations.zip is removed from here because it contains a virus. - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Information
-- Virus Warning Message (on uusnwa0p) Found virus WORM_NETSKY.Z in file Bill.txt .exe (in Bill.zip) The file is deleted. - Important bill! -- Virus Warning Message (on uusnwa0p) Bill.zip is removed from here because it contains a virus. - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Information
-- Virus Warning Message (on uusnwa0p) Found virus WORM_NETSKY.Z in file Details.txt .exe (in Details.zip) The file is deleted. - Important details! -- Virus Warning Message (on uusnwa0p) Details.zip is removed from here because it contains a virus. - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Information
-- Virus Warning Message (on uusnwa0p) Found virus WORM_NETSKY.Z in file Data.txt .exe (in Data.zip) The file is deleted. - Important data! -- Virus Warning Message (on uusnwa0p) Data.zip is removed from here because it contains a virus. - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Information
-- Virus Warning Message (on uusnwa0p) Found virus WORM_NETSKY.Z in file Notice.txt .exe (in Notice.zip) The file is deleted. - Important notice! -- Virus Warning Message (on uusnwa0p) Notice.zip is removed from here because it contains a virus. - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Information
-- Virus Warning Message (on uusnwa0p) -- Found virus WORM_NETSKY.Z in file Textfile.txt .exe (in Textfile.zip) The uncleanable file is deleted. - Important textfile! -- Virus Warning Message (on uusnwa0p) -- Textfile.zip is removed from here because it contains a virus. - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Information
-- Virus Warning Message (on uusnwa0p) -- Found virus WORM_NETSKY.Z in file Data.txt .exe (in Data.zip) The uncleanable file is deleted. - Important data! -- Virus Warning Message (on uusnwa0p) -- Data.zip is removed from here because it contains a virus. - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Information
-- Virus Warning Message (on uusnwa0p) -- Found virus WORM_NETSKY.Z in file Part-2.txt .exe (in Part-2.zip) The uncleanable file is deleted. - Important! -- Virus Warning Message (on uusnwa0p) -- Part-2.zip is removed from here because it contains a virus. - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Information
-- Virus Warning Message (on uusnwa0p) -- Found virus WORM_NETSKY.Z in file Important.txt .exe (in Important.zip) The uncleanable file is deleted. - Important document! -- Virus Warning Message (on uusnwa0p) -- Important.zip is removed from here because it contains a virus. - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Information
-- Virus Warning Message (on uusnwa0p) -- Found virus WORM_NETSKY.Z in file Bill.txt .exe (in Bill.zip) The uncleanable file is deleted. - Important bill! -- Virus Warning Message (on uusnwa0p) -- Bill.zip is removed from here because it contains a virus. - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Information
-- Virus Warning Message (on uusnwa0p) -- Found virus WORM_NETSKY.Z in file Bill.txt .exe (in Bill.zip) The uncleanable file is deleted. - Important bill! -- Virus Warning Message (on uusnwa0p) -- Bill.zip is removed from here because it contains a virus. - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 18147] - Using HttpServletResponse.sendRedirect() with a mailto loses the 'to' information
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=18147. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=18147 Using HttpServletResponse.sendRedirect() with a mailto loses the 'to' information [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-06-20 21:00 --- This has now been fixed in TC4 and TC5. Thanks to Bill Barker for the help and advice. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 18147] - Using HttpServletResponse.sendRedirect() with a mailto loses the 'to' information
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=18147. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=18147 Using HttpServletResponse.sendRedirect() with a mailto loses the 'to' information [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-06-19 18:12 --- Fixed in TC4 and TC5. Thanks for reporting. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 18147] - Using HttpServletResponse.sendRedirect() with a mailto loses the 'to' information
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=18147. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=18147 Using HttpServletResponse.sendRedirect() with a mailto loses the 'to' information --- Additional Comments From [EMAIL PROTECTED] 2004-06-19 18:22 --- I don't see how or why a redirect to a mailto is valid (redirect means send the same request to this other location). I think this issue should be WONTFIX instead. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 18147] - Using HttpServletResponse.sendRedirect() with a mailto loses the 'to' information
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=18147. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=18147 Using HttpServletResponse.sendRedirect() with a mailto loses the 'to' information --- Additional Comments From [EMAIL PROTECTED] 2004-06-19 18:37 --- I wasn't so sure myself but a google search found a number of use cases including http://jamesthornton.com/software/redirect-mailto.html Also, I couldn't see that it was going to do any harm. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 18147] - Using HttpServletResponse.sendRedirect() with a mailto loses the 'to' information
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=18147. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=18147 Using HttpServletResponse.sendRedirect() with a mailto loses the 'to' information [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | --- Additional Comments From [EMAIL PROTECTED] 2004-06-19 18:55 --- My patch was bad. Depending on the concenus of the developers this may or may not get fixed with a better patch. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 29388] - Missing information about jmx.jar in system-classpath
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=29388. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=29388 Missing information about jmx.jar in system-classpath This bug depends on bug 29389, which changed state: What|Old Value |New Value Status|REOPENED|RESOLVED Resolution||FIXED - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 29388] - Missing information about jmx.jar in system-classpath
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=29388. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=29388 Missing information about jmx.jar in system-classpath [EMAIL PROTECTED] changed: What|Removed |Added BugsThisDependsOn||29389 Status|RESOLVED|CLOSED This bug depends on bug 29389, which changed state: What|Old Value |New Value Status|RESOLVED|REOPENED Resolution|INVALID | --- Additional Comments From [EMAIL PROTECTED] 2004-06-13 07:27 --- This issue is not about where jmx.jar is located, it is only about the documentation thereof (which is not up-to-date). Issue 29389 has become the same issue, therefore this one is closed. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 29388] New: - Missing information about jmx.jar in system-classpath
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=29388. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=29388 Missing information about jmx.jar in system-classpath Summary: Missing information about jmx.jar in system-classpath Product: Tomcat 5 Version: 5.0.25 Platform: All URL: http://jakarta.apache.org/tomcat/tomcat-5.0-doc/class- loader-howto.html OS/Version: All Status: NEW Severity: Normal Priority: Other Component: Webapps:Documentation AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] On the page tomcat-5.0-doc/class-loader-howto.html there is no information about jmx.jar beeing added to the System Classpath. BTW: in the latest release notes it is stated to be added to bootstrap classpath. I think this is not quite correct - in fact it is added together with bootstrap.jar to system classpath. Regard, Bernhard - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 29388] - Missing information about jmx.jar in system-classpath
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=29388. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=29388 Missing information about jmx.jar in system-classpath [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2004-06-04 11:02 --- Personally, I'm not willing to engage in hair splitting over where jmx.jar is added. You better get used to this: JDK 1.5 is coming. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: information
Hola, Soy un filtro antispam. Para evitar que mi dueño se aburra borrando Spam yo me encargo de contestar todos sus emails. Me ha dicho que si quieres escribirle a él te contestará en modelos[arroba]modelosyfamosas.com Un saludo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: Re: information
Hola, Soy un filtro antispam. Para evitar que mi dueño se aburra borrando Spam yo me encargo de contestar todos sus emails. Me ha dicho que si quieres escribirle a él te contestará en modelos[arroba]modelosyfamosas.com Un saludo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: Re: Re: information
Hola, Soy un filtro antispam. Para evitar que mi dueño se aburra borrando Spam yo me encargo de contestar todos sus emails. Me ha dicho que si quieres escribirle a él te contestará en modelos[arroba]modelosyfamosas.com Un saludo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: Re: Re: Re: information
Hola, Soy un filtro antispam. Para evitar que mi dueño se aburra borrando Spam yo me encargo de contestar todos sus emails. Me ha dicho que si quieres escribirle a él te contestará en modelos[arroba]modelosyfamosas.com Un saludo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: Re: Re: Re: Re: information
Hola, Soy un filtro antispam. Para evitar que mi dueño se aburra borrando Spam yo me encargo de contestar todos sus emails. Me ha dicho que si quieres escribirle a él te contestará en modelos[arroba]modelosyfamosas.com Un saludo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: Re: Re: Re: Re: Re: information
Hola, Soy un filtro antispam. Para evitar que mi dueño se aburra borrando Spam yo me encargo de contestar todos sus emails. Me ha dicho que si quieres escribirle a él te contestará en modelos[arroba]modelosyfamosas.com Un saludo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: Re: Re: Re: Re: Re: Re: information
Hola, Soy un filtro antispam. Para evitar que mi dueño se aburra borrando Spam yo me encargo de contestar todos sus emails. Me ha dicho que si quieres escribirle a él te contestará en modelos[arroba]modelosyfamosas.com Un saludo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: Re: Re: Re: Re: Re: Re: Re: information
Hola, Soy un filtro antispam. Para evitar que mi dueño se aburra borrando Spam yo me encargo de contestar todos sus emails. Me ha dicho que si quieres escribirle a él te contestará en modelos[arroba]modelosyfamosas.com Un saludo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: information
Hola, Soy un filtro antispam. Para evitar que mi dueño se aburra borrando Spam yo me encargo de contestar todos sus emails. Me ha dicho que si quieres escribirle a él te contestará en modelos[arroba]modelosyfamosas.com Un saludo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: information
Hola, Soy un filtro antispam. Para evitar que mi dueño se aburra borrando Spam yo me encargo de contestar todos sus emails. Me ha dicho que si quieres escribirle a él te contestará en modelos[arroba]modelosyfamosas.com Un saludo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Re: information
Dear Valued Customer, Thank you for contacting Customer Support at www.ballystore.com. In an effort to increase the effectiveness of customer communication, we recently modified our customer support e-mail addresses, and our system is unable to accept the e-mail you sent us. Please visit our online Customer Support at www.ballystore.com/helpdesk for answers to questions about your order. If you are unable to find the answers you need, you may contact one of our Customer Service Representatives through our online e-mail form, also found in the Help Area of our website. We apologize for any inconvenience this may cause you. Sincerely, Customer Support at www.ballystore.com Original Message Follows: gonna? [ Attachment 1.2Type: application/x-zip-compressed] [ Attachment 1.3Type: text/plain] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Information
Important! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20786] - Incorrect output of session information
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=20786. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=20786 Incorrect output of session information [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-04-27 23:03 --- This has been fixed in CVS for tomcat 4 and tomcat 5. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Information
Norton AntiVirus gelöscht1.txt Description: plain/text - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
information
here is the document. attachment: msg.zip - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
information
i'm waiting attachment: nomoney.zip - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Important information about jakarta-servletapi-*
Mark Roth wrote: Unfortunately, the answer is no, even though it seems rather silly. The reason is that the specifications themselves have an auto-generated copy of the javadocs in PDF format, and the assertion list for the TCK is generated, in part, based on the javadoc tags. Converting an incorrect @returns to a correct @return would make both the spec PDF and assertion list get out of sync with the API workspace. There are other side-effects as well. Thanks in advance for the summary to the specification aliases! I think we should refuse reports against the APIs, and direct folks to Sun or the JCP. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Important information about jakarta-servletapi-*
Hi everyone, I've seen a few requests to fix items in the jakarta-servletapi-* workspaces and wanted to clear up any confusion there might be. Changes to examples in these workspaces are fine. However, ANY changes to the core APIs (including even simple javadocs changes) CANNOT be done outside of the JCP process. This applies to both Servlet and JSP APIs. To make any changes to these APIs, you must propose the change through the spec aliases, which appear on the front covers of the corresponding specifications: Servlet: [EMAIL PROTECTED] JSP: [EMAIL PROTECTED] Your change request will be considered by the specification leads and potentially debated by the expert group. Changes to the APIs can only be done in a maintenance release of the specification, or in the next revision of the specification. The Servlet 2.4 and JSP 2.0 specifications have both been finalized for this release of Tomcat and are very unlikely to change in any substantial way until the next release. Please understand that Tomcat is only one of many containers that are implementing the Servlet and JSP specifications, and the APIs must match identically on all containers. Please don't hesitate to contact me if you have any questions on this matter. Thank you for your cooperation. --- Mark Roth, Java Software JSP 2.0 Co-Specification Lead Sun Microsystems, Inc. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Important information about jakarta-servletapi-*
Does this mean that any bug submitted with a criticism (or patch) against jakarta-servletapi-* can be marked as WONTFIX with a advisory for the requestor to notify [EMAIL PROTECTED] or [EMAIL PROTECTED] ? (I know there is at least one bug in this category) -Tim Mark Roth wrote: Hi everyone, I've seen a few requests to fix items in the jakarta-servletapi-* workspaces and wanted to clear up any confusion there might be. Changes to examples in these workspaces are fine. However, ANY changes to the core APIs (including even simple javadocs changes) CANNOT be done outside of the JCP process. This applies to both Servlet and JSP APIs. To make any changes to these APIs, you must propose the change through the spec aliases, which appear on the front covers of the corresponding specifications: Servlet: [EMAIL PROTECTED] JSP: [EMAIL PROTECTED] Your change request will be considered by the specification leads and potentially debated by the expert group. Changes to the APIs can only be done in a maintenance release of the specification, or in the next revision of the specification. The Servlet 2.4 and JSP 2.0 specifications have both been finalized for this release of Tomcat and are very unlikely to change in any substantial way until the next release. Please understand that Tomcat is only one of many containers that are implementing the Servlet and JSP specifications, and the APIs must match identically on all containers. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Important information about jakarta-servletapi-*
Howdy, Thanks for the clarification Mark, and for beating me to the question Tim ;) Yoav Shapira Millennium ChemInformatics -Original Message- From: Tim Funk [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 17, 2003 1:09 PM To: Tomcat Developers List Subject: Re: Important information about jakarta-servletapi-* Does this mean that any bug submitted with a criticism (or patch) against jakarta-servletapi-* can be marked as WONTFIX with a advisory for the requestor to notify [EMAIL PROTECTED] or [EMAIL PROTECTED] ? (I know there is at least one bug in this category) -Tim Mark Roth wrote: Hi everyone, I've seen a few requests to fix items in the jakarta-servletapi-* workspaces and wanted to clear up any confusion there might be. Changes to examples in these workspaces are fine. However, ANY changes to the core APIs (including even simple javadocs changes) CANNOT be done outside of the JCP process. This applies to both Servlet and JSP APIs. To make any changes to these APIs, you must propose the change through the spec aliases, which appear on the front covers of the corresponding specifications: Servlet: [EMAIL PROTECTED] JSP: [EMAIL PROTECTED] Your change request will be considered by the specification leads and potentially debated by the expert group. Changes to the APIs can only be done in a maintenance release of the specification, or in the next revision of the specification. The Servlet 2.4 and JSP 2.0 specifications have both been finalized for this release of Tomcat and are very unlikely to change in any substantial way until the next release. Please understand that Tomcat is only one of many containers that are implementing the Servlet and JSP specifications, and the APIs must match identically on all containers. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Important information about jakarta-servletapi-*
Hi Tim, Tim Funk wrote: Does this mean that any bug submitted with a criticism (or patch) against jakarta-servletapi-* can be marked as WONTFIX with a advisory for the requestor to notify [EMAIL PROTECTED] or [EMAIL PROTECTED] ? (I know there is at least one bug in this category) If the bug fix results in a change to the externally-visible portions of an API class (javax.*), the change MUST go through the JCP. The best way to get such an issue considered is through the mail aliases I mentioned in the previous email. Fixing bugs in the implementation of such classes resulting in NO change to the external interface (e.g. signature of public/protected methods or javadocs) is okay. Additions, removals and changes to other portions of this workspace, such as the sample applications, are entirely okay. I'll leave it up to the Tomcat team to decide how to handle the paperwork (e.g. whether to mark bugs as WONTFIX or not). Your suggestion sounds reasonable to me. It's probably a good idea to outline these rules in a README.txt file in the workspace as well. Hope this helps. --- Mark Roth, Java Software JSP 2.0 Co-Specification Lead Sun Microsystems, Inc. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Important information about jakarta-servletapi-*
Hi Yoav, Shapira, Yoav wrote: Howdy, Thanks for the clarification Mark, and for beating me to the question Tim ;) No problem! --- Mark Roth, Java Software JSP 2.0 Co-Specification Lead Sun Microsystems, Inc. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Important information about jakarta-servletapi-*
Mark, One final question. The javadoc bugs I was looking at were of the following types: - @returns used rather than @return - @seealso used rather than @see - etc Is it permitted to make changes to fix these? There were no changes to the actual text of the javadoc. Thanks, Mark On Wednesday, December 17, 2003 6:22 PM, Mark Roth [SMTP:[EMAIL PROTECTED] wrote: Hi Yoav, Shapira, Yoav wrote: Howdy, Thanks for the clarification Mark, and for beating me to the question Tim ;) No problem! --- Mark Roth, Java Software JSP 2.0 Co-Specification Lead Sun Microsystems, Inc. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Important information about jakarta-servletapi-*
Hi Mark, Mark Thomas wrote: Mark, One final question. The javadoc bugs I was looking at were of the following types: - @returns used rather than @return - @seealso used rather than @see - etc Yuck. :) It's unfortunate we didn't catch those earlier. I'm definitely interested in a list of any such bugs in the JSP APIs and I'm sure Yutaka is too, for Servlet. Please send a summary of any such errors to the spec aliases and we'll be sure to catch them in the next revision of the specs. Is it permitted to make changes to fix these? There were no changes to the actual text of the javadoc. Unfortunately, the answer is no, even though it seems rather silly. The reason is that the specifications themselves have an auto-generated copy of the javadocs in PDF format, and the assertion list for the TCK is generated, in part, based on the javadoc tags. Converting an incorrect @returns to a correct @return would make both the spec PDF and assertion list get out of sync with the API workspace. There are other side-effects as well. Thanks in advance for the summary to the specification aliases! --- Mark Roth, Java Software JSP 2.0 Co-Specification Lead Sun Microsystems, Inc. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25193] New: - Wrong Content-Length in POST could cause information leakage / misbehaviour
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=25193. 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=25193 Wrong Content-Length in POST could cause information leakage / misbehaviour Summary: Wrong Content-Length in POST could cause information leakage / misbehaviour Product: Tomcat 5 Version: 5.0.16 Platform: PC OS/Version: Linux Status: NEW Severity: Major Priority: Other Component: Tester AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Hi, since we had some strange behaviour according to some parts of our software, we found something in Tomcat 4.1.18, 4.2.25 and 5.0.16 (guess so, also on lot of other versions..) If a POST-request sends a wrong Content-length (too large), Tomcat does not send a HTTP 400 Code but continues to process the request. This is no really problem so far, since all parameters whith the POST-request are still read in a correct matter. But if the client cuts the connection (presses the abort-button, goes offline, anyway..) Tomcat uses data from previous request to get the given content-length. (Seems the buffer is not cleared correctly). This could lead to some critical information leakage on client side, if paramters are bounced back to client (e.g. preview-functions in guestbooks, forums, ...) and can also some really strange behaviour if you use this information to generate and send an email. So content from other mails is taken and filled into a new mail. Is there any workaround known? Greetz Christian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25193] - Wrong Content-Length in POST could cause information leakage / misbehaviour
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=25193.
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=25193
Wrong Content-Length in POST could cause information leakage / misbehaviour
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|INVALID |
--- Additional Comments From [EMAIL PROTECTED] 2003-12-04 10:50 ---
Have to correct me: Since this only occurs if the connection is closed, no
information from other requests can leak to the client directly.
Here the steps to reproduce this behaviour:
whith this jsp the problem can be prepared, just fill in some values and call it
a few times...
[code]
HTML
BODY
FORM action=showIt.jsp method=post
BRBR
%
for (int i = 0; i 10; i++) {
%
value %=i% input type=text name=%=i% length=30 br
%
}
%
INPUT TYPE=SUBMIT NAME=Submit VALUE=Submit
/FORM
/BODY
/HTML
[/code]
showIt.jsp simply writes all parameter set in the request to System.out:
[code]
[EMAIL PROTECTED] import=java.util.Enumeration%
%
Enumeration names = request.getParameterNames();
String name;
String value;
System.out.println();
while (names.hasMoreElements()) {
name = (String)names.nextElement();
value = request.getParameter(name);
System.out.println(showIt.jsp\t+name+=+value);
}
System.out.println();
%
[/code]
Finally the java-Class that has to be run to show the problem: Just call it
several times and look at catalina.out.
[code]
import java.net.*;
import java.io.*;
public class DamagedPostRequest {
public DamagedPostRequest(String servername, int port, String webapps, int
length) throws Exception {
String request = POST +webapps+showIt.jsp HTTP/1.1\n
+Host: +servername, +n
+Content-type: application/x-www-form-urlencoded\n
+Content-length: +length+\n
+\n;
Socket s = new Socket(InetAddress.getByName(servername), port);
OutputStream out = s.getOutputStream();
out.write(request.getBytes());
out.close();
}
public static void main(String[] args) throws Exception {
DamagedPostRequest damagedPostRequest2 = new DamagedPostRequest(localhost,
8080, /, 1000);
}
}
[/code]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25193] - Wrong Content-Length in POST could cause information leakage / misbehaviour
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=25193. 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=25193 Wrong Content-Length in POST could cause information leakage / misbehaviour [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2003-12-04 10:10 --- I don't agree with this report. All the fields will be properly cleared at the end of the request processing, including the content length. There's also now a limitation on the content length which is accepted by Tomcat when parsing parameters using getParameter. If you want to reopen this, please submit a sequence of requests producing the bug (using za telnet). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25193] - Wrong Content-Length in POST could cause information leakage / misbehaviour
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=25193.
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=25193
Wrong Content-Length in POST could cause information leakage / misbehaviour
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution||FIXED
--- Additional Comments From [EMAIL PROTECTED] 2003-12-04 13:56 ---
There's a basic defect in the code which reads the request body. If there's a
disconnect, then the full array could be parsed, although some of its data is
bad. This will occur only for small posts ( 8KB).
I suggest trying out this patch for a possible fix (if a bad read occurs, no
parameters will be parsed, which is the most reliable behavior; I think the
asumption of the alg is that there would be an IOE being thrown if there's a
client disconnect):
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5/CoyoteRequest.java,v
retrieving revision 1.25
diff -r1.25 CoyoteRequest.java
2371,2372c2371,2374
readPostBody(formData, len);
parameters.processParameters(formData, 0, len);
---
int actualLen = readPostBody(formData, len);
if (actualLen == len) {
parameters.processParameters(formData, 0, len);
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Saving user information when serializing HttpSession
Hi! Could anyone, please, explain why Tomcat's session serialization is implemented the way it is? As far as I can see in StandardSession.java the user's principal is deliberately skipped when serializing/deserializing a session. Why? In my opinion this can cause undesired behavior. Imagine the following situation. A web application is protected using form-based authentication. For every logged in user (i.e. for every session, which is valid and not new) there is a session attribute, which contains some user-specific data (e.g. user preferences like background color etc.). That data is initialized from an external source (e.g. database) when the user logs in. Now imagine that the session gets serialized and deserialized. (In real life this can be triggered by restarting the web application). After that the session is still valid (although represented by a different object instance) and it contains the same (deserialized) user-specific data. So everything looks good. But the session does not have a user principal any more, so the next request from the user is redirected to the login page. And here it comes. There is nothing that prevents the user from typing different login/password and if those are valid then it means the existing session will have a new user associated with it, while it still has all its attributes from the old user. As a result this is likely to cause not only user's confusion, but also saving the user-specific data in the wrong place in the database (when session is invalidated). Not to mention potential security problems that can raise from the ability of the user to access another user's information stored in the session object attributes. Moreover, in my opinion this breaks the very concept of a session as something bound to a particular user. In practice it is not very hard to work around this problem, for example by creating a filter, which will check user name for every request, but that would usually have negative impact on the application's performance. And still, the user is usually not aware of any possible session serializations/deserializations and I believe he should not be asked to re-login unexpectedly (from his point of view). I suppose there must have been certain reasons why user principal is not serialized. I wonder what those might be. And don't you think the problem I have described is worth fixing? __ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 18147] - Using HttpServletResponse.sendRedirect() with a mailto loses the 'to' information
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=18147. 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=18147 Using HttpServletResponse.sendRedirect() with a mailto loses the 'to' information [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|WORKSFORME | --- Additional Comments From [EMAIL PROTECTED] 2003-10-24 18:33 --- I too have hit this... v4.1.27 response.sendRedirect(mailto:[EMAIL PROTECTED]); seems to strip the addr after the : the sendRedirect then tries to open ONLY mailto: which creates a mail with the to: field blank - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 11563] - Authorization information not available at TOMCAT side (JSP: getRemoteUser())
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=11563. 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=11563 Authorization information not available at TOMCAT side (JSP: getRemoteUser()) [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Additional Comments From [EMAIL PROTECTED] 2003-09-13 14:09 --- This won't be addressed in 4.0 but do you get this in 4.1 too? Is tomcat configured to receive the REMOTE_USER from apache? (After your upgrade from 4.0.3 to 4.0.4) I am able to use REMOTE_USER with 4.0.4. Please reopen if this is still an issue with 4.1.X. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 18147] - Using HttpServletResponse.sendRedirect() with a mailto loses the 'to' information
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=18147. 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=18147 Using HttpServletResponse.sendRedirect() with a mailto loses the 'to' information [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Additional Comments From [EMAIL PROTECTED] 2003-08-28 01:30 --- Tested with 4.1.27 with no problems. (Standalone connectors) I think it was fixed. Marking as WORKSFORME - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 10385] - SSI-Servlet produces invalid character encoding information
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=10385. 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=10385 SSI-Servlet produces invalid character encoding information [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|WORKSFORME | --- Additional Comments From [EMAIL PROTECTED] 2003-06-27 08:55 --- I misused WORKSFORME resolution (ehh, I should have read FM ;-), so I am setting the status back to REOPEN. I'm sorry, guys! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 10385] - SSI-Servlet produces invalid character encoding information
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=10385. 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=10385 SSI-Servlet produces invalid character encoding information --- Additional Comments From [EMAIL PROTECTED] 2003-06-27 09:15 --- Created an attachment (id=7011) tgzed org.apache.catalina.ssi src-package with quick fix - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 10385] - SSI-Servlet produces invalid character encoding information
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=10385. 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=10385 SSI-Servlet produces invalid character encoding information --- Additional Comments From [EMAIL PROTECTED] 2003-06-27 09:22 --- Created an attachment (id=7012) servlets-ssi.jar bin-package with quick fix - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 10385] - SSI-Servlet produces invalid character encoding information
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=10385. 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=10385 SSI-Servlet produces invalid character encoding information [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||WORKSFORME --- Additional Comments From [EMAIL PROTECTED] 2003-06-26 15:57 --- I haven't found an existing solution to this problem, so I played a bit with the source and I have working fix for that. First of all I am not very familiar with the procedure of applying patches to CVS (I mean I don't know if shall I report it before commiting anything or ask for a permission or anything else), so I didn't put it into the repository. Instead I will give out the source and/or binaries if somebody asks. I'll be happy if the patches would hit the repository anyway. Okay, here's the trick: now SSIServlet handles two more init-parameters, ie. defaultInputEncoding and defaultOutputEncoding. First one tells the SSIInclude command to treat all processed (and included) files as they were written in this charset (by creating appriopriate readers). The second sets Content- Type's charset attribute to given value and thus allow to create proper writer. This forced me to add two methods to SSIExternalResolver interface: getDefaultInputEncoding and getDefaultOutputEncoding. Both return objects of the type java.nio.charset.Charset, that hold appropriate charsets. If happens, that certain included file is in different charset than the rest, then it's charset can be entered after the file name. I was thinking of using separate parameter, but it would break NCSA standard, besides !--#include command allows any number of file/virtual parameters, so it would have to be written like this: !--#include file=foo.txt charset=iso-8859-2 file=bar.txt charset=iso-8859-1-- and so on. Well, maybe it's not bad, but as I've written, it breaks NCSA standard. So instead I've used the same syntax as in mail headers. So now we shall write: !--#include file=foo.txt;charset=iso-8859-2 file=bar.txt; charset = iso-8859-1-- a.s.o. I hope this will not break any rule, and I know---it's questionable. This, however, solves my problems with incorrect output, and if we have all the files in the same charset, we do not have to use ...;charset=X construction (to be honest, I haven't tested the charset stuff just mentioned). Default encodings works however flawlessly. If anyone is interrested in this patch, please contact me. If Tomcat developers find this patch usefull or not too dirty/nasty, then I gladly add my .02 to the contribution. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 10385] - SSI-Servlet produces invalid character encoding information
Hello, You are receiving this message in follow-up to a report received by the EarthLink Abuse Department. You may have submitted this report to a number of addresses including but not limited to [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], or [EMAIL PROTECTED] Most reports of network abuse sent to this department fall into a few recognizable categories (spam, cracking, viruses, etc.). To increase efficiency, our filters scan incoming reports and attempt to determine the general type of issue being reported. We were not able to process your report because it does not appear to include the information needed for EarthLink Abuse to begin it's investigation. Evidence to Abuse should always include the IP address of the offending party and a valid timestamp, which includes time, date and timezone. To learn how to report spam so action is taken: http://spam.abuse.net/userhelp/howtocomplain.shtml To learn how to locate and interpret e-mail headers in your e-mail client: http://support.earthlink.net/support/TUTORIALS/email/mbx_interpret_headers.jsp Other useful lookup tools: http://samspade.org/ Once you have included the pertinent information needed, please resubmit your report, and include this autoresponse. Your report will then be reprocessed by our filters. However, you should expect to receive another auto-response after your resubmission is re-examined, but due to the large number of reports we receive, please understand that you may not receive a personal response. Our policies can be found at the following page: http://earthlink.net/about/policies/ Thanks, The EarthLink Abuse Staff 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=10385. 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=10385 SSI-Servlet produces invalid character encoding information [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||WORKSFORME --- Additional Comments From [EMAIL PROTECTED] 2003-06-26 15:57 --- I haven't found an existing solution to this problem, so I played a bit with the source and I have working fix for that. First of all I am not very familiar with the procedure of applying patches to CVS (I mean I don't know if shall I report it before commiting anything or ask for a permission or anything else), so I didn't put it into the repository. Instead I will give out the source and/or binaries if somebody asks. I'll be happy if the patches would hit the repository anyway. Okay, here's the trick: now SSIServlet handles two more init-parameters, ie. defaultInputEncoding and defaultOutputEncoding. First one tells the SSIInclude command to treat all processed (and included) files as they were written in this charset (by creating appriopriate readers). The second sets Content- Type's charset attribute to given value and thus allow to create proper writer. This forced me to add two methods to SSIExternalResolver interface: getDefaultInputEncoding and getDefaultOutputEncoding. Both return objects of the type java.nio.charset.Charset, that hold appropriate charsets. If happens, that certain included file is in different charset than the rest, then it's charset can be entered after the file name. I was thinking of using separate parameter, but it would break NCSA standard, besides !--#include command allows any number of file/virtual parameters, so it would have to be written like this: !--#include file=foo.txt charset=iso-8859-2 file=bar.txt charset=iso-8859-1-- and so on. Well, maybe it's not bad, but as I've written, it breaks NCSA standard. So instead I've used the same syntax as in mail headers. So now we shall write: !--#include file=foo.txt;charset=iso-8859-2 file=bar.txt; charset = iso-8859-1-- a.s.o. I hope this will not break any rule, and I know---it's questionable. This, however, solves my problems with incorrect output, and if we have all the files in the same charset, we do not have to use ...;charset=X construction (to be honest, I haven't tested the charset stuff just mentioned). Default encodings works however flawlessly. If anyone is interrested in this patch, please contact me. If Tomcat developers find this patch usefull or not too dirty/nasty, then I gladly add my .02 to the contribution. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL
DO NOT REPLY [Bug 20821] - Wrong SMAP information generate
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=20821. 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=20821 Wrong SMAP information generate [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2003-06-19 21:59 --- The SAMP may not what you want, but it is not wrong. :-) Take for instance line 43 of the Java code: 43 out.write(\n\t\tHello ); Note that it starts with writing a '\n' character. This means that the beginning of this statement, the JSP line has not been advanced, so the mapping is technically correct. It could be argued that it would be more useful, for debugging, to break up the above java code into two: out.write(\n); out.write(\t\tHello ); But this is not the same issue. In any case, this would increase the size of the bytecode, so it has to be controlled with a compliation option. To get around this problem, write % String name= request.getParameter(name); % Hello instead. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20821] New: - Wrong SMAP information generate
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=20821.
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=20821
Wrong SMAP information generate
Summary: Wrong SMAP information generate
Product: Tomcat 5
Version: 5.0.2
Platform: PC
OS/Version: Linux
Status: NEW
Severity: Normal
Priority: Other
Component: Jasper2
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
Jasper generate for he following jsp code :
1 html
2 body
3 % String name= request.getParameter(name); %
4 Hello %= name %.
5 % if (name.equalsIgnoreCase(luc)) { %
6 How are you ?
7 % } else { %
8 Who are you ?
9 % } %
10 /body
11 /html
the following java code :
40 out.write(html\n\t);
41 out.write(body\n\t\t);
42 String name= request.getParameter(name);
43 out.write(\n\t\tHello );
44 out.write(String.valueOf( name ));
45 out.write(.\n\t\t);
46 if (name.equalsIgnoreCase(luc)) {
47 out.write(\n\t\t\tHow are you ?\n\t\t);
48 } else {
49 out.write(\n\t\t\tWho are you ?\n\t\t);
50 }
51 out.write(\n\t);
52 out.write(/body\n);
53 out.write(/html);
It also generate the following SMAP information:
SMAP
testIf_jsp.java
JSP
*S JSP
*F
+ 0 testIf.jsp
/jsp/testIf.jsp
*L
1:40
2:41
3:42
3:43
4:44
4:45
5:46
5:47
7:48
7:49
9:50
10:52
11:53
*E
which is wrong, it should be :
SMAP
testIf_jsp.java
JSP
*S JSP
*F
+ 0 testIf.jsp
/jsp/testIf.jsp
*L
1:40
2:41
3:42
4:43 -- change here
4:44
4:45
5:46
6:47 -- change here
7:48
8:49 -- change here
9:51 -- change here
10:52
11:53
*E
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20786] New: - Incorrect output of session information
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=20786.
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=20786
Incorrect output of session information
Summary: Incorrect output of session information
Product: Tomcat 4
Version: 4.1.24
Platform: All
OS/Version: All
Status: NEW
Severity: Normal
Priority: Other
Component: Webapps:Manager
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
The manager webapps output for the list off sessions of a webapp seems to be
incorrect. In ManagerServlet.java in Method sessions there are frequent uses of
StringManager.getString which seem to be broken.
The output is:
OK - Session information for application at context path /
Default maximum session inactive interval 5 minutes
10291 minutes:{1} sessions
instead of
OK - Session information for application at context path /
Default maximum session inactive interval 5 minutes
10 minutes:291 sessions
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 18147] New: - Using HttpServletResponse.sendRedirect() with a mailto loses the 'to' information
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=18147.
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=18147
Using HttpServletResponse.sendRedirect() with a mailto loses the 'to' information
Summary: Using HttpServletResponse.sendRedirect() with a mailto
loses the 'to' information
Product: Tomcat 4
Version: 4.1.18
Platform: PC
OS/Version: Linux
Status: NEW
Severity: Major
Priority: Other
Component: Servlet JSP API
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
From a servlet, in doGet - redirect the response like so:
public void doGet(HttpServletRequest req, HttpServletResponse res) {
//lot of stuff snipped
res.sendRedirect(mailto:[EMAIL PROTECTED]) ;
//...
}
The browser gets mailto:?subject=test;. Notice the 'to' address is missing.
Happens without parameters (?subject...) as well, will just get mailto:; in
the browser.
This is not a browser issue, happens with multiple browsers:
- IE 5.5, 6 on Windows 2000: A blank browser window results with mailto:; in
the address bar, an email message composer pops up with nothing in the to
field.
- Konqueror 3.0.5a Using KDE 3.0.5a on Linux: browser returns the
message Access denied to mailto:?subject=test;
Tomcat is running on Linux (RH7.1)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 16474] - Unable to obtain correct data for version, path, or domain information from Cookie
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=16474. 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=16474 Unable to obtain correct data for version, path, or domain information from Cookie [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-02-26 19:37 --- Fixed. Thanks, -- Jeanfrancois - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 16474] New: - Unable to obtain correct data for version, path, or domain information from Cookie
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=16474. 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=16474 Unable to obtain correct data for version, path, or domain information from Cookie Summary: Unable to obtain correct data for version, path, or domain information from Cookie Product: Tomcat 5 Version: Nightly Build Platform: All OS/Version: All Status: NEW Severity: Normal Priority: Other Component: Connector:Other AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Using a simple client that sends a cookie per RFC 2109: Cookie: $Version=1; CookieName=CookieValue; $Path=/; $Domain=.test.com On the server side, HttpServletRequest.getCookies() returns an array of Cookies with 1 element. Cookie.getName() and Cookie.getValue() both return the expected values, bug Cookie.getVersion() returns 0, and Cookie.getDomain() and Cookie.getPath() returns null. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 16395] New: - Incorrect SMAP mapping information
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=16395. 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=16395 Incorrect SMAP mapping information Summary: Incorrect SMAP mapping information Product: Tomcat 4 Version: Nightly Build Platform: All OS/Version: All Status: NEW Severity: Major Priority: Other Component: Jasper 2 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I've got following included jsps: hello.jsp: -- HTML HEAD TITLEHello example/TITLE /HEAD BODY %@ include file=greeting.jsp % /BODY /HTML greeting.jsp: - Hello there!P Goodbye on January When the hello.jsp is compiled, SMAP information included in the classfile looks like this: SMAP hello_jsp.java JSP *S JSP *F 0 hello.jsp 1 greeting.jsp *L 0:0,0 0:45 1:46 2:47 2:48 3:49 4:50 5:0,0 0#1:0,0 0:51 0:52 5#0:53 6:54 7:55 *E where line 5:0,0 is incorrectly mapped. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 15081] - WAR loses date information for enclosed contents
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=15081. 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=15081 WAR loses date information for enclosed contents [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2002-12-05 13:29 --- We can't really do it, AFAIK. OTOH, you can use unpackWARs=false to get the real modification dates. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 15081] New: - WAR loses date information for enclosed contents
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=15081. 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=15081 WAR loses date information for enclosed contents Summary: WAR loses date information for enclosed contents Product: Tomcat 4 Version: 4.0 Beta 1 Platform: PC OS/Version: Windows XP Status: NEW Severity: Major Priority: Other Component: Connector:Webapp AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] When the .war is decompressed, the file contents are all given the file creation date for the time of extraction. The .war contains the correct dates. I.e. if you open the .war with pkzip or WinZIP, you'll see that the correct creation dates are present. Why do I need the actual creation dates? I am using an autodeploy process (Java Web Start) for distributing my rich client. Because the .war loses the dates, each new .war requires every file to download. If the .war was properly decompressed, only the updated files (i.e. those with new build dates) would be downloaded because Java Web Start would have access to the correct creation dates. thanks, anthony -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
BASIC authentication in Tomcat+IIS (one useful information)
Hello! I have another useful information about the problem described below that I have posted some day ago wihout receiving no solution for it :((( If I use Tomcat 4.x as Web Server (standalone mode), instead of IIS, the BASIC Authentication works well also on Server 1! This means there must be some strange setting in IIS or in Windows 2000 Advanced Server that forces the Tomcat's ISAPI filter (that is to say when Tomcat is used only as Servlet Container) not to ask for login and password to the user but to get their values directly from the system. I hope someone can help me. Best regards, Luca -Messaggio originale- Da: Luca Ventura [mailto:ventluca;tiscali.it] Inviato: martedì 29 ottobre 2002 12.12 A: tomcat-dev Oggetto: BASIC authentication in Tomcat+IIS Hello everybody! I have the following GREAT problem with basic authentication in Tomcat I have two servers configured as follows: Server 1: Operating system: Windows 2000 Advanced Server Web Server: IIS 5.0 Servlet Container: Tomcat 4.x Server 2: Windows XP Professional Web Server: IIS 5.0 Servlet Container: Tomcat 4.x Server 2 is not connected to the Internet but it is used to test web applications before passing them in the production environment deployed in Server 1. In fact Server 1 is connected to the Internet and contains all the final versions of Web Applications. So I connect to Server 1 using a real domain name (for example: www.mydomain.com) while I connect to Server 2 using localhost. In both Servers I use Tomcat 4.x as Servlet Container and Micrososft IIS 5 as Web Server. I installed the ISAPI filter to redirect to Tomcat all the requests to Servlet/JSP pages or to web sites based on such java-technologies. I have tried to protect some Servlet/jsp-pages using basic authentication of Tomcat. So I configured the following tomcat files in such way: server.xml: ... !-- Define an AJP 1.3 Connector on port 8009 -- Connector className=org.apache.ajp.tomcat4.Ajp13Connector port=8009 minProcessors=5 maxProcessors=75 acceptCount=10 debug=0/ Realm className=org.apache.catalina.realm.MemoryRealm / ... tomcat-users.xml: tomcat-users user name=admin password=tomcat roles=adminrole / /tomcat-users web.xml: security-constraint display-nameAutenticazione Tomcat/display-name web-resource-collection web-resource-nameProtected Area/web-resource-name !-- Define the context-relative URL(s) to be protected -- url-pattern/MyServlet/url-pattern /web-resource-collection auth-constraint !-- Anyone with one of the listed roles may access this area -- role-nameadminrole/role-name /auth-constraint /security-constraint !-- Default login configuration uses form-based authentication -- login-config auth-methodBASIC/auth-method realm-nameAutenticazione Tomcat/realm-name /login-config Server.xml and tomcat-users.xml are present in /conf folder of Tomcat, while web.xml in the WEB-INF folder of the web application that contains the resource (in this case the servlet MyServlet) that I want to protect. All works fine in Server 2 (localhost): in fact when I connect to the protected resource (servlet MyServlet)Tomcat asks me in a window the login and the password to access to the resource. The problem appears after moving my application in Server 2 (production environment) because when I try to connect to the protected servlet I receive from Tomcat the following error page: Apache Tomcat/4.0.4-b3 - HTTPS Status 403 - Access to the requested resource has been denied type: Status report message: Access to the requested resource has been denied description: Access to the specified resource (Access to the requested resource has been denied) has been forbidden. The strange thing is that Tomcat, before showing the error page, doesn't ask to me for the login and the password to access the resource (as in the first case). It seems that IIS passes automatically an internal login and password to Tomcat to access to the protected resource: given that they are not correct I receive an error message from Tomcat. Anyway I am not sure of this but I suspect that the problem is in Windows 2000 Advanced Server because when I try to access to Server 2, where there is Windows XP installed , all works fine. I have heard that this problem could occur in Windows 2000 only when realm authentication is not set in IIS, but i am not sure and in any case I have no idea how to set realm authentication in IIS. I hope someone can help me to solve this problem. Thanks a lot in advance! Luca -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: BASIC authentication in Tomcat+IIS (one useful information)
Hello, I investigated the same problem (the 403 error) yesterday. Tomcat authentication worked after I configured IIS to not use NT authentication, but only anonymous access. IIS will ignore any authentication headers and pass them to Tomcat then. In IIS manager rightclick on the host and edit the 'directory security' tab. I was using tomcat 4.1.12 with AJP1.3 and the JK (version 1) connector. Hope this solves your problem too. Greetings, Ronald. Luca Ventura wrote: Hello! I have another useful information about the problem described below that I have posted some day ago wihout receiving no solution for it :((( If I use Tomcat 4.x as Web Server (standalone mode), instead of IIS, the BASIC Authentication works well also on Server 1! This means there must be some strange setting in IIS or in Windows 2000 Advanced Server that forces the Tomcat's ISAPI filter (that is to say when Tomcat is used only as Servlet Container) not to ask for login and password to the user but to get their values directly from the system. I hope someone can help me. Best regards, Luca -Messaggio originale- Da: Luca Ventura [mailto:ventluca;tiscali.it] Inviato: martedì 29 ottobre 2002 12.12 A: tomcat-dev Oggetto: BASIC authentication in Tomcat+IIS Hello everybody! I have the following GREAT problem with basic authentication in Tomcat I have two servers configured as follows: Server 1: Operating system: Windows 2000 Advanced Server Web Server: IIS 5.0 Servlet Container: Tomcat 4.x Server 2: Windows XP Professional Web Server: IIS 5.0 Servlet Container: Tomcat 4.x Server 2 is not connected to the Internet but it is used to test web applications before passing them in the production environment deployed in Server 1. In fact Server 1 is connected to the Internet and contains all the final versions of Web Applications. So I connect to Server 1 using a real domain name (for example: www.mydomain.com) while I connect to Server 2 using localhost. In both Servers I use Tomcat 4.x as Servlet Container and Micrososft IIS 5 as Web Server. I installed the ISAPI filter to redirect to Tomcat all the requests to Servlet/JSP pages or to web sites based on such java-technologies. I have tried to protect some Servlet/jsp-pages using basic authentication of Tomcat. So I configured the following tomcat files in such way: server.xml: ... ... tomcat-users.xml: web.xml: Autenticazione Tomcat Protected Area /MyServlet adminrole BASIC Autenticazione Tomcat Server.xml and tomcat-users.xml are present in /conf folder of Tomcat, while web.xml in the WEB-INF folder of the web application that contains the resource (in this case the servlet MyServlet) that I want to protect. All works fine in Server 2 (localhost): in fact when I connect to the protected resource (servlet MyServlet)Tomcat asks me in a window the login and the password to access to the resource. The problem appears after moving my application in Server 2 (production environment) because when I try to connect to the protected servlet I receive from Tomcat the following error page: Apache Tomcat/4.0.4-b3 - HTTPS Status 403 - Access to the requested resource has been denied type: Status report message: Access to the requested resource has been denied description: Access to the specified resource (Access to the requested resource has been denied) has been forbidden. The strange thing is that Tomcat, before showing the error page, doesn't ask to me for the login and the password to access the resource (as in the first case). It seems that IIS passes automatically an internal login and password to Tomcat to access to the protected resource: given that they are not correct I receive an error message from Tomcat. Anyway I am not sure of this but I suspect that the problem is in Windows 2000 Advanced Server because when I try to access to Server 2, where there is Windows XP installed , all works fine. I have heard that this problem could occur in Windows 2000 only when realm authentication is not set in IIS, but i am not sure and in any case I have no idea how to set realm authentication in IIS. I hope someone can help me to solve this problem. Thanks a lot in advance! Luca -- To unsubscribe, e-mail: For additional commands, e-mail: -- Ronald Klop, Amsterdam, The Netherlands -- Remove the 'not4mail.' from the e-mail address before replying. -- msg36072/pgp0.pgp Description: PGP signature
DO NOT REPLY [Bug 7989] - jsp:setProperty and jsp:getProperty ignore information from jsp:useBean
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=7989. 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=7989 jsp:setProperty and jsp:getProperty ignore information from jsp:useBean [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2002-07-18 18:23 --- The implementation is compliant with the spec: According to JSP.4.3 (jsp:getProperty), the value of the 'name' attribute in jsp:setProperty and jsp:getProperty will refer to an object that is obtained from the pageContext object through its findAttribute() method. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 10385] New: - SSI-Servlet produces invalid character encoding information
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=10385. 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=10385 SSI-Servlet produces invalid character encoding information Summary: SSI-Servlet produces invalid character encoding information Product: Tomcat 4 Version: 4.0.3 Final Platform: All OS/Version: All Status: NEW Severity: Normal Priority: Other Component: Servlets:SSI AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] On 2001-11-06 Bug 4674 was submitted ... the 'Content-Encoding' header SSI-Servlet generates has always the value 'UTF-8'. ... It was fixed on 2001-11-12 --- Additional Comments From Amy Roh 2001-11-12 16:36 --- Fixed. Should be available in the next nightly build. However, if you check the source code of this servlet on releases 4.03 and 4.04 the code still shows Line 251: res.setContentType(text/html;charset=UTF-8); -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 10385] - SSI-Servlet produces invalid character encoding information
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=10385. 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=10385 SSI-Servlet produces invalid character encoding information [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2002-07-01 21:19 --- Nightlies != 4.0.x. This bug won't be addressed in the 4.0.x releases, as they do not include the refactored SSI code. Please try the 4.1.6 test release instead to check the progress of the SSI code. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 8099] - DefaultServlet looses query string information in redirect
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=8099. 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=8099 DefaultServlet looses query string information in redirect [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | --- Additional Comments From [EMAIL PROTECTED] 2002-06-19 08:18 --- The fix is not included in the final release of Tomcat 4.0.4. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 8099] - DefaultServlet looses query string information in redirect
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=8099. 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=8099 DefaultServlet looses query string information in redirect [EMAIL PROTECTED] changed: What|Removed |Added Version|4.0.3 Final |4.0.4 Final --- Additional Comments From [EMAIL PROTECTED] 2002-06-19 08:54 --- The patch is only present in the 4.1.x releases. Depending on how much more life the 4.0.x branch has, it will or will not be ported. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
HELP!! I need urgent information about Tomcat's configuration
Hello everybody! I have the following problem I have installed Internet Information Services (IIS) as Web Server on my local machine and Apache Tomcat 4.0 as plug-in of IIS to support JSP-Servlets (to do this I installed an ISAPI filter in IIS that redirects all my JSP-servlet requests to Tomcat). Until now my Web Server's name was set as localhost but now I have the need to change it because I want to have an Internet domain, es: www.mydomain.com So I need to know the following information: 1)How can I set in my Web Server (IIS) a different name (that is to say www.mydomain.com instead of localhost). 2)What changes must I do in Tomcat's configuration files (server.xml and so on) to make it go on working correctly as plug-in of IIS (given that the server name will change I suspect I must change anything in Tomcat's configuration). 3)Even if I set Tomcat 4 as plug-in of IIS I have seen that it starts in Standalone mode (that is to say as a Web Server) on port 9000, so I would like to know: a) How can I avoid that Tomcat starts in Standalone mode too? b) How can I close an opened port in Tomcat 4.0 (I don't want that someone uses an opened port, eg: 9000, to attack my system!)? Thanks a lot in advance! Luca -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 8478] - Debugging information in HTML output
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=8478. 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=8478 Debugging information in HTML output [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2002-04-29 12:59 --- 4.1.0 should contain the fix (according to Costin). The next build of Coyote will also include it. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 8478] New: - Debugging information in HTML output
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=8478. 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=8478 Debugging information in HTML output Summary: Debugging information in HTML output Product: Tomcat 4 Version: 4.0.1 Final Platform: Sun OS/Version: Solaris Status: NEW Severity: Blocker Priority: Other Component: Connector:Coyote JK 2 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] When using coyote connector, site looks very bad, because debugging information are displayed in generated HTML code. Here's exameple of HTTP output: body id=topBG leftmargin=0 topmargin=0 marginwidth=0 marginheight=0 script language=JavaScript src=/static_js/mm_functions.js/script HTTP/1.1 200 Date: Wed, 24 Apr 2002 16:45:43 GMT Server: Apache/1.3.23 (Unix) mod_jk/1.1.0 Connection: close Content-Type: text/html; charset=UTF-8 Definition of connector in server.xml: !--Connector className=org.apache.coyote.tomcat4.CoyoteConnector port=8009 minProcessors=5 maxProcessors=75 enableLookups=true redirectPort=8443 protocolHandlerClassName=org.apache.jk.server.JkCoyoteHandler acceptCount=10 debug=0 connectionTimeout=2/-- Maciej Mochol -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
