struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From KUROSAKA Teruhiko <>
Subject Proposed new config parameters to fix request encoding related bugs
Date Wed, 23 Jun 2004 08:41:52 GMT
My name is "Kuro" and I am new to Struts.

Struts is great in that it takes care of i18n.  But a problem
is that it only takes care of the message portion of i18n.
Especially, it seems to miss a way to set the character
encoding of requests, which is needed when the client
(browser) doesn't send request with charset attribute
in Content-type header and the charset is not ISO-8859-1.
Unfortunately, most browsers don't add charset attribute.

I believe this is the the root cause of the two
bugs I've found in bugzilla:
20186|New|Enh|2003-05-23|CharacterEncoding filter needed for il8n
29668|New|Nor|2004-06-18|unicode text fields in "multipart/form-data" form
(Those in cc: are submitters.)

There are some workarounds to this lacking feature.
The most elegant way seems to be to call request.setCharacterEncoding()
from ActionForm subclass' reset() method.
But this is still cumbersome if all the developers outside
of ISO-8859-1 region have to do this.

I would like to propose to have new config parameters for
struts-config and enhance RequestProcessor so that
request.setCharacterEncoding() is called from within

Specifically, I would add requestEncoding attribute to two
tags, <controller> and <form-bean>.  For example:
this would be used like these:


<form-bean requestEncoding="Shift_JIS"
            type="org.apache.struts.webapp.example.LogonForm" />

Why in two places? Conceptuallly, only <form-bean> needs
this attribute.  But in real world, all the forms in a single app
would share the same request character encoding.  So I thought
allowing controller to have a default encoding for all
form-beans that don't have requestEncoding attribute might be

The name "requestEncoding" was chosen to be in sync with
JSTL fmt:requestEncoding action.  ("requestCharacterEncoding"
would is most accurate but it is too lengthy.)

I would like to ask current struts contributors if this is
an OK design from the Struts' core design philosophy.  If it is
OK enough, then I will volunteer coding to this spec.

KUROSAKA ("Kuro") Teruhiko
San Francisco, California, USA

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message