[
https://issues.apache.org/jira/browse/WW-5310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17762145#comment-17762145
]
nikos dimitrakas commented on WW-5310:
--------------------------------------
I also noticed that the fragment identifier remains as part of the _value if no
? exists, so the behaviour is different if there is both a query string and a
fragment identifier or if there is only a fragment identifier. This causes also
the weird behaviour that if the value of an s:url has a fragment identifier and
also specifies nested s:param-tags, the parameters are added after the fragment
identifier and thus become part of the fragment identifier, not part of the
query string. Sure, this is a very unlikely scenario, but still.
> s:url does not handle equal sign correctly
> ------------------------------------------
>
> Key: WW-5310
> URL: https://issues.apache.org/jira/browse/WW-5310
> Project: Struts 2
> Issue Type: Bug
> Components: Core Tags
> Affects Versions: 2.5.30, 6.1.2
> Reporter: nikos dimitrakas
> Priority: Major
> Fix For: 6.2.0
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> We discovered a strange case when a URL is passed to s:url. The URL contains
> an equal sign as part of a parameter value. Example:
> [https://www.scitepress.org/PublicationsDetail.aspx?ID=GjTu91suYQI=&t=1]
> This URL works in the browser even though the equal sign that is part of the
> value of the parameter ID has not been replaced with %3D.
> When this URL is passed to an s:url as value then the equal sign disappears.
> When I put a break point in ComponentTagSupport.doStartTag() I can see that
> the query string has been split and the component.parameters contains the two
> parameters (ID and t), but the equal sign is missing.
> The problem seems to be in ServletUrlRenderer.mergeRequestParameters called
> from beforeRenderUrl. The way the StrutsQueryStringParser.parse splits each
> param of the queryString on equal sign causes all the equal signs to be used,
> not just the first. Shouldn't that split be only on the first equal sign so
> that any remaining equal signs can be considered as part of the value? Just
> by adding a limit of one to the split should fix this.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
