struts-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <>
Subject [jira] [Commented] (WW-4971) s:include tag fails with truncated content in certain circumstances
Date Fri, 19 Oct 2018 06:48:00 GMT


ASF GitHub Bot commented on WW-4971:

JCgH4164838Gh792C124B5 opened a new pull request #257: Proposed fix for WW-4971 (broken includes
for non-UTF8 content).
   Adds a config flag to make all s:include tags use response page encoding.
   Adds an encoding override property to the s:include tag (flexibility).
   Adds a warning log output to FastByteArrayBuffer when decoding has errors.

This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:

> 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
> 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