Hans Schäfer created WICKET-6878:
------------------------------------
Summary: Rendering of relative Urls does not take into account
filterpath for absolute Urls
Key: WICKET-6878
URL: https://issues.apache.org/jira/browse/WICKET-6878
Project: Wicket
Issue Type: Improvement
Components: wicket
Affects Versions: 8.11.0
Reporter: Hans Schäfer
Assume, there is an WicketApplication with mounted Page "error" running on
[https://localhost:8443/ |https://localhost:8443/]
The page "error" renders an reference for resource
"https://localhost:8443/[webjars/uilib/5.6.0/javascripts/bundle.all.js|https://localhost:8443/webjars/uilib/5.6.0/javascripts/bundle.all.js]";.
The rendered Url is created by
Url.parse("https://localhost:8443/[webjars/uilib/5.6.0/javascripts/bundle.all.js";|https://localhost:8443/webjars/uilib/5.6.0/javascripts/bundle.all.js]).
In this case everything is fine:
[https://localhost:8443/error|https://localhost:8443/] renders tag <script
type="text/javascript"
src="[./webjars/uilib/5.6.0/javascripts/bundle.all.js|https://localhost:8443/webjars/uilib/5.6.0/javascripts/bundle.all.js]";></script>
But if I change the filterpath of the application to "recovery", the following
happens:
[https://localhost:8443/recovery/error] renders tag <script
type="text/javascript"
src="[.//webjars/uilib/5.6.0/javascripts/bundle.all.js|https://localhost:8443/recovery//webjars/uilib/5.6.0/javascripts/bundle.all.js]";></script>
This is not the expected Url ../webjars/uilib/5.6.0/javascripts/bundle.all.js
I tried to break it down: The rendered Url in the script tag is created by the
UrlRenderer. The UrlRenderer decides to render a relative url as scheme, host
and port match the corresponding properties of the clientUrl and the Url is not
"contextabsolute" (as it contains an hostname). I think, this is absolutly
fine. But during rendering the relative url the UrlRenderer does not detect,
that it has to handle this url separatly. The segments of the Url contain a
leading "" (for /) which is not followed by the filterpath. I assume, this
should be resolved to ".." for every part of the filterpath.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
