Martin,

Comments in-line...

Martin Walsh wrote:
Thanks Nikolaos. Response in-line...
That appears to be encoded properly. Is the URL correct i.e. have you
tried simply going to:

http://localhost:8080/test/action/test/tmp_test_txt

The URL would be correct if the %2F was a '/'.  i.e. The following works:

http://localhost:8080/test/action/test/tmp/test.txt

But with the final '/' being encoded because it is technically a parameter, it results in a request of

http://localhost:8080/test/action/test/tmp%2Ftest.txt

This request then does not even make it to Stripes. Tomcat just returns a 400 error, before it even invokes Stripes. So I think the question really is, which side is wrong. Tomcat not even trying to handle the URL, or Stripes encoding the '/' when generating the clean URL.
How do you know it isn't making it to Stripes?

Personally I think part of the issue is that you are trying to inject data that can have spaces or slashes or whatever as part of a base URL. Typically that would be part of a parameter.

How about if you did something like:

http://localhost:8080/test/action/test?file=tmp%2Ftest.txt

i.e. create a link with a parameter called file? I know that changes things slightly but that makes more sense to me.

     Secondly, if the parameter includes a special char, i.e. a space.

     e.g.

     parameter = "String path = test file.txt"

     the link is encoded, which gives
     http://localhost:8080/test/action/test/test+file.txt. However the
     parameter is not decoded, so in my action bean, the path variable is
     "test+file.txt" instead of "test file.txt".

That isn't totally surprising to me. Just use:

java.net.URLDecoder.decode(string, encoding);

In say the setPath(...) method as you expect that you might have a case
wherein the parameter has encoded characters.

I can do that as a fix for now.  Should this not be fixed in Stripes though?
I would imagine there is a reason why Stripes does not URL decode every single parameter... and personally I would not want it to... as having to URL decode data is not often a requirement and would be an often needless performance penalty i.e. often clear text with spaces et al. is collected via a form POST wherein it doesn't matter how the data is formatted.

So... No I don't think this is a bug. I think you are simply combining data that doesn't belong in a base part of a URL normally - and most often gets form POST'ed - into a URL and then having this issue.

Said differently I think what you are trying to do is a little odd ;-)

--Nikolaos

------------------------------------------------------------------------------
The Next 800 Companies to Lead America's Growth: New Video Whitepaper
David G. Thomson, author of the best-selling book "Blueprint to a 
Billion" shares his insights and actions to help propel your 
business during the next growth cycle. Listen Now!
http://p.sf.net/sfu/SAP-dev2dev
_______________________________________________
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users

Reply via email to