Re: [enhydra] Possible Bug in MultiPartMimeInputStream

Slobodan Vujasinovic <[email protected]> Mon, 26 Sep 2005 13:35:32 +0200
Newsgroups gmane.comp.java.enhydra.general
Organization PROZONE
Message-ID <[email protected]>
This is a multi-part message in MIME format...

------------=_1127734819-2167-97
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

Hi,

we have applied your patch (regarding multipart request headers encoding)!

In Enhydra 5, we have integrated your adaptation directly ("HTTPUtils"=20
based encoding).
I've already committed changes to public CVS!

In Enhydra 6 (EAF), we have implemented a bit different approach (with=20
idea to enable application (not EAF) specific encoding option).
I've adapted 'MultipartMimeInputStream' and 'MultipartMimeInput'=20
implementation.

'MultipartMimeInputStream':
- has additional, encoding dependent, constructor (with your patch=20
applied - MIME header initialization).

protected MultipartMimeInputStream (BMByteSearchStream source,
            BMByteSearch sep, String encoding) throws IOException,
            MimeEOFException {
...
}

'MultipartMimeInput':
This 'MultipartMimeInputStream' constructor is meant to be called only=20
from 'MultipartMimeInput'! Therefore, I had to make additional=20
adaptation and implement, encoding dependent,=20
'MultipartMimeInput.nextPart' method (that should be used from your=20
application code).

public MultipartMimeInputStream nextPart(String encoding)
            throws MimeException {
...
}

Those changes will be included in next EAF (Enhydra) release!

Thank you for your contribution!

Regards,
  Slobodan Vujasinovic
Enhydra Development Team



Jo=E3o Paulo Ribeiro wrote:

>Hi!
>
>I found something that i think is bug: in MultipartMimeInputStream when
>reading the headers of a multipart request, the byte are autamatically
>transformed in String instead of using the correct encoding. This happen
>in 5.4.1 and the last enhydra version from CVS (6.5.1?).
>The problem is the headers in multipart request have usefull information
>like the file name. Not using the correct encoding to transform the
>bytes to a String, made the file name appears wtih strange chars on it.
>
>For enhydra 5.4.1 a made a little patch: i just changed one line in the
>constructor and added the necessary import.
>I changed the line:
>String line =3D new String(bytesToChars(lineBuf,0,n));
>to:
>String line =3D new String(lineBuf,0,n,HttpUtils.ENCODING);
>And added the:
>import javax.servlet.http.HttpUtils;
>
>Now it works well. :)
>
>For 6.5.1 i did not made a patch but it should be something similar like
>changing the same line to:
>String line =3D new String(lineBuf,0,n,
>comms.request.getHttpServletRequest().getCharacterEncoding());
>and add the necessary imports.
>
>I attached the diff for 5.4.1.
>
>I hope this can be usefull.
>
>Best regards.
>Jo=E3o Paulo Ribeiro
>
>=20=20
>
>------------------------------------------------------------------------
>
>32d31
>< import javax.servlet.http.HttpUtils;
>142c141
><             String line =3D new String(lineBuf,0,n,HttpUtils.ENCODING);
>---
>=20=20
>
>>	    String line =3D new String(bytesToChars(lineBuf,0,n));
>>=20=20=20=20
>>
>>------------------------------------------------------------------------
>>
>>
>>--
>>You receive this message as a subscriber of the [email protected] mai=
ling list.
>>To unsubscribe: mailto:[email protected]
>>For general help: mailto:[email protected]?subject=3Dhelp
>>ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
>>=20=20=20=20
>>


------------=_1127734819-2167-97
Content-Type: text/plain; name="message-footer.txt"
Content-Disposition: inline; filename="message-footer.txt"
Content-Transfer-Encoding: 8bit


--
You receive this message as a subscriber of the [email protected] mailing list.
To unsubscribe: mailto:[email protected]
For general help: mailto:[email protected]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

------------=_1127734819-2167-97--