DO NOT REPLY [Bug 25055] - getRemoteUser() returns null - bypass of apache authentication
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=25055. 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=25055 getRemoteUser() returns null - bypass of apache authentication [EMAIL PROTECTED] changed: What|Removed |Added Summary|getRemoteUser() returns null|getRemoteUser() returns null |(again) |- bypass of apache ||authentication --- Additional Comments From [EMAIL PROTECTED] 2003-12-02 07:43 --- ok, I found a workaround to my problem by placing the limit tag directly into the httpd.conf instead of a .htaccess file This looks then like this VirtualHost Location /protecteddir AuthUserFile /path_to_.htpasswd AuthGroupFile /dev/null AuthName Please enter username and password AuthType Basic Limit GET POST require valid-user /Limit /Location I remember from the 3.1 or 3.2 versions that this was the only way to use apache for protecting jsp pages, but at least on 3.3 and 4.1.24 this worked also with simple .htaccess files. I have looked at my old configuration of 4.1.24 and could not find anything that would explain this, so I assume that this is indeed a bug or just a change in behaviour of the connector. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25130] New: - I think an error getting to the parsers! but the parser is in endorsed dir!
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=25130. 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=25130 I think an error getting to the parsers! but the parser is in endorsed dir! Summary: I think an error getting to the parsers! but the parser is in endorsed dir! Product: Tomcat 4 Version: 4.1.12 Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Major Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] java.lang.IllegalAccessError: class org.apache.xml.dtm.ref.sax2dtm.SAX2DTM2$Ance storIterator cannot access its superclass org.apache.xml.dtm.ref.DTMDefaultBaseI terators$InternalAxisIteratorBase at java.lang.ClassLoader.defineClass0(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:509) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:12 3) at java.net.URLClassLoader.defineClass(URLClassLoader.java:246) at java.net.URLClassLoader.access$100(URLClassLoader.java:54) at java.net.URLClassLoader$1.run(URLClassLoader.java:193) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:186) at org.apache.catalina.loader.StandardClassLoader.findClass(StandardClas sLoader.java:621) at org.apache.catalina.loader.StandardClassLoader.loadClass(StandardClas sLoader.java:958) at org.apache.catalina.loader.StandardClassLoader.loadClass(StandardClas sLoader.java:857) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:322) at org.apache.xalan.xsltc.dom.XSLTCDTMManager.getDTM(XSLTCDTMManager.jav a:291) at org.apache.xalan.xsltc.dom.XSLTCDTMManager.getDTM(XSLTCDTMManager.jav a:174) at org.apache.xalan.xsltc.trax.TransformerImpl.getDOM(TransformerImpl.ja va:516) at org.apache.xalan.xsltc.trax.TransformerImpl.transform(TransformerImpl .java:655) at org.apache.xalan.xsltc.trax.TransformerImpl.transform(TransformerImpl .java:298) at be.ikan.etl4all.transformation.TransformationEngine.run(Transformatio nEngine.java:324) at java.lang.Thread.run(Thread.java:536) java.lang.IllegalAccessError: class org.apache.xml.dtm.ref.sax2dtm.SAX2DTM2$Ance storIterator cannot access its superclass org.apache.xml.dtm.ref.DTMDefaultBaseI terators$InternalAxisIteratorBase at java.lang.ClassLoader.defineClass0(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:509) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:12 3) at java.net.URLClassLoader.defineClass(URLClassLoader.java:246) at java.net.URLClassLoader.access$100(URLClassLoader.java:54) at java.net.URLClassLoader$1.run(URLClassLoader.java:193) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:186) at org.apache.catalina.loader.StandardClassLoader.findClass(StandardClas sLoader.java:621) at org.apache.catalina.loader.StandardClassLoader.loadClass(StandardClas sLoader.java:958) at org.apache.catalina.loader.StandardClassLoader.loadClass(StandardClas sLoader.java:857) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:322) at org.apache.xalan.xsltc.dom.XSLTCDTMManager.getDTM(XSLTCDTMManager.jav a:291) at org.apache.xalan.xsltc.dom.XSLTCDTMManager.getDTM(XSLTCDTMManager.jav a:174) at org.apache.xalan.xsltc.trax.TransformerImpl.getDOM(TransformerImpl.ja va:516) at org.apache.xalan.xsltc.trax.TransformerImpl.transform(TransformerImpl .java:655) at org.apache.xalan.xsltc.trax.TransformerImpl.transform(TransformerImpl .java:298) at be.ikan.etl4all.transformation.TransformationEngine.run(Transformatio nEngine.java:324) at java.lang.Thread.run(Thread.java:536) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25133] New: - Cannot add responses headers in filter after doFilter
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=25133. 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=25133 Cannot add responses headers in filter after doFilter Summary: Cannot add responses headers in filter after doFilter Product: Tomcat 5 Version: 5.0.14 Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Major Priority: Other Component: Connector:Coyote AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I have a very simple filter that calls response.addHeader both before and after calling chain.doFilter. Before chaining the header is added, after chaining the header is not added. Also I cannot set the value of the header after chaining, or set a cookie. To see this failure Try this, browse to http://localhost:8080/index.jsp. For the page itself I see a 200 response and all my headers being set. For the gifs I get a 200 but only the headers I set *before* calling chain.doFilter are set. If I then refresh I get a 304 Not Modified response (for the gifs) from tomcat and all the headers are set! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25133] - Cannot add responses headers in filter after doFilter
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=25133. 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=25133 Cannot add responses headers in filter after doFilter [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2003-12-02 11:47 --- After the chain has been executed, the response was committed. Once the response is committed, no headers (which is what a cookie is) may be added. To get around this - you need to wrap the ServletOutputStream and buffer it to prevent it from being committed. There are many articles on the net about filters and wrappers. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25133] - Cannot add responses headers in filter after doFilter
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=25133. 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=25133 Cannot add responses headers in filter after doFilter --- Additional Comments From [EMAIL PROTECTED] 2003-12-02 12:11 --- Thanks Tim To get around this - you need to wrap the ServletOutputStream and buffer it to prevent it from being committed. There are many articles on the net about filters and wrappers. d'oh! and I've written a few of them so I should have realised this :) However, the response will have been committed after a 304 yet the headers are then set, so I would still regard this as a bug. I would think thet after returning from a doFilter, logically speaking, either the response is committed or it isn't. What was confusing to me is that I see the headers in one case but not in the other. I realise that a 304 contains no data, but logically it is a committed response - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25133] - Cannot add responses headers in filter after doFilter
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=25133. 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=25133 Cannot add responses headers in filter after doFilter --- Additional Comments From [EMAIL PROTECTED] 2003-12-02 12:40 --- No content is sent back on a 304. Only a header is sent to the client. With those situations, to response is not committed by the time doFilter() returns. Typically the response gets committed when the output buffer is full, but in the case of a 304 (and maybe very small files) it does not. The spec doesn't dictate exactly when (in time of request) the response is committed. If it did - then no one would be allowed to write XSL filters (or similar) to transform the response data after the previous link in the chain was executed. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25138] New: - [PATCH] Can't store web application context with admintool.
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=25138. 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=25138 [PATCH] Can't store web application context with admintool. Summary: [PATCH] Can't store web application context with admintool. Product: Tomcat 5 Version: Nightly Build Platform: All OS/Version: All Status: NEW Severity: Normal Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Admin tools have a following problem. When I change Application Context and store it's configuration with other than iso-8859-1, the configuration file ($CATALINA_HOME/conf/Catalina/localhost/*) would be broken. The cause is StandardServer don't open file with utf-8 neither write xml header encoding. I wrote patch for this problem. Please took following patch and fix problem until tomcat5 final release. http://yamaguch.sytes.net/~tora/tmp/StandardServer.java.1.22.diff regards, Takashi Okamoto - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 5.0.16
Remy Maucherat wrote: ballot Release 5.0.16 as Stable ? [X] Yes [ ] No /ballot I haven't found any regressions with this build :) Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25138] - [PATCH] Can't store web application context with admintool.
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=25138. 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=25138 [PATCH] Can't store web application context with admintool. --- Additional Comments From [EMAIL PROTECTED] 2003-12-02 15:17 --- I also encountered this issue. When I describe display-name in web.xml by UTF-8(or our native encoding), the admin tool copies it to $CATALINA_HOME/conf/Catalina/localhost/*.xml without the encoding specification. Finally, Tomcat fails to startup the context. Regards. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Tomcat 5 Issue (not 5.0.16 specific!)
First, I'd like to say that we should *not* consider the following issue as one to prevent a stable label for Tomcat 5.0.16. That said, I've noted that if you do: response.setContentLength( 0 ); All subsequent setHeader(), etc, calls are ignored -- Tomcat considers the response commited. Is this as per the spec? Or is this an odd corner case? [The fact that we have code that does a setContentLength(0) seems to be an odd corner case in and of itself... I've worked around this in our code by ensuring that this call is always made after all other headers are assigned.] -- Jess Holle
Re: Tomcat 5 Issue (not 5.0.16 specific!)
Section 5.5 of the spec: When a response is closed, the container must immediately flush all remaining content in the response buffer to the client. The following events indicate that the servlet has satisfied the request and that the response object is to be closed: The termination of the service method of the servlet. * The amount of content specified in the setContentLength method of the response has been written to the response. * The sendError method is called. The sendRedirect method is called. Looks like the behavior is OK. -Tim Jess Holle wrote: First, I'd like to say that we should *not* consider the following issue as one to prevent a stable label for Tomcat 5.0.16. That said, I've noted that if you do: response.setContentLength( 0 ); All subsequent setHeader(), etc, calls are ignored -- Tomcat considers the response commited. Is this as per the spec? Or is this an odd corner case? [The fact that we have code that does a setContentLength(0) seems to be an odd corner case in and of itself... I've worked around this in our code by ensuring that this call is always made after all other headers are assigned.] -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 Http11Processor.java
jfarcand2003/12/02 08:27:11
Modified:coyote/src/java/org/apache/coyote Request.java
ActionCode.java
catalina/src/share/org/apache/coyote/tomcat5
CoyoteRequest.java
http11/src/java/org/apache/coyote/http11
Http11Processor.java
Log:
Implement getLocalPort using ActionCode instead of getServerPort. Associate 1
ActionCode for each getXXX method.
Please review.
Revision ChangesPath
1.24 +11 -1
jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/Request.java
Index: Request.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/Request.java,v
retrieving revision 1.23
retrieving revision 1.24
diff -u -r1.23 -r1.24
--- Request.java 7 Sep 2003 18:03:21 - 1.23
+++ Request.java 2 Dec 2003 16:27:11 - 1.24
@@ -136,6 +136,7 @@
private String localHost;
private int remotePort;
+private int localPort;
private MessageBytes schemeMB = new MessageBytes();
@@ -303,7 +304,14 @@
public void setRemotePort(int port){
this.remotePort = port;
}
-
+
+public int getLocalPort(){
+return localPort;
+}
+
+public void setLocalPort(int port){
+this.localPort = port;
+}
// encoding/type
@@ -502,6 +510,8 @@
headers.recycle();
serverNameMB.recycle();
serverPort=-1;
+localPort = -1;
+remotePort = -1;
cookies.recycle();
parameters.recycle();
1.14 +17 -0
jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/ActionCode.java
Index: ActionCode.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/ActionCode.java,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -r1.13 -r1.14
--- ActionCode.java 1 Oct 2003 07:50:29 - 1.13
+++ ActionCode.java 2 Dec 2003 16:27:11 - 1.14
@@ -135,7 +135,24 @@
* (including forcing a re-handshake if necessary)
*/
public static final ActionCode ACTION_REQ_SSL_CERTIFICATE = new ActionCode(15);
+
+
+/**
+ * Callback for lazy evaluation - socket remote port.
+ **/
+public static final ActionCode ACTION_REQ_REMOTEPORT_ATTRIBUTE = new
ActionCode(16);
+
+/**
+ * Callback for lazy evaluation - socket local port.
+ **/
+public static final ActionCode ACTION_REQ_LOCALPORT_ATTRIBUTE = new
ActionCode(17);
+
+
+/**
+ * Callback for lazy evaluation - local address.
+ **/
+public static final ActionCode ACTION_REQ_LOCAL_ADDR_ATTRIBUTE = new
ActionCode(18);
// --- Constructors
int code;
1.24 +23 -7
jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5/CoyoteRequest.java
Index: CoyoteRequest.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5/CoyoteRequest.java,v
retrieving revision 1.23
retrieving revision 1.24
diff -u -r1.23 -r1.24
--- CoyoteRequest.java20 Nov 2003 20:56:28 - 1.23
+++ CoyoteRequest.java2 Dec 2003 16:27:11 - 1.24
@@ -366,6 +366,11 @@
/**
+ * Local port
+ */
+protected int localPort = -1;
+
+/**
* Remote address.
*/
protected String remoteAddr = null;
@@ -420,6 +425,7 @@
remoteAddr = null;
remoteHost = null;
remotePort = -1;
+localPort = -1;
localAddr = null;
attributes.clear();
@@ -646,6 +652,7 @@
remoteHost = null;
remoteAddr = null;
remotePort = -1;
+localPort = -1;
localAddr = null;
}
@@ -1236,7 +1243,7 @@
remotePort = socket.getPort();
} else {
coyoteRequest.action
-(ActionCode.ACTION_REQ_HOST_ATTRIBUTE, coyoteRequest);
+(ActionCode.ACTION_REQ_REMOTEPORT_ATTRIBUTE, coyoteRequest);
remotePort = coyoteRequest.getRemotePort();
}
}
@@ -1262,7 +1269,7 @@
localAddr = inet.getHostAddress();
} else {
coyoteRequest.action
-(ActionCode.ACTION_REQ_HOST_ATTRIBUTE, coyoteRequest);
+(ActionCode.ACTION_REQ_LOCAL_ADDR_ATTRIBUTE, coyoteRequest);
Re: Tomcat 5 Issue (not 5.0.16 specific!)
Tim Funk wrote: Section 5.5 of the spec: When a response is closed, the container must immediately flush all remaining content in the response buffer to the client. The following events indicate that the servlet has satisfied the request and that the response object is to be closed: The termination of the service method of the servlet. * The amount of content specified in the setContentLength method of the response has been written to the response. * That's what I figured. I'm just a bit uncertain about the corner/end case where nothing is to be written to the response, i.e. for a content-length of 0. The sendError method is called. The sendRedirect method is called. Looks like the behavior is OK. I was kind of guessing this was to the letter of the spec -- I'm fine with my changes (which would not have been necessary but for some old mechanisms which produce a hash of headers and toss them at code which simply spits them at the response in hash order -- with a few special cases to use more specific methods where possible). -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] 5.0.16
Howdy, ballot Release 5.0.16 as Stable ? [ X ] Yes [ ] No /ballot Did my usual tests: examples, my applications (and their cactus/junit tests), manager webapp, links, docs, balancer. Yoav Shapira 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: [VOTE] 5.0.16
Shapira, Yoav wrote: Howdy, ballot Release 5.0.16 as Stable ? [ X ] Yes [ ] No /ballot Did my usual tests: examples, my applications (and their cactus/junit tests), manager webapp, links, docs, balancer. Since I have the required three votes, I'll move the binaries later today so they can be replicated before an official announcement is made. I'll pull them if there's a problem (somehow). Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Minimal server.xml
Hi, IMHO the server.xml that comes with tomcat by default ($CATALINA_HOME/conf/server.xml) is nice in that it provides many comments and examples. But I think power users would appreciate a minimal version as well, so I've created one, as shown below. Should we distribute something like this, perhaps as $CATALINA_HOME/conf/server-minimal.xml? Server port=8005 shutdown=SHUTDOWN debug=0 Service name=Catalina Connector port=8080 maxThreads=150 minSpareThreads=1 maxSpareThreads=75 enableLookups=false redirectPort=8443 acceptCount=100 debug=0 connectionTimeout=2 disableUploadTimeout=true / Engine name=Catalina defaultHost=localhost debug=0 Logger className=org.apache.catalina.logger.FileLogger prefix=catalina_log. suffix=.txt timestamp=true/ Host name=localhost debug=0 appBase=webapps unpackWARs=true autoDeploy=true xmlValidation=false xmlNamespaceAware=false Logger className=org.apache.catalina.logger.FileLogger directory=logs prefix=localhost_log. suffix=.txt timestamp=true/ /Host /Engine /Service /Server Yoav Shapira Millennium ChemInformatics 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: Minimal server.xml
Sounds like a good idea to me. I would recommend removing the Logger and just letting the output go into catalina.out -bob On Tue, 2003-12-02 at 12:18, Shapira, Yoav wrote: Hi, IMHO the server.xml that comes with tomcat by default ($CATALINA_HOME/conf/server.xml) is nice in that it provides many comments and examples. But I think power users would appreciate a minimal version as well, so I've created one, as shown below. Should we distribute something like this, perhaps as $CATALINA_HOME/conf/server-minimal.xml? Server port=8005 shutdown=SHUTDOWN debug=0 Service name=Catalina Connector port=8080 maxThreads=150 minSpareThreads=1 maxSpareThreads=75 enableLookups=false redirectPort=8443 acceptCount=100 debug=0 connectionTimeout=2 disableUploadTimeout=true / Engine name=Catalina defaultHost=localhost debug=0 Logger className=org.apache.catalina.logger.FileLogger prefix=catalina_log. suffix=.txt timestamp=true/ Host name=localhost debug=0 appBase=webapps unpackWARs=true autoDeploy=true xmlValidation=false xmlNamespaceAware=false Logger className=org.apache.catalina.logger.FileLogger directory=logs prefix=localhost_log. suffix=.txt timestamp=true/ /Host /Engine /Service /Server Yoav Shapira Millennium ChemInformatics 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Minimal server.xml
+1 You can also remove the xmlValidation=false xmlNamespaceAware=false, since they are optionals. -- Jeanfrancois Shapira, Yoav wrote: Hi, IMHO the server.xml that comes with tomcat by default ($CATALINA_HOME/conf/server.xml) is nice in that it provides many comments and examples. But I think power users would appreciate a minimal version as well, so I've created one, as shown below. Should we distribute something like this, perhaps as $CATALINA_HOME/conf/server-minimal.xml? Server port=8005 shutdown=SHUTDOWN debug=0 Service name=Catalina Connector port=8080 maxThreads=150 minSpareThreads=1 maxSpareThreads=75 enableLookups=false redirectPort=8443 acceptCount=100 debug=0 connectionTimeout=2 disableUploadTimeout=true / Engine name=Catalina defaultHost=localhost debug=0 Logger className=org.apache.catalina.logger.FileLogger prefix=catalina_log. suffix=.txt timestamp=true/ Host name=localhost debug=0 appBase=webapps unpackWARs=true autoDeploy=true xmlValidation=false xmlNamespaceAware=false Logger className=org.apache.catalina.logger.FileLogger directory=logs prefix=localhost_log. suffix=.txt timestamp=true/ /Host /Engine /Service /Server Yoav Shapira Millennium ChemInformatics 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 Http11Processor.java
Remy Maucherat wrote: [EMAIL PROTECTED] wrote: jfarcand2003/12/02 08:27:11 Modified:coyote/src/java/org/apache/coyote Request.java ActionCode.java catalina/src/share/org/apache/coyote/tomcat5 CoyoteRequest.java http11/src/java/org/apache/coyote/http11 Http11Processor.java Log: Implement getLocalPort using ActionCode instead of getServerPort. Associate 1 ActionCode for each getXXX method. Please review. I'll have to vote -0 for implementing getLocalPort as mandated in the specification, since I think this is a huge mistake, and the spec authors intention is misinterpreted (or they didn't think about all the consequences of the wording they used, thinking only about the case of a server without any proxies, or using an AJP-like scheme). BTW, I also think your patch has a sky high likelihood of breaking the JK 2 connector ;-) Can you explain how? The only changes I did was to remove the code associated with remoteAddr (which was duplicated and useless IMO). I said it would be ok, yesterday, but I changed my mind, as this looks wrong. If Bill votes -1 to this, I'll change my vote to -1. I should start reverting my patch ;-) The problem is that this call is likely intended to allow users to build URLs to the server. Actually, this won't work, since the server may not be accessible with the connector hostname or port. What actually should be returned is what is in the Host header (HTTP/1.0 is a broken spec, since it can't possibly work when behind a reverse proxy). Otherwise, we're returning completely useless information to the user, and the getLocalPort is simply useless. Make sense.That will also apply to LocalAddr too then. What the specs states is: public java.lang.String getLocalAddr() Returns the Internet Protocol (IP) address of the interface on which the request was received. public int getLocalPort() Returns the Internet Protocol (IP) port number of the interface on which the request was received. I think parsing/using the Host header is the way to go, since it will work with/without proxy. Can I -1 on myself ;-) -- Jeanfrancois Note: Compliant HTTP/1.1 clients must send correct Host header, and proxy servers are not allowed to modify them. Rémy - 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: cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 Http11Processor.java
Jeanfrancois Arcand wrote: Remy Maucherat wrote: [EMAIL PROTECTED] wrote: jfarcand2003/12/02 08:27:11 Modified:coyote/src/java/org/apache/coyote Request.java ActionCode.java catalina/src/share/org/apache/coyote/tomcat5 CoyoteRequest.java http11/src/java/org/apache/coyote/http11 Http11Processor.java Log: Implement getLocalPort using ActionCode instead of getServerPort. Associate 1 ActionCode for each getXXX method. Please review. I'll have to vote -0 for implementing getLocalPort as mandated in the specification, since I think this is a huge mistake, and the spec authors intention is misinterpreted (or they didn't think about all the consequences of the wording they used, thinking only about the case of a server without any proxies, or using an AJP-like scheme). BTW, I also think your patch has a sky high likelihood of breaking the JK 2 connector ;-) Can you explain how? The only changes I did was to remove the code associated with remoteAddr (which was duplicated and useless IMO). I don't see how JK would set the localPort field (since the new action isn't handled yet), so I thought it would always return -1. Maybe I'm wrong, I didn't try it. Make sense.That will also apply to LocalAddr too then. What the specs states is: public java.lang.String getLocalAddr() Returns the Internet Protocol (IP) address of the interface on which the request was received. public int getLocalPort() Returns the Internet Protocol (IP) port number of the interface on which the request was received. I think parsing/using the Host header is the way to go, since it will work with/without proxy. Can I -1 on myself ;-) I don't know, maybe you can talk to the Servlet spec people first to see what they have to say on this issue ? Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25146] New: - Use setCharacterEncoding() does not change parameters encoding
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=25146. 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=25146 Use setCharacterEncoding() does not change parameters encoding Summary: Use setCharacterEncoding() does not change parameters encoding Product: Tomcat 4 Version: 4.1.29 Platform: PC OS/Version: Linux Status: NEW Severity: Critical Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I set encoding in filter using setCharacterEncoding(). But when i call getParameter() parameter retun not encoded. In 4.1.12 version all work fine. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/conf server-minimal.xml
yoavs 2003/12/02 10:16:19 Added: catalina/src/conf server-minimal.xml Log: Initial version. Revision ChangesPath 1.1 jakarta-tomcat-catalina/catalina/src/conf/server-minimal.xml Index: server-minimal.xml === Server port=8005 shutdown=SHUTDOWN Service name=Catalina Connector port=8080 / Engine name=Catalina defaultHost=localhost Logger className=org.apache.catalina.logger.FileLogger / Host name=localhost appBase=webapps / /Engine /Service /Server - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25146] - Use setCharacterEncoding() does not change parameters encoding
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=25146. 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=25146 Use setCharacterEncoding() does not change parameters encoding --- Additional Comments From [EMAIL PROTECTED] 2003-12-02 18:28 --- May be something wrong in org.apache.tomcat.util.buf.UDecoder. Function public void convert( CharChunk mb, boolean query ) not use encoding, and cannot correctly work with 2-byte encodings - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 Http11Processor.java
Remy Maucherat wrote: [...] Now the big question is actually what the new getLocalPort call should return. If you need an extra localPort (and its friend getLocalName - did you notice the getLocalName() call was always returning whatever hostname was in the host header) field in the request because it doesn't correspond to vhosting (I consider it would be yet another major blunder of the Servlet spec, but what can I do ...), then so be it. The getLocalXXX() methods are intended to provide information about where the request was _recieved_ by the container, rather than where it was _sent_ by the client, which is useful information for some types of applications, for instance to detect if there's any vhosting involved. So you have three sets of methods for getting address/port info. * Where the request was received (server socket): getLocalName() getLocalPort() getLocalAddr() * Where the request was sent (Host header info): getServerName() getServerPort() * Where the request comes from (client socket): getRemoteName() getRemotePort() getRemoteAddr() With an HTTP/1.1 request with a Host header foo.com value, proxied through Apache to Tomcat listening on port 8005, from a client (or a proxy) at 4.62.132.17 (bar.com) port 1766, the methods should return these values: getLocalName() - localhost (or some other local interface) getLocalPort() - 8005 getLocalAddr() - 127.0.0.1 (or some other local interface) getServerName() - foo.com getServerPort() - 80 getRemoteName() - bar.com getRemotePort() - 1766 getRemoteAddr() - 4.62.132.17 Without proxying through Apache, a Host header localhost:8080 value and Tomcat listening on port 8080, it would look like this instead: getLocalName() - localhost getLocalPort() - 8080 getLocalAddr() - 127.0.0.1 getServerName() - localhost getServerPort() - 8080 getRemoteName() - bar.com getRemotePort() - 1766 getRemoteAddr() - 4.62.132.17 HTH, Hans -- Hans Bergsten[EMAIL PROTECTED] Gefion Software http://www.gefionsoftware.com/ Author of O'Reilly's JavaServer Pages, covering JSP 2.0 and JSTL 1.1 Details athttp://TheJSPBook.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 Http11Processor.java
- Original Message - From: Remy Maucherat [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Tuesday, December 02, 2003 8:59 AM Subject: Re: cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 Http11Processor.java [EMAIL PROTECTED] wrote: jfarcand2003/12/02 08:27:11 Modified:coyote/src/java/org/apache/coyote Request.java ActionCode.java catalina/src/share/org/apache/coyote/tomcat5 CoyoteRequest.java http11/src/java/org/apache/coyote/http11 Http11Processor.java Log: Implement getLocalPort using ActionCode instead of getServerPort. Associate 1 ActionCode for each getXXX method. Please review. I'll have to vote -0 for implementing getLocalPort as mandated in the specification, since I think this is a huge mistake, and the spec authors intention is misinterpreted (or they didn't think about all the consequences of the wording they used, thinking only about the case of a server without any proxies, or using an AJP-like scheme). BTW, I also think your patch has a sky high likelihood of breaking the JK 2 connector ;-) I said it would be ok, yesterday, but I changed my mind, as this looks wrong. If Bill votes -1 to this, I'll change my vote to -1. I'm fine with the patch (although not a great fan of getLocalPort :). The problem is that this call is likely intended to allow users to build URLs to the server. Actually, this won't work, since the server may not be accessible with the connector hostname or port. What actually should be returned is what is in the Host header (HTTP/1.0 is a broken spec, since it can't possibly work when behind a reverse proxy). Otherwise, we're returning completely useless information to the user, and the getLocalPort is simply useless. Users should be using getServerPort to build URLs to the server. The problem with yesterdays patch is that it broke getServerPort (which is defined to be the value of the Host header). I agree that getLocalPort is simply useless, but it's in the spec so we have to implement it :). About the only thing that it is good for is to grant rights to requests coming in on one connector, but not on another (which points to a bad design). Note: Compliant HTTP/1.1 clients must send correct Host header, and proxy servers are not allowed to modify them. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 Http11Processor.java
- Original Message - From: Remy Maucherat [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Tuesday, December 02, 2003 9:47 AM Subject: Re: cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 Http11Processor.java Jeanfrancois Arcand wrote: Remy Maucherat wrote: [EMAIL PROTECTED] wrote: jfarcand2003/12/02 08:27:11 Modified:coyote/src/java/org/apache/coyote Request.java ActionCode.java catalina/src/share/org/apache/coyote/tomcat5 CoyoteRequest.java http11/src/java/org/apache/coyote/http11 Http11Processor.java Log: Implement getLocalPort using ActionCode instead of getServerPort. Associate 1 ActionCode for each getXXX method. Please review. I'll have to vote -0 for implementing getLocalPort as mandated in the specification, since I think this is a huge mistake, and the spec authors intention is misinterpreted (or they didn't think about all the consequences of the wording they used, thinking only about the case of a server without any proxies, or using an AJP-like scheme). BTW, I also think your patch has a sky high likelihood of breaking the JK 2 connector ;-) Can you explain how? The only changes I did was to remove the code associated with remoteAddr (which was duplicated and useless IMO). I don't see how JK would set the localPort field (since the new action isn't handled yet), so I thought it would always return -1. Maybe I'm wrong, I didn't try it. Yes, the JK connector is going to need some changes to support this. However they should be pretty minor. Make sense.That will also apply to LocalAddr too then. What the specs states is: public java.lang.String getLocalAddr() Returns the Internet Protocol (IP) address of the interface on which the request was received. public int getLocalPort() Returns the Internet Protocol (IP) port number of the interface on which the request was received. I think parsing/using the Host header is the way to go, since it will work with/without proxy. Can I -1 on myself ;-) I don't know, maybe you can talk to the Servlet spec people first to see what they have to say on this issue ? Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 Http11Processor.java
Hans Bergsten wrote: Remy Maucherat wrote: [...] Now the big question is actually what the new getLocalPort call should return. If you need an extra localPort (and its friend getLocalName - did you notice the getLocalName() call was always returning whatever hostname was in the host header) field in the request because it doesn't correspond to vhosting (I consider it would be yet another major blunder of the Servlet spec, but what can I do ...), then so be it. The getLocalXXX() methods are intended to provide information about where the request was _recieved_ by the container, rather than where it was _sent_ by the client, which is useful information for some types of applications, for instance to detect if there's any vhosting involved. So you have three sets of methods for getting address/port info. * Where the request was received (server socket): getLocalName() getLocalPort() getLocalAddr() * Where the request was sent (Host header info): getServerName() getServerPort() * Where the request comes from (client socket): getRemoteName() getRemotePort() getRemoteAddr() With an HTTP/1.1 request with a Host header foo.com value, proxied through Apache to Tomcat listening on port 8005, from a client (or a proxy) at 4.62.132.17 (bar.com) port 1766, the methods should return these values: getLocalName() - localhost (or some other local interface) getLocalPort() - 8005 getLocalAddr() - 127.0.0.1 (or some other local interface) getServerName() - foo.com getServerPort() - 80 getRemoteName() - bar.com getRemotePort() - 1766 getRemoteAddr() - 4.62.132.17 Without proxying through Apache, a Host header localhost:8080 value and Tomcat listening on port 8080, it would look like this instead: getLocalName() - localhost getLocalPort() - 8080 getLocalAddr() - 127.0.0.1 getServerName() - localhost getServerPort() - 8080 getRemoteName() - bar.com getRemotePort() - 1766 getRemoteAddr() - 4.62.132.17 Then today's commit implemented that behaviour except for getLocalName(0 which is still broken.Will fix it). Before getLocalPort() was calling getServerPort() (my mistake back in 03/05). I think the spec should be clarified with an example like this one ;-) Thanks for the clarification. -- Jeanfrancois HTH, Hans - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25148] New: - JDBCRealm should get the user name from database after login and not use the string given by the user
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=25148. 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=25148 JDBCRealm should get the user name from database after login and not use the string given by the user Summary: JDBCRealm should get the user name from database after login and not use the string given by the user Product: Tomcat 4 Version: 4.1.29 Platform: All OS/Version: All Status: NEW Severity: Enhancement Priority: Other Component: Unknown AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] The user_name column of my users table is case insensitive, so users do not need to remember the case of their name (Am I User or user?). The downside: request.getRemoteUser() always reflects the spelling used to log in, not the spelling contained in the database. In order to get the correct spelling, I have to SELECT user_name FROM users WHERE user_name = ? each time I want to process the user name. My suggestion is to also fetch the user name with the SELECT needed to get the password when logging in. This shouldn't be of much impact, because the SELECT statement is needed anyway, there is just one more column to transfer. JDBCRealm should pass the name stored in the database when queried for the name to return with request.getRemoteUser(). Regards, Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 Http11Processor.java
jfarcand2003/12/02 15:01:01
Modified:coyote/src/java/org/apache/coyote Request.java
ActionCode.java
catalina/src/share/org/apache/coyote/tomcat5
CoyoteRequest.java
http11/src/java/org/apache/coyote/http11
Http11Processor.java
Log:
Add proper getLocalName implementation.
Please review
Revision ChangesPath
1.25 +5 -1
jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/Request.java
Index: Request.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/Request.java,v
retrieving revision 1.24
retrieving revision 1.25
diff -u -r1.24 -r1.25
--- Request.java 2 Dec 2003 16:27:11 - 1.24
+++ Request.java 2 Dec 2003 23:01:00 - 1.25
@@ -149,7 +149,7 @@
// remote address/host
private MessageBytes remoteAddrMB = new MessageBytes();
-private MessageBytes localAddr = new MessageBytes();
+private MessageBytes localNameMB = new MessageBytes();
private MessageBytes remoteHostMB = new MessageBytes();
private MessageBytes localAddrMB = new MessageBytes();
@@ -284,6 +284,10 @@
public MessageBytes remoteHost() {
return remoteHostMB;
}
+
+public MessageBytes localName() {
+ return localNameMB;
+}
public MessageBytes localAddr() {
return localAddrMB;
1.15 +6 -0
jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/ActionCode.java
Index: ActionCode.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/ActionCode.java,v
retrieving revision 1.14
retrieving revision 1.15
diff -u -r1.14 -r1.15
--- ActionCode.java 2 Dec 2003 16:27:11 - 1.14
+++ ActionCode.java 2 Dec 2003 23:01:00 - 1.15
@@ -153,6 +153,12 @@
* Callback for lazy evaluation - local address.
**/
public static final ActionCode ACTION_REQ_LOCAL_ADDR_ATTRIBUTE = new
ActionCode(18);
+
+
+/**
+ * Callback for lazy evaluation - local address.
+ **/
+public static final ActionCode ACTION_REQ_LOCAL_NAME_ATTRIBUTE = new
ActionCode(19);
// --- Constructors
int code;
1.25 +23 -5
jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5/CoyoteRequest.java
Index: CoyoteRequest.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5/CoyoteRequest.java,v
retrieving revision 1.24
retrieving revision 1.25
diff -u -r1.24 -r1.25
--- CoyoteRequest.java2 Dec 2003 16:27:11 - 1.24
+++ CoyoteRequest.java2 Dec 2003 23:01:01 - 1.25
@@ -391,7 +391,13 @@
* Local address
*/
protected String localAddr = null;
+
+/**
+ * Local address
+ */
+protected String localName = null;
+
/** After the request is mapped to a ServletContext, we can also
* map it to a logger.
*/
@@ -427,6 +433,7 @@
remotePort = -1;
localPort = -1;
localAddr = null;
+localName = null;
attributes.clear();
notes.clear();
@@ -654,6 +661,7 @@
remotePort = -1;
localPort = -1;
localAddr = null;
+localName = null;
}
@@ -1255,7 +1263,17 @@
* which the request was received.
*/
public String getLocalName(){
-return getServerName();
+if (localName == null) {
+if (socket != null) {
+InetAddress inet = socket.getLocalAddress();
+localAddr = inet.getHostName();
+} else {
+coyoteRequest.action
+(ActionCode.ACTION_REQ_LOCAL_NAME_ATTRIBUTE, coyoteRequest);
+localName = coyoteRequest.localName().toString();
+}
+}
+return localName;
}
/**
1.92 +21 -2
jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/Http11Processor.java
Index: Http11Processor.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/Http11Processor.java,v
retrieving revision 1.91
retrieving revision 1.92
diff -u -r1.91 -r1.92
--- Http11Processor.java 2 Dec 2003 16:27:11 - 1.91
+++ Http11Processor.java 2 Dec 2003 23:01:01 - 1.92
@@ -239,9 +239,17 @@
* Remote
Re: cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 Http11Processor.java
Hans Bergsten wrote: Remy Maucherat wrote: [...] Now the big question is actually what the new getLocalPort call should return. If you need an extra localPort (and its friend getLocalName - did you notice the getLocalName() call was always returning whatever hostname was in the host header) field in the request because it doesn't correspond to vhosting (I consider it would be yet another major blunder of the Servlet spec, but what can I do ...), then so be it. The getLocalXXX() methods are intended to provide information about where the request was _recieved_ by the container, rather than where it was _sent_ by the client, which is useful information for some types of applications, for instance to detect if there's any vhosting involved. So proxying would be detected as vhosting. I think it would indicate if the server is a pure standalone server, but that's it. So you have three sets of methods for getting address/port info. * Where the request was received (server socket): getLocalName() getLocalPort() getLocalAddr() * Where the request was sent (Host header info): getServerName() getServerPort() * Where the request comes from (client socket): getRemoteName() getRemotePort() getRemoteAddr() With an HTTP/1.1 request with a Host header foo.com value, proxied through Apache to Tomcat listening on port 8005, from a client (or a proxy) at 4.62.132.17 (bar.com) port 1766, the methods should return these values: getLocalName() - localhost (or some other local interface) getLocalPort() - 8005 getLocalAddr() - 127.0.0.1 (or some other local interface) getServerName() - foo.com getServerPort() - 80 getRemoteName() - bar.com getRemotePort() - 1766 getRemoteAddr() - 4.62.132.17 Without proxying through Apache, a Host header localhost:8080 value and Tomcat listening on port 8080, it would look like this instead: getLocalName() - localhost getLocalPort() - 8080 getLocalAddr() - 127.0.0.1 getServerName() - localhost getServerPort() - 8080 getRemoteName() - bar.com getRemotePort() - 1766 getRemoteAddr() - 4.62.132.17 This will likely confuse users a bit. If it's as intended, then fine :) Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/jk/common HandlerRequest.java
billbarker2003/12/02 21:37:42
Modified:jk/java/org/apache/jk/common HandlerRequest.java
Log:
Fix JkCoyote to properly handle the distinction between localName/Port and
serverName/Port.
As always with mod_jk, you can lose strict Servlet-Spec compliance by playing with
your Apache settings. However if ConnonicalName=on or DNS, then this is correct. If
it's not, then you obviously don't want this to be correct ;-). It also seems to be
the value that IIS is sending.
Thanks to Remy for his great parseHost routine (which I had to modify slightly,
because of design differences in JkCoyote and HTTP11Coyote).
Revision ChangesPath
1.29 +144 -60
jakarta-tomcat-connectors/jk/java/org/apache/jk/common/HandlerRequest.java
Index: HandlerRequest.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/jk/java/org/apache/jk/common/HandlerRequest.java,v
retrieving revision 1.28
retrieving revision 1.29
diff -u -r1.28 -r1.29
--- HandlerRequest.java 16 Oct 2003 07:37:32 - 1.28
+++ HandlerRequest.java 3 Dec 2003 05:37:42 - 1.29
@@ -62,6 +62,7 @@
import java.io.File;
import java.io.FileOutputStream;
import java.io.IOException;
+import java.io.CharConversionException;
import java.net.InetAddress;
import java.util.Properties;
@@ -75,6 +76,8 @@
import org.apache.jk.core.MsgContext;
import org.apache.jk.core.WorkerEnv;
import org.apache.tomcat.util.buf.ByteChunk;
+import org.apache.tomcat.util.buf.CharChunk;
+import org.apache.tomcat.util.buf.HexUtils;
import org.apache.tomcat.util.buf.MessageBytes;
import org.apache.tomcat.util.http.MimeHeaders;
import org.apache.tomcat.util.net.SSLSupport;
@@ -109,16 +112,16 @@
// Prefix codes for message types from server to container
public static final byte JK_AJP13_FORWARD_REQUEST = 2;
- public static final byte JK_AJP13_SHUTDOWN = 7;
- public static final byte JK_AJP13_PING_REQUEST = 8;
- public static final byte JK_AJP13_CPING_REQUEST = 10;
+public static final byte JK_AJP13_SHUTDOWN = 7;
+public static final byte JK_AJP13_PING_REQUEST = 8;
+public static final byte JK_AJP13_CPING_REQUEST = 10;
// Prefix codes for message types from container to server
public static final byte JK_AJP13_SEND_BODY_CHUNK = 3;
public static final byte JK_AJP13_SEND_HEADERS = 4;
public static final byte JK_AJP13_END_RESPONSE = 5;
- public static final byte JK_AJP13_GET_BODY_CHUNK= 6;
- public static final byte JK_AJP13_CPONG_REPLY = 9;
+public static final byte JK_AJP13_GET_BODY_CHUNK= 6;
+public static final byte JK_AJP13_CPONG_REPLY = 9;
// Integer codes for common response header strings
public static final int SC_RESP_CONTENT_TYPE= 0xA001;
@@ -132,7 +135,7 @@
public static final int SC_RESP_SERVLET_ENGINE = 0xA009;
public static final int SC_RESP_STATUS = 0xA00A;
public static final int SC_RESP_WWW_AUTHENTICATE= 0xA00B;
-
+
// Integer codes for common (optional) request attribute names
public static final byte SC_A_CONTEXT = 1; // XXX Unused
public static final byte SC_A_SERVLET_PATH = 2; // XXX Unused
@@ -219,6 +222,11 @@
user-agent
};
+/*
+ * Note for Host parsing.
+ */
+public static final int HOSTBUFFER = 10;
+
HandlerDispatch dispatch;
String ajpidDir=conf;
@@ -239,9 +247,9 @@
JK_AJP13_SHUTDOWN,
this, null); // 7
- dispatch.registerMessageType( JK_AJP13_CPING_REQUEST,
-
JK_AJP13_CPING_REQUEST,
-
this, null); // 10
+dispatch.registerMessageType( JK_AJP13_CPING_REQUEST,
+
JK_AJP13_CPING_REQUEST,
+
this, null); // 10
// register outgoing messages handler
dispatch.registerMessageType( JK_AJP13_SEND_BODY_CHUNK, // 3
@@ -272,7 +280,7 @@
}
public void setDecodedUri( boolean b ) {
- decoded=b;
+decoded=b;
}
public boolean isTomcatAuthentication() {
@@ -422,21 +430,21 @@
log.info(Exiting);
System.exit(0);
- return OK;
+return OK;
- // We got a
DO NOT REPLY [Bug 25138] - [PATCH] Can't store web application context with admintool.
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=25138. 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=25138 [PATCH] Can't store web application context with admintool. --- Additional Comments From [EMAIL PROTECTED] 2003-12-03 05:44 --- In StandardServer.java, storeResources method has already been fixed as changes that Okamoto- san proposed. The storeContext method should also be fixed ASAP. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Need installation of Tomcat jakarta-tomcat-5.0.12 on Windows 98 - How to proceed?
- Do you Yahoo!? Free Pop-Up Blocker - Get it now
