Issue Details (XML | Word | Printable)

Key: CACTUS-89
Type: Bug Bug
Status: Closed Closed
Resolution: Fixed
Priority: Major Major
Assignee: Vincent Massol
Reporter: Scott Leberknight
Votes: 0
Watchers: 0
Operations

If you were logged in you would be able to see more operations.
Cactus

getRequestURL in HttpServletRequestWrapper returns the string "null" in the request URL

Created: 25/Jan/04 04:56 AM   Updated: 17/Apr/04 03:43 PM
Return to search
Component/s: Framework
Affects Version/s: 1.5
Fix Version/s: 1.6

Time Tracking:
Not Specified

Environment:
Operating System: All
Platform: All

Bugzilla Id: 26401


 Description  « Hide
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.

 All   Comments   Work Log   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Serge Knystautas made changes - 20/Mar/04 07:03 PM
Field Original Value New Value
issue.field.bugzillaimportkey 26401 15866
Vincent Massol made changes - 17/Apr/04 03:04 PM
Assignee Cactus Developers Mailing List [ cactus-dev@jakarta.apache.org ] Vincent Massol [ vmassol ]
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.
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.
Priority Blocker [ 1 ]
Environment Operating System: All
Platform: All
Operating System: All
Platform: All
Fix Version/s 1.6 [ 10691 ]
Vincent Massol made changes - 17/Apr/04 03:04 PM
Status Resolved [ 5 ] Closed [ 6 ]
Vincent Massol made changes - 17/Apr/04 03:43 PM
Priority Blocker [ 1 ] Major [ 3 ]