You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commons-dev@ws.apache.org by "Andreas Veithen (JIRA)" <ji...@apache.org> on 2008/12/13 00:06:44 UTC

[jira] Resolved: (WSCOMMONS-328) Failure in boundaryPosition condition for checking position validity

     [ https://issues.apache.org/jira/browse/WSCOMMONS-328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andreas Veithen resolved WSCOMMONS-328.
---------------------------------------

       Resolution: Fixed
    Fix Version/s: Axiom 1.2.8
         Assignee: Andreas Veithen

Actually the condition "foundAt + boundary.length > end" is never true, so the entire if statement should be removed. I added a unit test that confirms your analysis and fixed the code. Thanks for spotting this issue!

> Failure in boundaryPosition condition for checking position validity
> --------------------------------------------------------------------
>
>                 Key: WSCOMMONS-328
>                 URL: https://issues.apache.org/jira/browse/WSCOMMONS-328
>             Project: WS-Commons
>          Issue Type: Bug
>          Components: AXIOM
>            Reporter: Csorba Zoltán
>            Assignee: Andreas Veithen
>             Fix For: Axiom 1.2.8
>
>
> org.apache.axiom.attachments.BoundaryPushbackInputStream
> Following code searches for the boundary in the given buffer, and after skipSearch it validates the position whether the boundary extends the buffer limit.
> The check condition is wrong, because rnBoundaryLen = boundary.length+2.  That means if the boundary is found at the end of the buffer, this condition fails although boundary is already in the buffer.
>     protected int boundaryPosition(byte[] searchbuf, int start, int end) throws java.io.IOException  {
>         if (skip == null) {
>             skip = ByteSearch.getSkipArray(boundary, true);
>         }
>         int foundAt = ByteSearch.skipSearch(boundary, true,searchbuf, start, end, skip);
>         // First find the boundary marker
>         if (foundAt >= 0) {    // Something was found.
>             if (foundAt + rnBoundaryLen > end) {                             <-- THIS IS WRONG, SHOULD BE "if (foundAt + boundary.length > end) {"
>                 foundAt = -1;  // Not sure why this check is done
>             }
>         }
>         
>         // Backup 2 if the boundary is preceeded by /r/n
>         // The /r/n are treated as part of the boundary
>         if (foundAt >=2) {
>             if (searchbuf[foundAt-2] == 13 &&
>                 searchbuf[foundAt-1] == 10) {
>                 foundAt = foundAt -2;
>             }
>         }
>         return foundAt;
>     }
> This may cause problem in only one case: if there is one more character after mime boundary at the end of the search buffer, then boundaryPosition returns -1. As \r\n is prior to the boundary, the 'read' function appends '\r' to the read buffer. This results, that searchbuf in he next loop starts with "\nMIMEBoundary...", so '\n' will be appended to the read buffer also.
> That means, an extra CRLF is written at the end of SOAP attachment in this case.
> Using "if (foundAt + boundary.length > end) {" instead solves the problem.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.