[
https://issues.apache.org/jira/browse/WINK-371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14353172#comment-14353172
]
Martin Smithson commented on WINK-371:
--------------------------------------
So, the issue exists wherever strings are created from byte arrays and vice
versa.
The initialization of the boundaryBA and boundaryDelimiterBA attributes needs
to take place in the constructor so that a suitable encoding can be specified
and UnsupportedEncodingExceptions caught, as follows:
try {
boundaryBA = ("--" + boundary).getBytes("UTF-8"); //$NON-NLS-1$
boundaryDelimiterBA = "--".getBytes("UTF-8"); //$NON-NLS-1$
} catch (UnsupportedEncodingException e) {
e.printStackTrace();
}
This ensures that the parser is able to idenfify each part in the multipart
form data.
Then, as previously noted, the readLine method needs to be modified to specify
an encoding when reading each header from the buffer, as follows:
String hdr = new String(buff, buffIdx, lineIdx, "UTF-8"); //$NON-NLS-1$
Obviously, the "UTF-8" string should probably be defined as a constant
somewhere to tidy up the code.
I have tested these changes locally and can verify that they fix the issue on
z/OS.
> Data conversion issue for Multi-part MIME on mainframe (z/OS)
> -------------------------------------------------------------
>
> Key: WINK-371
> URL: https://issues.apache.org/jira/browse/WINK-371
> Project: Wink
> Issue Type: Bug
> Components: Server
> Affects Versions: 1.2
> Environment: z/OS primarily
> Reporter: Peter Masters
> Attachments: MultiPartParser.class,
> wink-common-1.3.0-incubating-SNAPSHOT-with-wink371-fix.jar
>
>
> We have a method annotated as follows:-
> @POST
> @Consumes(MediaType.MULTIPART_FORM_DATA)
> @Produces(MediaType.TEXT_XML)
> When we look through the parts on zOS, using:
> while (iterator.hasNext()) {
> InPart part = iterator.next();
> InputStream is = part.getBody(InputStream.class, null);
> ...
> }
> we see an exception
> java.lang.StringIndexOutOfBoundsException
> at java.lang.String.substring(String.java:1092)
> at
> org.apache.wink.common.internal.providers.multipart.MultiPartParser.parseHeaders(MultiPartParser.java:264)
> at
> org.apache.wink.common.internal.providers.multipart.MultiPartParser.nextPart(MultiPartParser.java:109)
> at
> org.apache.wink.common.model.multipart.InMultiPart.hasNext(InMultiPart.java:83)
> ...
> The headers going over the wire are in UTF-8, but I believe Wink is trying to
> decode them as platform encoding (e.g. a new String(bytes), without a
> codepage specified). On a regular windows/linux box this would work for
> normal codepoints, but on zOS, EBCDIC encoding is nothing like UTF-8, so the
> assumption wouldn't work. I'm unfortunately not permitted to look at wink
> sourcecode (legal reasons) so I cannot verify this myself, but as this is a
> string handling error on a UTF-8 string, that is the best guess I can do.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
