Bug 38113 - getQueryString returns null instead of empty-string
getQueryString returns null instead of empty-string
Status: RESOLVED FIXED
Product: Tomcat 5
Classification: Unclassified
Component: Catalina
5.5.12
All other
: P2 normal (vote)
: ---
Assigned To: Tomcat Developers Mailing List
:
Depends on:
Blocks: 39130
  Show dependency tree
 
Reported: 2006-01-03 23:06 UTC by Dan Jacobs
Modified: 2010-09-07 12:10 UTC (History)
0 users



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Dan Jacobs 2006-01-03 23:06:03 UTC
The method getQueryString in class org.apache.catalina.connector.Request returns
null, instead of an empty string for a URL of the form http://foo/bar? as
required by the specification.  A correct implementation of the method is as
follows:

    /**
     * Return the query string associated with this request.
     */
    public String getQueryString() {
        Object qStrObj = coyoteRequest.queryString();
        return ((qStrObj == null) ? null : qStrObj.toString());
    }
Comment 1 william.barker 2006-03-04 03:59:14 UTC
This is fixed in the SVN trunk, and will appear in 5.5.16
Comment 2 Michiel Meeuwissen 2006-03-28 19:23:18 UTC
(In reply to comment #1)
> This is fixed in the SVN trunk, and will appear in 5.5.16

The fix is not correct.

Following jsp:
<jsp:expression>"" + request.getQueryString()</jsp:expression>
does not write 'null' to the page, even if not question mark on the url.

While javadoc of HttpServletRequest#getQueryString states:
public java.lang.String getQueryString()

    Returns the query string that is contained in the request URL after the
path. This method returns null if the URL does not have a query string. Same as
the value of the CGI variable QUERY_STRING.
Comment 3 Gili 2006-03-29 19:54:05 UTC
(Sorry if this results in a duplicate post, BugZilla seems to be very flacky
today and commiting comments does not seem to work)

I agree. This "fix" breaks webapps: JForum, and maybe others.

The original assumption behind this change was incorrect, the specification
clearly states that getQueryString() *should* return null, not an empty string.
Comment 4 Remy Maucherat 2006-03-29 23:50:49 UTC
(In reply to comment #3)
> I agree. This "fix" breaks webapps: JForum, and maybe others.
> 
> The original assumption behind this change was incorrect, the specification
> clearly states that getQueryString() *should* return null, not an empty string.

Most likely, this will be the one and only time I agree with you on something.

http://foo/bar? means there's no query String -> it should most likely return
null anyway (and if it shouldn't, it's not actually specified anywhere).
Comment 5 Remy Maucherat 2006-03-30 18:46:30 UTC
Ok, so I reverted the fix.
Comment 6 a.in.the.k 2010-08-12 09:01:46 UTC
Please read specifications:

5.2.1.  Pre-parse the Base URI

other components may be empty or undefined....  

A component is undefined if its associated delimiter does  not appear 
in the URI reference; the path component is never undefined, though it may be empty.
--------------------------------------------------------------
So for query we have two values null and "".

Please fix this because Tomcat is the only tested container (even 6.28) which is not capable to tell difference between /aaa? and /aaa.
(WAS, WLS and many others correctly return "" and null) for suplied data.

If you so afraid about old ignorant existing apps, please implement as switch.
Comment 7 Mark Thomas 2010-08-25 12:45:44 UTC
I've fixed this for Tomcat 7.0.x. It will be included in 7.0.3 onwards.

I'll propose a back port (off by default, configured via a system property) for 5.5.x and 6.0.x.
Comment 8 Mark Thomas 2010-08-25 13:12:35 UTC
Backports proposed.
Comment 9 Mark Thomas 2010-09-03 12:48:43 UTC
Fixed in 5.5.x and will be in 5.5.31 onwards.
Comment 10 Mark Thomas 2010-09-07 12:10:53 UTC
Fixed in 6.0.x and will be included in 6.0.30 onwards.