[jira] [Commented] (WINK-371) Data conversion issue for Multi-part MIME on mainframe (z/OS)

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

[jira] [Commented] (WINK-371) Data conversion issue for Multi-part MIME on mainframe (z/OS)

JIRA jira@apache.org

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