[prev in list] [next in list] [prev in thread] [next in thread] 

List:       wink-dev
Subject:    [jira] [Commented] (WINK-371) Data conversion issue for Multi-part MIME on mainframe (z/OS)
From:       "Martin Smithson (JIRA)" <jira () apache ! org>
Date:       2015-03-09 16:29:38
Message-ID: JIRA.12614185.1351694821000.38407.1425918578915 () Atlassian ! JIRA
[Download RAW message or body]


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


[prev in list] [next in list] [prev in thread] [next in thread]