[
https://issues.apache.org/jira/browse/WICKET-6968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17517058#comment-17517058
]
Robert Murphy commented on WICKET-6968:
---------------------------------------
Why are you marking this resolved? If no charset implies UTF-8, shouldn't
Wicket know that the submit is UTF-8, thus characters don't get corrupt? This
is still an unresolved bug. AjaxFallbackButton appends ; charset=UTF-8 to the
content-type and then Wicket populates models correctly. When ; charset=UTF-8
is not appended, instead of Wicket assuming UTF-8, it is using some other
encoding and the strings are corrupted when populating the form model.
> SubmitLink results in submission without charset resulting in string
> corruption
> -------------------------------------------------------------------------------
>
> Key: WICKET-6968
> URL: https://issues.apache.org/jira/browse/WICKET-6968
> Project: Wicket
> Issue Type: Bug
> Components: wicket-core
> Affects Versions: 9.1.0
> Environment: Ran into this issue running Wicket in WildFly
> 20.0.1.Final in Java 11 in CentOS Linux release 7.6.1810 (Core) and in
> Windows 11
> Reporter: Robert Murphy
> Assignee: Sven Meier
> Priority: Major
>
> Castañeda becomes Castañeda when SubmitLink is used to submit form. Same
> exact code except for using AjaxFallbackButton does not corrupt the string.
> Difference noted between the form submission with SubmitLink and the form
> submission with AjaxFallbackButton is that AjaxFallbackButton specifies the
> charset in the content-type and SubmitLink does not.
> content-type: application/x-www-form-urlencoded
> vs
> content-type: application/x-www-form-urlencoded; charset=UTF-8
> where the latter would appear to be correct to me
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
