in that case I would suggest some kind of
setSlashedUrlHandlingPATH(boolean ..) with the default-behaviour that
wicket handls /a/? and /a? equal;
Korbinian
Juergen Donnerstag schrieb:
I completly agree. And as you mentioned different frameworks might
implement different behaviors. I don't recall exactly but I think I
was under the impression that Wicket didn't make a difference. /a?..
seemed to return the same result as /a/?.. Whether is by intention or
by accident is what I wasn't sure about.
-Juergen
On Thu, Jun 11, 2009 at 11:19 AM, Korbinian Bachl -
privat<korbinian.ba...@whiskyworld.de> wrote:
Hi,
IMHO WICKET-1597 should be applied soon, however there seems 1 last question
from Juergen Donnerstag needed to be clearified (and maybe implemented):
"Applied the change and modified the test cases. Since I wasn't sure if
/a/?param is the same as /a?param, I didn't commit it but attached the
patch."
IMHO /a/?param is NOT the same as /a?param
Reason: different paths!
while the queries are exactly the same, the paths arent;
Example:
/a -> goes to path-root "/" and requests file "a";
/a/ -> goes not to path-root but instead to folder called "a" and requests
document "null" that gets converted to the default-request document for that
folder - often some index.htm or sth. like that; in case there is no default
target however, it may be that the webserver/ container getting the requests
decides to truncate the last "/" and reroutes the request to "/a" - however,
this is dependend on specific container-configuration and mustn't be seen as
valid default;
see also RFC 3986 example under http://en.wikipedia.org/wiki/URI_scheme
where exactly is defined that the parts "/a" and "/a/" each belong to the so
called <hierarchical part> while the ? sperates it from the query part ( [ ?
<query> ]);
Best,
Korbinian
