Different parts of the URL (URI) are encoded differently. The '+' sign, for example, is handled differently depending on where it appears. According to RFC 2396 (http://www.ietf.org/rfc/rfc2396.txt), a plus sign is legal in the path, but converts to a space in the query/parameters area. For example:

In
STS-743
Closed
, the reporter mentions that they have encoded the parameter values using URLEncoding. URLEncoding/URLDecoding can only parse URI query parameters, and does not work on URI paths. So the encoding that was reported as "broken" was actually working correctly for the first time.

Both of these are correctly handled by the parsing code in the Servlet engine. The path is parsed correctly, and using the parameterMap the values are also parsed correctly. No further action would be required by stripes to handle this. (In fact, the URI class always encodes a "+" sign in to the path as %23, but will accept either form for parsing and handles it correctly.)

=================
Suggested solutions
=================

Two possible fixes. First, change the getRequestedPath() method. I've attached code below. Second, it might be worthwhile to provide a startup parameter that re-enables the use of URLDecoding for parameters passed in the path. (And just the parameters, not the rest of the path.) If you would like this option let me know, and I'll see what I can do.

// Check to see if the request is processing an include, and pull the path
// information from the appropriate source.
servletPath = (String) request.getAttribute(StripesConstants.REQ_ATTR_INCLUDE_PATH);
if (servletPath != null)