[
https://issues.apache.org/jira/browse/WICKET-6878?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hans Schäfer updated WICKET-6878:
---------------------------------
Description:
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";. 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.
was:
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.
> 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
> Priority: Major
>
> 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";. 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)
