Gerald Holl wrote:
> Ryan Lubke wrote:
>> Gerald Holl wrote:
>>> Ryan Lubke wrote:
>>>>> It's 3 times in the log, 2 times before the warning and once after.
>>>>>
>>>> Can you post the other two?
>>>
>>> Here it is. It's more than 3 times in the log, I didn't see it first.
>> Ok, looking through the source for the different filters A4J leverages,
>> it would seem that based off the stacktrace, A4J will set the request
>> encoding,
>> and further in the filter processing calls
>> ServletRequest.getParameter() which
>> effectively locks the encoding and causes the warning to be displayed
>> when
>> an attempt is made to set it again (as is done by default in
>> ViewHandler.initView().
>
> Ryan,
>
> I know the cause of the problem. Many of the forms of our app uses
> file upload stuff and so we the the form's enctype to
> multipart/form-data instead of the default
> application/x-www-form-urlencoded.
> If I set the enctype to application/x-www-form-urlencoded no warning
> occurs in the log file and the characters are displayed correctly.
>
> Do you know why multipart/form-data causes broken character encoding?
I'm guessing it's this snippet in Woodstock's UploadFilter (present in
the most recent set of stacktraces):
if (!FileUpload.isMultipartContent(req)) {
chain.doFilter(request, response);
return;
}
If the request isn't multipart/form-data, the UploadFilter invokes the filter chain.
If it is, then further in the processing setRequestEncoding is called.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>