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