Re: WICKET-1597 clearing

> 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
>>