struts-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF subversion and git services (JIRA)" <>
Subject [jira] [Commented] (WW-4971) s:include tag fails with truncated content in certain circumstances
Date Thu, 01 Nov 2018 19:54:00 GMT


ASF subversion and git services commented on WW-4971:

Commit 567fae9dfc86d467537e9c5255624f4f18e433a2 in struts's branch refs/heads/struts-2-5-x
from JCgH4164838Gh792C124B5
[;h=567fae9 ]

WW-4971 Fix broken s:includes for non-UTF8 content.  The low-risk fix retains existing behaviour
by default, but provides a configuration flag users can set (to true) in order to enable usage
of response (page) encoding for s:include tags.  A WARN level log output is also generated
for failed FastByteArrayOutputStream decoding (can be suppressed by log configuration).

> s:include tag fails with truncated content in certain circumstances
> -------------------------------------------------------------------
>                 Key: WW-4971
>                 URL:
>             Project: Struts 2
>          Issue Type: Bug
>          Components: Core Tags
>    Affects Versions: 2.3.36, 2.5.18
>         Environment: Windows 10, Java 7/8 (but issue isn't environment specific)
>            Reporter: James Chaplin
>            Priority: Major
>             Fix For: 2.6, 2.5.19
>         Attachments: WW4791_Reproducer.war
> Hello Apache Struts Team.
> There is an issue with the Struts include tag (s:include) when processing includes on
a page that isn't using UTF-8 encoding (e.g. ISO-8859-1 or Windows-1252 page encoding).
> In some circumstances the s:include tag results in truncated content from the child page
(i.e. the parent page including the child page via s:include experiences incomplete rendering
of the included content).  This happens when the included page contains certain characters
(e.g. 'ç') in a non-UTF8 encoding (whether directly or from a resource bundle).
> There are no warnings produced in the logs (even in debug mode), so the issue can only
be detected visually when things fail.
> Changing all the content to UTF-8 is a workaround, but that is not feasible in all circumstances. 
Given the preceding and the lack of warnings I'm initially submitting it as a major priority.
> I will attempt to submit a bugfix for consideration shortly.

This message was sent by Atlassian JIRA

View raw message