[
https://issues.apache.org/jira/browse/WW-5310?focusedWorklogId=863295&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-863295
]
ASF GitHub Bot logged work on WW-5310:
--------------------------------------
Author: ASF GitHub Bot
Created on: 01/Jun/23 16:45
Start Date: 01/Jun/23 16:45
Worklog Time Spent: 10m
Work Description: lukaszlenart commented on PR #692:
URL: https://github.com/apache/struts/pull/692#issuecomment-1572399393
To support this properly I would have to change signature to return an
object like `ParserResult(Map<String, String> params, String fragment)` but
this will break backward compatibility. I will close this PR and left
implementation _as is_ and register a ticket to fix that in Struts 7.x
Issue Time Tracking
-------------------
Worklog Id: (was: 863295)
Time Spent: 1h 10m (was: 1h)
> 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: 1h 10m
> 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)