Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core ApplicationHttpResponse.java
[EMAIL PROTECTED] wrote: luehe 2004/10/14 17:00:35 Modified:catalina/src/share/org/apache/catalina/core ApplicationHttpResponse.java Log: Expose any errors on an included resource. For example, a JSP with this include action: jsp:include page=nonexistent or jsp:include page=nonexistent.jsp where nonexistent[.jsp] does not exist, currently returns silently, hiding the fact that the resource to be included does not exist. This patch returns a 404 with the name of the nonexistent resource. Yes, SRV.8.3 (The Include Method) mentions that it [the target servlet] cannot set headers or call any method that affects the headers of the response. Any attempt to do so must be ignored. but i don't think it is referring to the error case. Let me know if you see any problems. Same as Bill. It would be logical that it refers to the whole HTTP header(all of its elements already are), since the idea is that it might already have been sent. It's true that we have no good way of reporting problems when including. This has always been a problem from a user perspective. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core ApplicationHttpResponse.java
The HTTP response to the user should reflect their request to the named resource. If the user-requested JSP was found, then a 404 Not Found is not an appropriate response, the resource requested was found. If the server is unable to properly form a response, because some component/resource referenced by the user-requested resource is missing/unavailable/exceptioned/whatever, then the server has experienced an error processing the request, and a better response would be 500 Internal Server Error. -Mitchell Fisher -Original Message- From: Remy Maucherat [mailto:[EMAIL PROTECTED] Sent: Friday, October 15, 2004 4:46 AM To: Tomcat Developers List Subject: Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core ApplicationHttpResponse.java [EMAIL PROTECTED] wrote: luehe 2004/10/14 17:00:35 Modified:catalina/src/share/org/apache/catalina/core ApplicationHttpResponse.java Log: Expose any errors on an included resource. For example, a JSP with this include action: jsp:include page=nonexistent or jsp:include page=nonexistent.jsp where nonexistent[.jsp] does not exist, currently returns silently, hiding the fact that the resource to be included does not exist. This patch returns a 404 with the name of the nonexistent resource. Yes, SRV.8.3 (The Include Method) mentions that it [the target servlet] cannot set headers or call any method that affects the headers of the response. Any attempt to do so must be ignored. but i don't think it is referring to the error case. Let me know if you see any problems. Same as Bill. It would be logical that it refers to the whole HTTP header(all of its elements already are), since the idea is that it might already have been sent. It's true that we have no good way of reporting problems when including. This has always been a problem from a user perspective. 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-catalina/catalina/src/share/org/apache/catalina/core ApplicationHttpResponse.java
Remy/Bill, Remy Maucherat wrote: [EMAIL PROTECTED] wrote: luehe 2004/10/14 17:00:35 Modified:catalina/src/share/org/apache/catalina/core ApplicationHttpResponse.java Log: Expose any errors on an included resource. For example, a JSP with this include action: jsp:include page=nonexistent or jsp:include page=nonexistent.jsp where nonexistent[.jsp] does not exist, currently returns silently, hiding the fact that the resource to be included does not exist. This patch returns a 404 with the name of the nonexistent resource. Yes, SRV.8.3 (The Include Method) mentions that it [the target servlet] cannot set headers or call any method that affects the headers of the response. Any attempt to do so must be ignored. but i don't think it is referring to the error case. Let me know if you see any problems. Same as Bill. It would be logical that it refers to the whole HTTP header(all of its elements already are), since the idea is that it might already have been sent. I agree the above section needs to be clarified. It's true that we have no good way of reporting problems when including. This has always been a problem from a user perspective. OK, do you think it would be a better idea to return a null RequestDispatcher in this case? In ApplicationContext.getRequestDispatcher(path), we could check if the wrapper that the given path is being mapped to corresponds to the JspServlet or DefaultServlet, and only in that case, call getResource() to make sure the requested resource actually exists. If it doesn't, return null. I really don't like the idea of not reporting anything to the user. Jan 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-catalina/catalina/src/share/org/apache/catalina/core ApplicationHttpResponse.java
Jan Luehe wrote: Remy/Bill, Remy Maucherat wrote: [EMAIL PROTECTED] wrote: luehe 2004/10/14 17:00:35 Modified:catalina/src/share/org/apache/catalina/core ApplicationHttpResponse.java Log: Expose any errors on an included resource. For example, a JSP with this include action: jsp:include page=nonexistent or jsp:include page=nonexistent.jsp where nonexistent[.jsp] does not exist, currently returns silently, hiding the fact that the resource to be included does not exist. This patch returns a 404 with the name of the nonexistent resource. Yes, SRV.8.3 (The Include Method) mentions that it [the target servlet] cannot set headers or call any method that affects the headers of the response. Any attempt to do so must be ignored. but i don't think it is referring to the error case. Let me know if you see any problems. Same as Bill. It would be logical that it refers to the whole HTTP header(all of its elements already are), since the idea is that it might already have been sent. I agree the above section needs to be clarified. It's true that we have no good way of reporting problems when including. This has always been a problem from a user perspective. OK, do you think it would be a better idea to return a null RequestDispatcher in this case? In ApplicationContext.getRequestDispatcher(path), we could check if the wrapper that the given path is being mapped to corresponds to the JspServlet or DefaultServlet, and only in that case, call getResource() to make sure the requested resource actually exists. If it doesn't, return null. That's IMO well beyond the spec. I really don't like the idea of not reporting anything to the user. OTOH, I don't see anything which prevents the default servlet from reporting such an error as plain text This resource foo is not found when invoked from an include, which would likely be good enough for users. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core ApplicationHttpResponse.java
luehe 2004/10/15 09:09:27
Modified:catalina/src/share/org/apache/catalina/core
ApplicationHttpResponse.java
Log:
Reverted previous change
Revision ChangesPath
1.7 +3 -1
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/ApplicationHttpResponse.java
Index: ApplicationHttpResponse.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/ApplicationHttpResponse.java,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- ApplicationHttpResponse.java 15 Oct 2004 00:00:35 - 1.6
+++ ApplicationHttpResponse.java 15 Oct 2004 16:09:27 - 1.7
@@ -237,6 +237,7 @@
*/
public void sendError(int sc) throws IOException {
+if (!included)
((HttpServletResponse) getResponse()).sendError(sc);
}
@@ -252,6 +253,7 @@
*/
public void sendError(int sc, String msg) throws IOException {
+if (!included)
((HttpServletResponse) getResponse()).sendError(sc, msg);
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core ApplicationHttpResponse.java
luehe 2004/10/14 17:00:35
Modified:catalina/src/share/org/apache/catalina/core
ApplicationHttpResponse.java
Log:
Expose any errors on an included resource.
For example, a JSP with this include action:
jsp:include page=nonexistent
or
jsp:include page=nonexistent.jsp
where nonexistent[.jsp] does not exist, currently returns silently, hiding the
fact that the resource to be included does not exist.
This patch returns a 404 with the name of the nonexistent resource.
Yes, SRV.8.3 (The Include Method) mentions that
it [the target servlet] cannot set headers or call any method that
affects the headers of the response. Any attempt to do so must be
ignored.
but i don't think it is referring to the error case.
Let me know if you see any problems.
Revision ChangesPath
1.6 +1 -3
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/ApplicationHttpResponse.java
Index: ApplicationHttpResponse.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/ApplicationHttpResponse.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- ApplicationHttpResponse.java 27 Feb 2004 14:58:42 - 1.5
+++ ApplicationHttpResponse.java 15 Oct 2004 00:00:35 - 1.6
@@ -237,7 +237,6 @@
*/
public void sendError(int sc) throws IOException {
-if (!included)
((HttpServletResponse) getResponse()).sendError(sc);
}
@@ -253,7 +252,6 @@
*/
public void sendError(int sc, String msg) throws IOException {
-if (!included)
((HttpServletResponse) getResponse()).sendError(sc, msg);
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core ApplicationHttpResponse.java
- Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, October 14, 2004 5:00 PM Subject: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core ApplicationHttpResponse.java luehe 2004/10/14 17:00:35 Modified:catalina/src/share/org/apache/catalina/core ApplicationHttpResponse.java Log: Expose any errors on an included resource. For example, a JSP with this include action: jsp:include page=nonexistent or jsp:include page=nonexistent.jsp where nonexistent[.jsp] does not exist, currently returns silently, hiding the fact that the resource to be included does not exist. This patch returns a 404 with the name of the nonexistent resource. Yes, SRV.8.3 (The Include Method) mentions that it [the target servlet] cannot set headers or call any method that affects the headers of the response. Any attempt to do so must be ignored. but i don't think it is referring to the error case. Actually, it has always been my impression that this *is* referring to the error case. I think that somebody should get a clarification before making a change this drastic. (By the way, this doesn't do anything since the Response is still too smart to allow an included resource to call sendError.) In any case, it doesn't seem to be that useful, since in the case of jsp:include page=nonexistent.jsp flush=true it is way too late to do a meaningful sendError. Let me know if you see any problems. 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]
