You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cactus-dev@jakarta.apache.org by ji...@apache.org on 2004/04/17 17:04:38 UTC
[jira] Updated: (CACTUS-89) getRequestURL in HttpServletRequestWrapper returns the string "null" in the request URL
The following issue has been updated:
Updater: Vincent Massol (mailto:vmassol@apache.org)
Date: Sat, 17 Apr 2004 8:04 AM
Changes:
assignee changed from Cactus Developers Mailing List to Vincent Massol
description changed from Learning Cactus, I developed a simple servlet called "Servlet1" and a
corresponding Cactus test called "TestServlet1". I am testing the doGet()
method. In the beginDoGet() method I do the following:
request.setURL("localhost:8080", "/testWeb", "/servlet1", null, "name=scott");
Note in the above that pathInfo is null. Then, in my testDoGet() method, I do
the following assertions (among others):
assertEquals("requestURI",
"/testWeb/servlet1",
request.getRequestURI()); // this passes
assertEquals("requestURL",
"http://localhost:8080/testWeb/servlet1",
request.getRequestURL().toString()); // this fails
The second assertion fails! The test runner reports that the actual value was:
http://localhost:8080/testWeb/servlet1null
Setting pathInfo as null in the setURL() method on the WebRequest in beginXXX()
(which the Cactus JavaDocs state is OK) produces the literal string "null" at
the end of the request URL when you call the getRequestURL() method in testXXX()
methods.
I did some digging into the Cactus 1.5 source code and found what apppears to be
an error in the getRequestURL() method in the
org.apache.cactus.server.HttpServletRequestWrapper class. I compared this
method's code to the implementation of getRequestURI() in
AbstractHttpServletRequestWrapper, which handles a null pathInfo correctly.
Basically the problem is that HttpServletRequestWrapper.getRequestURL() doesn't
check whether pathInfo is null when it creates the request URL. In contrast,
AbstractHttpServletRequestWrapper.getRequestURI() checks both servletPath and
pathInfo and prints an empty string into the StringBuffer if they are null. So,
I believe this original code snippet from getRequestURL():
result = new StringBuffer(this.url.getProtocol() + "://"
+ getServerName() + ":" + getServerPort() + getContextPath()
+ getServletPath() + getPathInfo());
can be fixed if it is changed to:
result = new StringBuffer(this.url.getProtocol() + "://"
+ getServerName() + ":" + getServerPort() + getContextPath()
+ ((getServletPath() == null) ? "" : getServletPath())
+ ((getPathInfo() == null) ? "" : getPathInfo());
While this fixes it, I think it could be improved by recognizing that the
request URI is simply part of the request URL and that we can get it by calling
the getRequestURI() method defined in HttpServletRequestWrapper's superclass,
and we could refactor as:
result = new StringBuffer(this.url.getProtocol() + "://"
+ getServerName() + ":" + getServerPort()
+ getRequestURI());
Hopefully this explanation is helpful and it is, in fact, a bug. I did research
whether this bug existed in Bugzilla and could not find anything about it. to Learning Cactus, I developed a simple servlet called "Servlet1" and a
corresponding Cactus test called "TestServlet1". I am testing the doGet()
method. In the beginDoGet() method I do the following:
request.setURL("localhost:8080", "/testWeb", "/servlet1", null, "name=scott");
Note in the above that pathInfo is null. Then, in my testDoGet() method, I do
the following assertions (among others):
assertEquals("requestURI",
"/testWeb/servlet1",
request.getRequestURI()); // this passes
assertEquals("requestURL",
"http://localhost:8080/testWeb/servlet1",
request.getRequestURL().toString()); // this fails
The second assertion fails! The test runner reports that the actual value was:
http://localhost:8080/testWeb/servlet1null
Setting pathInfo as null in the setURL() method on the WebRequest in beginXXX()
(which the Cactus JavaDocs state is OK) produces the literal string "null" at
the end of the request URL when you call the getRequestURL() method in testXXX()
methods.
I did some digging into the Cactus 1.5 source code and found what apppears to be
an error in the getRequestURL() method in the
org.apache.cactus.server.HttpServletRequestWrapper class. I compared this
method's code to the implementation of getRequestURI() in
AbstractHttpServletRequestWrapper, which handles a null pathInfo correctly.
Basically the problem is that HttpServletRequestWrapper.getRequestURL() doesn't
check whether pathInfo is null when it creates the request URL. In contrast,
AbstractHttpServletRequestWrapper.getRequestURI() checks both servletPath and
pathInfo and prints an empty string into the StringBuffer if they are null. So,
I believe this original code snippet from getRequestURL():
result = new StringBuffer(this.url.getProtocol() + "://"
+ getServerName() + ":" + getServerPort() + getContextPath()
+ getServletPath() + getPathInfo());
can be fixed if it is changed to:
result = new StringBuffer(this.url.getProtocol() + "://"
+ getServerName() + ":" + getServerPort() + getContextPath()
+ ((getServletPath() == null) ? "" : getServletPath())
+ ((getPathInfo() == null) ? "" : getPathInfo());
While this fixes it, I think it could be improved by recognizing that the
request URI is simply part of the request URL and that we can get it by calling
the getRequestURI() method defined in HttpServletRequestWrapper's superclass,
and we could refactor as:
result = new StringBuffer(this.url.getProtocol() + "://"
+ getServerName() + ":" + getServerPort()
+ getRequestURI());
Hopefully this explanation is helpful and it is, in fact, a bug. I did research
whether this bug existed in Bugzilla and could not find anything about it.
environment changed from Operating System: All
Platform: All to Operating System: All
Platform: All
priority changed to Blocker
Fix Version changed to 1.6
---------------------------------------------------------------------
For a full history of the issue, see:
http://issues.apache.org/jira/browse/CACTUS-89?page=history
---------------------------------------------------------------------
View the issue:
http://issues.apache.org/jira/browse/CACTUS-89
Here is an overview of the issue:
---------------------------------------------------------------------
Key: CACTUS-89
Summary: getRequestURL in HttpServletRequestWrapper returns the string "null" in the request URL
Type: Bug
Status: Resolved
Priority: Blocker
Resolution: FIXED
Project: Cactus
Components:
Framework
Fix Fors:
1.6
Versions:
1.5
Assignee: Vincent Massol
Reporter: Scott Leberknight
Created: Sat, 24 Jan 2004 8:56 PM
Updated: Sat, 17 Apr 2004 8:04 AM
Environment: Operating System: All
Platform: All
Description:
Learning Cactus, I developed a simple servlet called "Servlet1" and a
corresponding Cactus test called "TestServlet1". I am testing the doGet()
method. In the beginDoGet() method I do the following:
request.setURL("localhost:8080", "/testWeb", "/servlet1", null, "name=scott");
Note in the above that pathInfo is null. Then, in my testDoGet() method, I do
the following assertions (among others):
assertEquals("requestURI",
"/testWeb/servlet1",
request.getRequestURI()); // this passes
assertEquals("requestURL",
"http://localhost:8080/testWeb/servlet1",
request.getRequestURL().toString()); // this fails
The second assertion fails! The test runner reports that the actual value was:
http://localhost:8080/testWeb/servlet1null
Setting pathInfo as null in the setURL() method on the WebRequest in beginXXX()
(which the Cactus JavaDocs state is OK) produces the literal string "null" at
the end of the request URL when you call the getRequestURL() method in testXXX()
methods.
I did some digging into the Cactus 1.5 source code and found what apppears to be
an error in the getRequestURL() method in the
org.apache.cactus.server.HttpServletRequestWrapper class. I compared this
method's code to the implementation of getRequestURI() in
AbstractHttpServletRequestWrapper, which handles a null pathInfo correctly.
Basically the problem is that HttpServletRequestWrapper.getRequestURL() doesn't
check whether pathInfo is null when it creates the request URL. In contrast,
AbstractHttpServletRequestWrapper.getRequestURI() checks both servletPath and
pathInfo and prints an empty string into the StringBuffer if they are null. So,
I believe this original code snippet from getRequestURL():
result = new StringBuffer(this.url.getProtocol() + "://"
+ getServerName() + ":" + getServerPort() + getContextPath()
+ getServletPath() + getPathInfo());
can be fixed if it is changed to:
result = new StringBuffer(this.url.getProtocol() + "://"
+ getServerName() + ":" + getServerPort() + getContextPath()
+ ((getServletPath() == null) ? "" : getServletPath())
+ ((getPathInfo() == null) ? "" : getPathInfo());
While this fixes it, I think it could be improved by recognizing that the
request URI is simply part of the request URL and that we can get it by calling
the getRequestURI() method defined in HttpServletRequestWrapper's superclass,
and we could refactor as:
result = new StringBuffer(this.url.getProtocol() + "://"
+ getServerName() + ":" + getServerPort()
+ getRequestURI());
Hopefully this explanation is helpful and it is, in fact, a bug. I did research
whether this bug existed in Bugzilla and could not find anything about it.
---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: cactus-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: cactus-dev-help@jakarta.apache.org