WICKET-1597 clearing

[Korbinian Bachl - privat]

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

[Juergen Donnerstag]

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.bachl@...> 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
>

[Korbinian Bachl - privat]

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.bachl@...> 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
>>